Alright, so thanks for the intro. 0:01 My name is Mia Brook. 0:02 As you kind of said alright. 0:04 And I'm here today to talk to you about collaborative work flows. 0:08 So, I work at a company called Pixo. 0:12 I am the creative director. 0:14 Which apparently now after this UX session here, probably be called the strategist 0:17 and the product owner and the UX designer and all that stuff, too. 0:21 So, I play quite a broad role at the company. 0:24 And we are, at Pixo, a fairly small company, there 0:28 are twenty nine of us and we do digital consulting, so. 0:31 Websites and web systems at a fairly large scale. 0:35 So as I mentioned, collaborative workflows. 0:40 A topic that I'm very, very passionate about. 0:42 And I'm gonna tell you a short story in a bit 0:46 as to why this topic is so near and dear to me. 0:48 And then we're gonna go into some concrete tools and techniques 0:51 that you can take back with you and implement in your teams. 0:54 So, we're gonna start with Annie. 0:59 This is my girl Annie. 1:02 In 1901, Annie Edson Taylor became the first woman, a 1:03 person to ever go over the Niagara Falls in a barrel. 1:07 This is a true story. 1:13 At the age of 63. 1:15 She went over all the falls and amazingly she survived and 1:17 you can see the look on that guy, that guy's face. 1:21 He is just like, what the heck was 1:23 this woman doing, but thank goodness, she's okay. 1:24 She survived with just a few bruises, a couple 1:27 cuts to her head but otherwise she was fine. 1:30 And I am sharing this story with you today because. 1:34 About two years ago, my team at Pixo, with me included, went over 1:37 the Niagara falls of web projects in a proverbial barrel. 1:42 So, this project was for an 1:49 overhaul complete redesign of the University website. 1:52 And that means there colleges, there departments, there centers, the works. 1:55 And to give you a sense of scale, this old site had about 3000 pages, 2:00 about 95 percent of the content needed to be completely checked or rewritten. 2:06 There was a legacy CMS that was no longer supported. 2:11 And we had a team of 12. 2:15 Very opinionated stakeholders. 2:17 So, we started the project using the water fall method that we'd always used 2:21 and we started with research.We went and 2:26 interviews their students, their faculty, their administration. 2:29 We really got in there. 2:33 We wrote this huge research brief. 2:34 And then based on that brief, the UX people created personas 2:36 and based on those personas, they build these beautiful interactive wire frames. 2:41 once those were done, that got handed over to 2:46 the design team which I was in at the time. 2:49 We, this was like right at the beginning of when we started doing responsive stuff. 2:52 So this was all Photoshop mock-ups of tons and 2:56 tons of different pages all at three different sizes. 2:59 I see nods. 3:03 You're like, those dark old ages. 3:04 When we were done, we handed that over to the development team. 3:06 And then we say goodbye. 3:10 It's like design and UX left, the developers were going to do their thing. 3:11 Once the developers were done, quality assurance came in and, and that was that. 3:16 We have done fairly large projects in the past, 3:22 but now responsive design really took us over the edge. 3:25 And. 3:30 Small waterfalls those can work just fine. 3:30 Medium size waterfalls can be okay. 3:35 Especially if you're wearing a helmet. 3:37 If you're into that kind of that thing. 3:39 But the larger the waterfall gets the more dangerous it becomes. 3:42 And the look of horror. 3:49 [LAUGH]. 3:51 >> [LAUGH] On this guy's face, is pretty much how I felt, the moment 3:51 that I realized that our team was going over the Niagara Falls of web projects. 3:56 My friends in a barrel. 4:01 So I'm assuming most of you, or maybe even 4:04 everyone here today, has experienced the challenges that come with. 4:07 The waterfall methodology. 4:11 So I won't go into the gory details 4:12 of how painful this project actually ended up being. 4:15 But I'll tell you this. 4:18 Because of multiple delays, both on the client's part and 4:19 our part, say it took two very long years to complete. 4:23 And like Annie, we survived. 4:28 We came out the other end. 4:31 We were kind of bruised, kind of shaken. 4:32 But we, we made it out okay. 4:35 And the site turned out beautifully. 4:37 And we were fine. 4:38 But, I actually fully share Annie's sentiments. 4:40 And she said, if it was with my dying breath. 4:46 I would caution anyone against attempting the feat. 4:49 I would sooner walk up to the mouth of a cannon, knowing it 4:52 was going to blow me to pieces than make another trip over the Fall. 4:56 Never again am I going over that. 5:00 So, since our epic waterfall adventure. 5:03 We've put a lot of effort into rethinking 5:08 our process at Pixo, and we're totally not alone. 5:10 Every consulting firm that I've talked to recently, a 5:13 lot of people here that I've just been talking with. 5:16 Everybody seems to be moving from a more rigid silent 5:19 approach to one that's a lot more collaborative and iterative. 5:23 And at Pixo, we're really in the thick of making that transition. 5:27 We've definitely not got it solved, but we're doing a lot of experimentation and 5:30 a lot of tweaks and we've learned a ton in the past two years. 5:35 And the really key thing we've learned is that we 5:41 need to adapt our methodology to the needs of every project. 5:43 We found that different techniques worked better for different kinds of clients. 5:47 So, we found that using a different approach for, say, a large web system 5:50 is needed as opposed to, say, a sexy brochure marketing site for a start up. 5:55 And, that's why what I'm presenting today isn't a methodology in and of itself. 5:59 It doesn't represent our, you know, quote, unquote process. 6:05 It's a collection of tools and techniques that you can use all at, you can start 6:08 implementing all at once, but I actually recommend 6:12 implementing them and trying them out one by one. 6:15 There's a great quote from an article in a list apart that showed up a 6:19 couple of weeks ago by Mike Libreria that really gets to the heart of this. 6:23 He said, a mentor of mine once told me that programming boils down 6:28 to reducing the number of unknowns on a project to a manageable number. 6:32 One is fine, two is a stretch, three is asking for trouble. 6:36 So, change takes time. 6:43 And. 6:48 Now I'm gonna talk to you a little about 6:50 those techniques that we can then jump into and 6:52 you can take and you can implement with your 6:55 own teams and your own peoples and your own project. 6:57 So, Sketch Studios, this is my favorite technique to 7:00 get the entire team invested and, on a project. 7:05 So Sketch Studios are a collaborative exercise. 7:09 Where the project team designs and iterates 7:13 a interface together in a structured format. 7:15 And this technique helps build the shared understanding of 7:18 the points of view and expectations on a project. 7:21 And it really speeds up the process of getting to the final design. 7:24 So I'm gonna show you a story of a recent one we did. 7:28 And a step-by-step breakdown of how to do a successful sketch studio. 7:31 So recently we redesigned the intranet 7:38 for the Champaign-Urbana Mass Transit District. 7:40 And this is the organization behind 7:44 Champaign-Urbana's really, really wonderful transit system. 7:46 So MTD's intranet is their core internal communication hub. 7:50 It's really, really important to the day to day runnings of the organization. 7:55 It's where bus operators message each other. 7:59 It's where payroll requests are made. 8:02 It's where people submit forms and, and request. 8:05 Things like clothing allowances. 8:10 Doing a sketch studio was one of the keys to this project's success. 8:15 So a good sketch studio needs clear 8:23 objectives, and research helps establish those objectives. 8:24 For MTV we began the process by interviewing MTV employees about how 8:28 they used the Internet, and we made sure to include MTV's project 8:32 liaisons in those interviews, so that they could hear first-hand, what the 8:35 paint points were and what the issues were that employees were talking about. 8:40 So using the results of these interviews and looking at 8:47 analytics and then doing our own assessment of the site. 8:51 We came up with a feature report that captured 8:54 those pain points and our recommended solutions for them. 8:57 It also assigned priorities for each of those recommendations. 9:00 And here's an example of the feature report that we did for MTV. 9:03 So the first column identifies Pixo's recommendations based on the pinpoints. 9:10 And the second column is an explanation of those recommendations. 9:15 So, for example, exposed key info in the dashboard. 9:19 Currently takes a lot of drilling in to find out what's new and fresh. 9:23 Let's make sure that is, we show that on the dashboard in the new system. 9:27 We then have columns for value and effort 9:33 and element nature for low, medium and high. 9:36 So with the case of NTD, they had an in-house developer that was exceptionally 9:39 talented and wonderful, and they were gonna 9:44 have him build the intranet that we designed. 9:45 So we then handed this feature port to him and had him 9:49 add some of his own notes and had him actually go through. 9:53 And add what he thought the was value and effort for each of these features. 9:57 And so that really helped determine our priorities 10:01 and make sure that when we went into 10:04 the sketch studios we had a clear set of tasks that we wanted to work on. 10:05 So a good sketch session needs clear objections. 10:10 And the feature report helps define the problems that you're trying to solve. 10:13 And your feature report may look completely different. 10:17 I mean, we did ours in Excel but, probably we'd use Google Sheets now. 10:20 You can even have it as a list. 10:23 But the most important thing is to identify 10:25 what you want and need to work on, what 10:27 value those features bring to the project, and what 10:29 the level of effort is to implement those features. 10:32 [BLANK_AUDIO] 10:35 One sec. 10:38 Water. 10:39 All right, the next thing is to include the 10:42 full team and typically in our industry, sketch studios, these 10:46 kind of things, are done by UX, or the 10:50 teams that are known as UX, sometimes designers get involved. 10:53 But I wanna emphasize that the most succesful, of the design studi, of 10:57 the sketch studios that I've done, have 11:01 involved a much broader, much broader team. 11:02 So invite your clients, invite project managers, invite developers, 11:05 maybe even the quality assurance people, so that they can 11:09 really see, what you're, what you're gonna be building, 11:11 and get a real sense of ownership into the project. 11:15 And by having the full team you get 11:18 perspectives that you might not have gotten otherwise. 11:20 So in the case of NTD there were three of us. 11:24 There was a UX designer, a graphic designer, 11:26 in this case me, and NTD's in-house developer. 11:29 And some of the best decisions we made came from MTD's developer. 11:33 As somebody who worked there, he had a 11:37 really strong understanding of the organization and its users. 11:39 And he's also going to be building the thing. 11:43 So he had a real investment and, and incentive to make sure 11:45 that every single aspect of the design made perfect sense for implementation. 11:50 He was gonna be building the thing. 11:54 So in our feature report, we broke the internet 11:58 into ten distinct features and we did one sketch 12:01 session per feature for a total of a ten 12:05 sketch set studios over the course of a few weeks. 12:07 In order to lower the stakes of the 12:11 initial sketch studio and to get everybody feeling comfortable. 12:13 We actually started with the lowest priority feature. 12:17 And in MTV's case, this was the classified section. 12:20 So we had a classified section, it was 12:24 kind of crappy on their current internet, it was 12:25 something that would bring value to the employees, but 12:28 it wasn't crucial to the day to day operation. 12:31 So that's what we started on first. 12:33 So if you're going to be doing multiple sketch studios because you have several 12:36 features you want to work on, I 12:38 definitely recommend starting with the lowest priority first, 12:40 because then you can work out the kinks in your process, and for us, by 12:43 the time we got to the really important features, we were really on our game. 12:47 We knew how to do things. 12:50 We knew how it worked, and we had established that basic communication. 12:51 So at the beginning of each of these sketch studios, we reviewed 12:57 a very informal feature brief that was compiled by our UX designer. 13:01 And in this document, again super simple Google Doc, she identified the page 13:06 types that we would need to be working on during that sketch studio. 13:11 So for classifieds. 13:14 things like a list page an item page post an item page she also did a comparison 13:15 of popular classified listings and how they approach key features that we need in 13:21 the classifieds so for example how long should 13:26 a listing stay up should we let people 13:29 do thirty days sixty days or what kind 13:31 of categories should we break the classifieds into. 13:34 She also included screen shots of each classified listing. 13:39 And Kijiji happens to be horribly ugly. 13:42 But it had some key features that would allow us to really 13:43 have a good discussion of what they're including, versus what we need. 13:48 And those Canadians in the house might recognize Kijiji. 13:52 So a feature brief should establish the sketch studio's 13:57 priorities, and coming with a concrete task list helps 13:59 give structure to the session and a comparison analysis 14:02 really gives you a great jumping off point for discussions. 14:06 So is this, this is really where the fun starts, so the image I'm gonna show here. 14:09 Is we did this for our dashboard and 14:15 the dashboard was one of the most important features. 14:20 I think we did this one third and we 14:22 wrote out on the whiteboard the most important elements, all 14:24 the elements that need, that needed to be on the 14:28 page and then we had our developer go ahead and. 14:31 Rank them in order of importance and you can see over 14:34 here that he actually marked the bulletins as the number one 14:37 thing in importance and I'm there on the left starting to 14:41 draw out these little grids for where the bulletins would go. 14:44 So the great thing about this process is that, 14:49 especially working with a white board, you can erase. 14:52 Photograph, discuss, sketch, erase some more, and 14:54 it's a very, very quick iteration between ideas, 14:58 and for us, it was also an opportunity to sort of get the ugly out. 15:01 Get those ideas that are kind of stale, and kind 15:05 of lame, but they're the first ones that come to mind. 15:07 So, for here it was like all right let's do this traditional 15:09 card gridded approach for each particular, piece of content that we needed. 15:13 But what we found was as we kept sketching and iterating on this, 15:17 with that stream made a lot more sense, that had all the different 15:22 elements in the order that they came in, and that was something that 15:25 was more digest, that we hypothesized at the time was more easily digestible. 15:28 And it's something that we've done user testing 15:33 on since and it's been a really good approach. 15:35 So it was really amazing to have the developer's last 15:40 client on hand cuz he was immediately able to video things 15:42 that just wouldn't work and fill in any knowledge gaps 15:46 that arose and we also held these sessions at MTV's office. 15:49 And what that did was it really allowed us to, anytime, 15:53 we had a question about something that our developer couldn't answer. 15:56 He was able to run from the next room. 15:59 Grab the person who was in that area and have them come in. 16:02 Look at our whiteboard and give us feedback. 16:05 Or just make a quick phone call. 16:08 Somebody would come down. 16:09 If you have the opportunity to do this onsite with your client, 16:10 it's really really great to be able to bring those people in. 16:14 Because of all the prep we've also done. 16:19 We were able to very quickly iron out all the 16:21 snacks, and fill in detail, and move towards the prohesive design. 16:23 So, after you're sketch studio, we went back to Pixo 16:28 with photos of our drawings in hand, and a UX designer. 16:32 When ahead and put those in an interactive prototype that was filled 16:36 with annotation based on the things that we had discussed during the session. 16:39 And this serves, this served as the main records for our designed decisions. 16:43 So in total we held about ten sketch sessions 16:47 about two hours each, very dependent on the features. 16:51 Some features were very quick. 16:54 Took us about a half an hour. 16:55 Other features that were more complicated took us up to two hours. 16:57 But in an average of 20 hours, we were able to get more 17:01 progress and more consensus that we historically 17:05 have gotten in about twice that time. 17:07 And one of the wonderfullest things that came out of this was that we 17:09 actually came in 40 hours under budget for this particular phase of the project. 17:13 So I've just shown you one variation, but I definitely encourage you to take the 17:19 concept of Sketch Studio and adapt it to you and your teams and your projects. 17:23 And here are a couple variations based on scenarios that you might find yourself in. 17:28 So large groups. 17:34 What I just showed you works great for two to four people. 17:35 Very informal, in front of a white board, with absolutely no structure tying to it. 17:39 If you're going to do sketch studios with larger groups, I encourage you 17:44 to break up into smaller teams, and then have people sketch on paper. 17:48 also really helpful to actually give time structure, in these cases. 17:54 So, to have these smaller groups do ten 17:57 minutes of brain storming and sketching, come back 18:01 together as a group, ten minutes of review 18:04 and discussion, then go back and iterate on that. 18:06 So having a structure for larger groups really helps keep things moving. 18:08 And keep people on task. 18:13 You might also find yourself being part of remote teams or having remote clients. 18:15 And one of the absolutely most wonderful 18:20 tools for this is an IPEVO document camera. 18:23 It's really helpful to be able to sketch 18:26 and see each other's sketches in real time. 18:28 And this camera is particularly great because if you put your hand. 18:30 It's the camera goes on to the paper, but if you put your hand in, 18:34 it doesn't refocus on your end, it will keep a fixed focus on the paper. 18:38 This is a particularly good tool for working remotely. 18:41 And, I just read a blog post a while back about a company that actually sends 18:44 clients these cameras in the mail when they 18:48 wanna do this collaborate sketch studios with them. 18:50 Cuz, it's such a valuable part of their experience. 18:53 So, Sketch Studios are a lot of fun. 18:58 And by getting a team, the team in the room and sketching together, you can 19:00 iterate ideas, superfast in real time, and give 19:04 everyone a sense of ownership of the project. 19:07 [BLANK_AUDIO] 19:10 So the next technique, if you've gone 19:13 to design school, you'll be intimately familiar with. 19:15 Group critiques are absolutely crucial to good innovative design. 19:18 But, in my experience, they're also something 19:23 that's really easy to forget to do. 19:25 Or to push aside in the face of deadlines or people being spread too thin. 19:27 And regular code reviews fall into a pretty similar bucket. 19:31 And also getting critiqued can be scary. 19:35 And you're standing and presenting in front of 19:37 a room of people who are smarter than you, 19:39 and pointing out things that you potentially have 19:42 missed, or things that you could have done better. 19:44 And 19:46 that's something that can be pretty humbling for a lot of people. 19:49 But in order to be successful, be on the waterfall. 19:52 We have to get comfortable exposing our unfinished work to the rest of the team. 19:55 And by the rest of the team, I 20:01 mean everyone who's gonna be working on the project. 20:02 Make sure to show it to your developers, to your project managers. 20:04 Really, the more people that you can, to get that feedback. 20:08 So, when discussing the success of Pixar's films, and that is Pixar, not Pixo. 20:13 We get that mixed up a lot. 20:19 The President of Walt Disney animation studios Ed Catmull, said that one of 20:21 their, the keys to their success, was reviewing the material every single day. 20:25 This was a process of review that came from employees that had worked at 20:32 Disney, that had worked at Lucas films, 20:35 and he stressed the importance of constant review. 20:37 As creative people, we wanna show things when they're done. 20:41 That's kind of our natural inclination. 20:44 But, he said, when you get over the embarrassment, you get more creative. 20:46 It's not obvious to people, but starting down that path, helped everything we did. 20:51 So at Pixar we don't have daily formal design critiques, 20:57 but we have a lot of, frequent informal reviews, and every 21:01 Wednesday, we get the entire design UX in front of the 21:06 development team, for an hour of what we call design digs. 21:10 So we use that hour to discuss web trends. 21:14 If somebody's seen a speaker and there's a video, 21:16 we will watch that video or watch a webinar. 21:19 And it's an opportunity for us to share our work for the team. 21:21 With 29 people at Pixar, we don't often 21:26 get to see what everybody else is working on. 21:28 And this gives us an opportunity to, not only share what 21:31 we're learning, but, give each other feedback, and much much needed feedback. 21:35 So the first time we did a critique at Design Digs, the project manager for 21:39 that particular project walked away saying, I 21:43 never wanna do a project without this again. 21:46 And ever since then we've made it a point, 21:48 to bring every project that we can for group critiques. 21:51 When running a critique, it's really important to ask the right questions, 21:56 and this is something that I've heard in, talk after talk today. 22:00 What do you think? 22:05 That question will only get you so far. 22:06 And, may not address the full underlying issues that you're trying to solve. 22:08 So Jason [UNKNOWN], the CEO of base camp, recently published a blog 22:12 post, with about 50 questions that he finds himself asking at design reviews. 22:17 It's a really wonderful reference that I highly recommend, you guys look up. 22:21 And for today, I've pulled out some of my favorites. 22:26 What's the takeaway after eight seconds? 22:30 Why is that worth a click? 22:34 What's the simpler version of this? 22:37 Why that order? 22:39 Would it matter if someone missed that? 22:42 Is this better as a sentence or a picture? 22:43 What problem is that solving? 22:49 So proactively asking for feedback, not a super natural inclination for most people. 22:54 But for me collaborating with others, is one 23:00 of the absolute best parts of being a designer. 23:02 And by making the critiques a priority in asking those hard questions, we 23:05 can push ourselves to innovate beyond the web trends that we're seeing everywhere. 23:09 So next you're doing a group critique, grab somebody 23:13 who you might not traditionally involve in a crit. 23:16 Make design a shared effort, and let your 23:19 team help push the boundaries of what you're creating. 23:21 So I'm gonna with you a story, about a 23:27 site we just built for a startup in Silicon Valley, 23:29 whose name I can't actually share with you cuz they're 23:32 in stealth mode until they launch their site next week. 23:34 So the client came to us, requesting a marketing site that 23:38 will show off a super-cool biotech product that they're working on. 23:41 But the thing was, they like, you know we have this 23:46 PR deadline coming up and we need the site in seven weeks. 23:49 They also had three very key goals. 23:54 The first being, they needed to get sign ups for their beta. 23:56 [SOUND] The second is to show investors and 23:58 potential investors that their product is actually for real. 24:01 And the third, is to blow any competitors that are 24:04 in the market, at the moment, completely out of the water. 24:08 So, typically at Pixar, we take anywhere from 24:13 four months to a year to build the site. 24:16 We work on large scale web systems. 24:18 We do a lot of requirements gathering. 24:20 And as you've heard from my previous story about the epic waterfall adventure. 24:23 In some cases it can actually take up to two years. 24:27 How that, knock on wood, never again. 24:30 We've never done such a large scale, such a, full blown, 24:33 cutting edge marketing site in such a short period of time. 24:37 But this project, ended up being the combination of two 24:43 year's worth of experimentation, with new techniques and new processes. 24:45 And has been by far the most successful and 24:49 profitable and fun project that I've worked on to date. 24:53 So leveraging techniques, that we tested out to this point, 24:58 we came out with a plan particularly for this project. 25:02 And here are the lessons that we put 25:05 into practice, that made it such a successful project. 25:07 So identify your team, your full team, 25:13 right at the very beginning of the project. 25:16 And make sure that team stays on, from the beginning right till the very end. 25:18 Cohesive teams, that stay together throughout the length 25:23 of the process, are a lot more efficient. 25:26 They have a greater ownership of the product that they're working on. 25:29 I mean nobody likes to come in, in the middle of a 25:32 project, look at somebody else's code, 25:34 because somebody else's code is always bad. 25:37 And then have to, re-architect or re-learn how they did it. 25:39 By having cohesive teams throughout the life 25:44 cycle of the project, you also capitalize on 25:45 that sense of, comradery and trust that 25:48 comes with people working together throughout the project. 25:50 At Pixar, we have definitely been guilty of hot potatoing projects. 25:55 And we have found that [SOUND]. 26:00 Aside from exploding the project's timeline, it also 26:03 significantly reduces the profit, profitability of a project. 26:06 There is massive knowledge loss, when you pull somebody off a 26:10 project, and then there's the spin-up cost, when you put somebody 26:14 new on, and it takes a lot of time for them 26:18 to get up to speed, and in our business, time is money. 26:21 So, if you're in a startup, or a 26:26 product focus company, keeping your team cohesive may not 26:28 be as big of an issue, but in a consulting company, this is like, super super hard. 26:32 And we don't have a magic bullet yet for making 26:37 this work perfectly, but seeing how important this is for, 26:39 our own team morale and the bottom line, we've updated 26:43 our sales and traffic management processes to prioritize cohesive teams. 26:46 When difficult decisions need to be made, the 26:51 priority now is to always keep our teams together. 26:54 That meant that for the starter project, we actually had to hire 26:58 two contractors to make sure that the project got done on time. 27:01 And while our own team members were super bummed about it, 27:05 cuz it was a really, really cool project, it made sure that 27:07 we were able to get the project done on time, and it 27:10 wasn't impacting any of our other work that we had going on. 27:13 So keeping your team cohesive is way more efficient. 27:20 It brings a greater sence of ownership to the team, 27:23 and it's really, really important, for building comradery and trust. 27:25 So the traditional waterfall model, kind of like a relay 27:32 race, maybe a very antiquated relay race at this point. 27:35 Each team does its work, passes the baton in the form of knowledge 27:39 and de, and deliverables off to the next team, and as so it goes. 27:43 So you've got, in silos each team does it's 27:47 thing, gets things done, hands things over to the next. 27:51 For the startup project, because we are on such 27:55 a tight timeline, we decided to work in parallel. 27:57 So we started to get familiar with the client, get to know 28:01 what their priorities were, get to know the product a little bit more. 28:05 And then we did an internal sketch studio, with the entire team 28:08 based on our, and based on those sketches we built an interactive prototype. 28:12 So when the basic architecture of the 28:18 site was down, we jumped straight into implementation. 28:19 The wire frame, this prototype, far from being finished. 28:22 It really just had the basics in it. 28:25 Have a navigation, has a footer, has some homepage elements, had 28:27 some pieces from more informational pages, but it was enough there that 28:31 the development team could, build out basic features, build out all the 28:36 infrastructure that they needed and really get started, and then in parallel, 28:41 we also started the design process. 28:47 So, getting the visual style of the site down, 28:49 making sure we had the bits and pieces that we 28:53 could then hand over to the development team and 28:54 really make sure, that the initial site design was established. 28:56 Very shortly after design and development began, we pulled our QA person in. 29:01 Because, then she was able to test things in real time as a feature went 29:06 up on our DEV site, she went through, made sure it worked and that really helped. 29:10 You dont get to the end of the project, you've got like, a few weeks 29:15 left, and then it's like boom, here are all your problems that QA comes up with. 29:17 So having them do that, as we were building, made a huge difference. 29:22 So working in parallel allowed us to it, 29:27 allowed us to iterate on the site incredibly quickly. 29:29 About two weeks into the project, it became very clear 29:32 that a particular section of the site where we were 29:36 talking about the client's web interface, it really needed some 29:38 sort of video or animation to communicate, effectively how it worked. 29:41 And so, in our initial prototype ,we had static 29:46 images and text that were describing this web interface. 29:50 And after doing some user testing, showing this 29:52 around, people were like gosh we really, really want 29:55 an animation, somehow get us in there so we can, we can see how the thing works. 29:57 We have initially intended to do our animation in phase two, 30:02 just because they really wasn't very much time on this project. 30:05 We also included in our contract, that we wouldn't 30:09 do any animation in phase one because of the timeline. 30:12 That could be felt so strongly about, wanting to set the 30:14 expectations and not get into something that might have been very troublesome. 30:17 But, you know, this approach we knew just weren't, wasnt gonna cut it. 30:24 We didn't wanna move forward with it. 30:27 So what we did is we had our developer, since we 30:29 were making such good progress at this point, go into a prototype. 30:31 He went, spent a day, spent a little bit of time working on a particular piece 30:35 of the animation, to see if we actually could do this in a short amount of time. 30:38 He came back, and he's like. 30:42 That was so much easier than I expected. 30:44 I have no issues and no concerns that we 30:46 can do to the full animation within the timeline. 30:49 So we prove to ourselves that we can do it. 30:51 I need to show you a little snippet. 30:53 How it turned out. 30:56 And that being a much more immersive experience. 30:57 And when we show this in our user testing, people are like oh my 31:00 gosh, okay, we get this, we understand so much more of how this works. 31:02 And this was really only possible, because development 31:08 started well before, either design or UX were complete. 31:11 And it gave us that buffer time that we needed, to 31:15 add something that actually became the client's favorite feature on the site. 31:18 And it made us look great, cuz we give this bonus 31:23 feature that went above and beyond the expectations that we have set. 31:26 So having UX design, development QA working in 31:31 parallel, not only saved us a ton of time. 31:34 But it gave us room to really respond to the needs of the project as they arose. 31:37 And, made for a really cool feature, and very very happy clients. 31:42 So I can't stress enough how important regular, 31:50 consistent communication is, both for the client and internally. 31:54 And because this starter project was done on such a tight 31:57 timeline, we had our client commit to a one hour meeting. 32:02 Every single day. 32:05 And that might sound excessive, but it was actually 32:07 one of the reasons that our project was so successful. 32:09 Because any time we had a question and any time that we had 32:12 something we wanted to showed them, we knew that we had a meeting 32:16 at the end of the day, that we can then show it to 32:18 them and get their immediate feedback, and 32:20 it allowed us to iterate incredibly quickly. 32:22 When you're working on a tight timeline, the most important thing is to keep 32:26 things moving and the thing that really 32:30 holds up progress the most is unanswered questions. 32:32 Internally, we also held three weekly team meetings 32:36 that were about ten to 30 minutes each, 32:39 and the key questions at these meetings, is 32:42 do you have what you need to keep working? 32:45 So these meetings could sometimes be super short when everybody went 32:49 around and was like, yep, yep, yep, got what we need. 32:52 Sometimes they were a little bit longer when somebody said, you know, I 32:55 have a bit of a blocker here, and we needed to talk that through. 32:57 But the goal of these meetings was really to keep it 33:00 short and make, make sure that people could keep on moving. 33:02 On top of that we also held one, one to 33:06 one and a half hour tech meeting, where this was 33:09 the opportunity for our team to really problem solve bigger 33:12 tech issues like, what framework, if any are we gonna use? 33:16 How are we gonna handle version control? 33:19 What's the go live process gonna look like? 33:21 So, one of the hardest things for us to stomach at 33:25 the beginning of this transition to more collaborative and iterative work flows, 33:27 was the uptake in the number of meetings that we ended up 33:31 having, and there is no question, meetings take a ton of time. 33:34 But we also notice this, the projects that we had more task 33:39 based team meetings where people were actually sitting in them and not just 33:44 schmoozing and talking but really addressing 33:47 key issues, were the ones that tended 33:49 to not go over budget, and we've seen a really consistent trend here. 33:51 [SOUND] And while it's a pretty large and potentially scary committment to 33:56 make, that's a lot of time, especially in a consulting environment, it's really 34:00 paid off for us, in the long run and I would say at 34:05 this point, we budget about 25% of our project's budget for team meetings. 34:08 So task-based meetings, super, super important, to keep the project's momentum. 34:13 They also really help the team gell and they create this, 34:17 greater sense of accountability and excitements, 34:21 in the team about the project. 34:24 All right, Agile, the big hot topic in our industry at the moment. 34:28 This has, Agile Development has actually given us some of 34:34 the most transformative and powerful techniques that we've used Pixar. 34:37 And most of the established Agile techniques, they're very structured. 34:41 You know, very particular rules, very particular things 34:45 you need to follow to do them right. 34:49 But, at Pixar we've been easing our way 34:51 in and really cherry picking, the pieces and the 34:53 bits of the Agile process that really worked 34:56 for us in the particular projects we're working on. 34:58 And task boards, are one of those bits. 35:01 So, task boards are a project management tool, that allows the team to 35:05 see at a glance the status of any given task on a project. 35:09 And these boards are amazing. 35:13 There was this like, audible side relief at Pixar, when we started 35:15 using it through the company about a year and a half ago. 35:19 So we internally use a project management tool called JIRA for our task boards. 35:22 But you can use all sorts of other tools. 35:27 There are plenty online. 35:30 Last night at the reception I was talking to somebody 35:31 who uses Trello, and is super in love with Trello. 35:34 His team absolutely adores it. 35:37 and, you know you could also use post it notes on a wall or a white board. 35:41 The, the key thing here is that, you keep each 35:46 person's task outline in a very, very easy to internalize format. 35:49 So here's the Agile board we used, for the start up project. 35:53 And I'm gonna go through it just to give you a sense of how these things work. 35:57 So the first column has, the tasks that need to be worked on. 36:01 So the title is of this one, to do. 36:05 The second shows the tasks that are in progress, and the third 36:08 is for tasks that are blocked or on hold for some reason. 36:13 So for example, a task might depend on a response from a client. 36:16 We've asked the question we're now waiting for that answer. 36:21 Or if I'm waiting for somebody to finish up their piece before I can work on mine. 36:25 The most important thing, is that everyone can see, at any 36:30 given time, that, that parti, that particular task is in limbo. 36:33 And then, really have conversations to address how to get that out of limbo. 36:37 Next you see a design review column. 36:43 And this indicates to whoever is testing or 36:45 reviewing, that this task is ready for review. 36:47 Then that person can go in, test that feature, 36:50 and then slide it over to the done column. 36:54 There's, lots of different ways that you can arrange these 36:57 boards, and we've experimented with 37:00 different approaches from project to project. 37:02 And you can see in this board from another 37:05 project, that there are six columns instead of five. 37:06 You can see the titles of the columns are slightly different. 37:10 It's very much depending on the projects needs. 37:14 I could seriously give an entire talk about 37:17 task boards, nuances of how to use them, but 37:19 I am just gonna show the, very very 37:22 basic workflow that we used on the startup project. 37:24 Okay, so the beginning of the project, the project manager creates a list 37:29 of tasks, for every known task that they need to do on the project. 37:33 All of those tasks then go into a backlog. 37:37 It's a list of all of them as a catalog 37:40 at any given moment of the task that we know about. 37:43 [SOUND] At the beginning of the week, the private manager selects a set of tasks 37:45 based on the priorities that have been 37:51 established and moves them into the task board. 37:54 And then as people work on their tasks, they can drag and drop the 37:58 tasks from column to column to reflect in real time the status of the task. 38:02 And at the end of the week the board is 38:07 refreshed, the done tasks are removed, and the cycle begins again. 38:09 And like I said this varies so much from project 38:16 to project, we might have, that review process go for two 38:18 weeks, it could be shorter, it could be longer, it's 38:21 very, very much depending on how things go with your project. 38:24 But, what I love about task boards and this view is the 38:27 transparency, you know where your team is at, at any given time. 38:31 You know what the bottlenecks are, and 38:36 you can go ahead and address those immediately. 38:37 It's also a really wonderful way to capture and organize your team's issues. 38:40 Prioritize them, take action on what's important. 38:44 So of all the tools and techniques in this talk, if you're not using 38:49 task boards at the moment, that's the first thing that I would try out. 38:54 As the complexity of our project grows, the amount 38:59 of stuff we need to keep track of increases. 39:01 Task boards have been an absolute life saver for us. 39:04 And I'm absolutely never doing a project again, 39:07 without having a view like this to work with. 39:10 [BLANK_AUDIO] 39:12 So, we've still got a ton to learn at Pixar. 39:15 Like I said, we're very much in the thick of it. 39:18 Everyone I've talked to in the industry is very much in the thick of it. 39:21 But, we're moving forward, we're trying out these new techniques. 39:24 We're trying out ways to be more collaborative and efficient in 39:28 our process and we're, we're definitely moving in the right direction. 39:31 My girl Annie would be proud. 39:35 Every project we do goes a little big smoother, a little bit faster. 39:38 I can see real change happening, and you know, change is hard. 39:42 We get used to working in particular ways. 39:46 We get habits. 39:49 We get into our comfort zones. 39:50 It's kind of, challenging sometimes to get ourselves 39:51 out of it, but it's so very worth it. 39:53 And this is a really cool time in our industry because 39:57 like I said no one really has this fully figured out. 39:59 So as you guys try the techniques, learn better ways to do things. 40:03 Definitely keep sharing them with us. 40:07 You know, let's create a better way to work together. 40:09 So my parting words of advice to you are these, don't go chasing waterfalls. 40:12 [LAUGH] Whatever tool or method you use, let it be one 40:18 that empowers your team and allows them to be true partners. 40:23 So, I can't wait to see what you 40:26 guys do, how you're adventures beyond the waterfalls go. 40:28 And I'll see you on the other side. 40:30 Thank you. 40:32 [SOUND] 40:34