Bummer! This is just a preview. You need to be signed in with a Pro account to view the entire video.
Beyond the Waterfall: Rethinking How We Work40:37 with Maya Bruck
Designer passes comp to developer. Developer develops. Project done. Except this traditional waterfall approach is riddled with missed opportunities. Given the complexity of our web projects today, collaborative workflows can dramatically increase the efficiency and quality of the final product. Learn how to engage clients and the full breadth of your team from the beginning of the process, so that research, sketching, prototyping and beyond become a collaborative effort. Maya will share concrete tools and techniques she's used to make all members of the team (including clients!) active participants instead of passive recipients. All while having a lot more fun in the process.
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
You need to sign up for Treehouse in order to download course files.Sign up