WEBVTT 00:00:03.040 --> 00:00:06.462 In this video, we'll teach you how to use  Google's design sprint process 00:00:06.462 --> 00:00:08.776 to create great design faster. 00:00:13.680 --> 00:00:18.000 In an age of tight resources, companies  are more reluctant than ever to commit  00:00:18.000 --> 00:00:22.773 to big design projects without a thorough  understanding of their chances of success. 00:00:23.200 --> 00:00:28.252 Google has developed a method to make the design process fast and still offer valuable insight. 00:00:28.252 --> 00:00:32.155 The process developed by  Google Ventures is called a *design sprint*. 00:00:32.400 --> 00:00:37.360 It focuses on getting insights into *critical  business questions* within a very short timeframe 00:00:37.360 --> 00:00:39.274 – just five days. 00:00:39.274 --> 00:00:43.177 The process is based on *design thinking*, so it attempts to gain those insights 00:00:43.177 --> 00:00:47.515 via *rapid design*, *prototype development* and *user testing*. 00:00:47.681 --> 00:00:50.339 The design sprint is a five-phase process. 00:00:50.339 --> 00:00:54.000 Each phase takes approximately one day or eight  hours to perform. 00:00:54.000 --> 00:00:56.223 So, a sprint can be done in five days. 00:00:56.223 --> 00:00:59.038 The five phases of Google's design sprint are 00:00:59.038 --> 00:01:00.347 *understand*, 00:01:00.347 --> 00:01:02.133 *sketch*, *decide*, 00:01:02.133 --> 00:01:04.201 *prototype* and *validate*. 00:01:04.432 --> 00:01:08.690 The design sprint is a *linear process*, but you  are strongly encouraged to *make revisions* 00:01:08.690 --> 00:01:12.998 based on your first sprint and then *reiterate the prototype and validate phases*. 00:01:12.998 --> 00:01:17.211 You can also move further back to earlier phases and reiterate from there. 00:01:17.344 --> 00:01:20.244 In the following, we'll look at each step in more detail, 00:01:20.244 --> 00:01:24.123 but let's start by taking  a quick look at how to plan a design sprint. 00:01:27.040 --> 00:01:31.692 To ensure that the design sprint will be  successful, some *planning ahead* is required. 00:01:31.792 --> 00:01:35.221 Before the sprint begins, here are some things you should consider. 00:01:35.221 --> 00:01:39.665 You should *write a brief* to state the sprint's goal and bring everyone on the same page. 00:01:39.665 --> 00:01:46.073 You might also need to collect or *conduct user research* to get insights that can inform the work you do during the sprint. 00:01:46.207 --> 00:01:48.521 *Consider who should be on the sprint team.* 00:01:48.521 --> 00:01:52.847 Google's sprint process is designed to be run by teams rather than individuals. 00:01:52.973 --> 00:01:57.643 That means getting everyone together and ensuring  that they're all aiming in the same direction. 00:01:57.760 --> 00:02:04.288 The ideal team would include representatives from  all relevant functions and at all levels in the organization. 00:02:04.288 --> 00:02:09.163 You could also invite external people –  for instance, a representative user or stakeholder. 00:02:09.200 --> 00:02:12.880 You need a *suitable space* for the  sprint, typically somewhere bright, 00:02:12.880 --> 00:02:17.840 quiet, with lots of wall space and enough room  for people to move about will be suitable. 00:02:17.840 --> 00:02:21.876 You have to *gather supplies* for the sketching  and prototyping phases. 00:02:21.876 --> 00:02:25.630 Typically, you need office supplies like Post-its, blank sheets of paper, 00:02:25.630 --> 00:02:28.537 color markers, tape, and so on. 00:02:28.537 --> 00:02:34.090 Finally, you should choose a good *icebreaker exercise* to kick off your design sprint. 00:02:34.090 --> 00:02:37.051 Some members of your team might not have worked together before, 00:02:37.051 --> 00:02:40.494 so it's good to start off with an activity to warm people up. 00:02:45.840 --> 00:02:50.419 Now, let's take a look at each stage in the  execution of the actual sprint. 00:02:50.419 --> 00:02:55.509 In the understand session, your goal is to *create shared knowledge* about the business problem you're working on. 00:02:55.600 --> 00:03:00.384 You bring everyone together and unpack all of your  team's knowledge about the problem. 00:03:00.384 --> 00:03:05.360 *Lightning talks*, where knowledge experts use 10 to 15 minutes to share their knowledge about the problem, 00:03:05.360 --> 00:03:08.439 is an important part of the understand session. 00:03:08.439 --> 00:03:12.883 Typical topics for a lightning talk are *business goals*, *insights from user research*, 00:03:12.883 --> 00:03:17.498 an *overview of competitive products*, *technical opportunities*, and so on. 00:03:17.531 --> 00:03:23.194 As part of the lightning talk, it can be a good idea to have a presentation by someone from senior management 00:03:23.194 --> 00:03:26.941 outlining why the problem  you're working on is important to the business. 00:03:27.200 --> 00:03:32.702 Other typical activities of the understand phase are demonstrations of solutions that are already available, 00:03:32.702 --> 00:03:36.604 a detailed walkthrough of any proposed  solution, creating user journeys 00:03:36.604 --> 00:03:39.160 and performing user research. 00:03:39.176 --> 00:03:43.590 In the understand session, it's also  a good idea to be *clear on the metrics of success*. 00:03:43.600 --> 00:03:48.000 And remember, your metrics should be  useful and not pulled out of thin air. 00:03:48.400 --> 00:03:52.080 When you do the understand session, it's  important to involve the whole team. 00:03:52.080 --> 00:03:55.542 Don't let an individual or group dominate the  proceedings. 00:03:55.542 --> 00:03:58.493 The idea is to ensure everyone is on the same page, 00:03:58.493 --> 00:04:01.799 and the only way to do that  is if everyone is heard from. 00:04:02.154 --> 00:04:07.888 Once everyone is on the same page, it's time to split the team up and get them to start working on solutions. 00:04:11.440 --> 00:04:14.029 Sketch day is an *individual effort*. 00:04:14.029 --> 00:04:18.029 Everyone is tasked with coming up with a detailed solution to the problem. 00:04:18.029 --> 00:04:21.000 It's a good idea to do this on paper for two reasons. 00:04:21.120 --> 00:04:24.824 First, it's quick and it takes no time  to make changes. 00:04:24.824 --> 00:04:30.480 Second, everybody is able to sketch so they can participate even if they don't know any wireframing tools. 00:04:30.880 --> 00:04:34.167 For particularly complex, large-scale problem solving, 00:04:34.167 --> 00:04:39.875 you might want to break up the problem into *manageable chunks* and assign people a chunk rather than the whole problem. 00:04:40.160 --> 00:04:43.922 The aim of sketch day is to get as many ideas down as possible. 00:04:43.922 --> 00:04:49.337 If your team is large and you generate a ton of ideas, you might want to allocate an hour at the end of the day 00:04:49.337 --> 00:04:53.053 to quickly *reduce the number of ideas* to a more manageable number 00:04:53.053 --> 00:04:56.251 before you go into the third day of the sprint. 00:05:00.560 --> 00:05:05.458 As you might expect, decide day is all about  *making a decision* about which idea 00:05:05.458 --> 00:05:07.838 you're going to take to the prototype phase. 00:05:07.838 --> 00:05:10.640 But there's more to decide day than making a decision. 00:05:10.640 --> 00:05:15.963 It's also about working out how your solutions  might conflict with your objectives and abilities. 00:05:16.080 --> 00:05:19.200 You can start the day by quickly  listing any assumptions that you 00:05:19.200 --> 00:05:22.449 are making about things like budget, users, 00:05:22.449 --> 00:05:25.280 technology capacity and business drivers. 00:05:25.360 --> 00:05:29.880 Then it's time to review each idea and look at  the conflicts that it generates. 00:05:29.880 --> 00:05:33.045 You should have an objective in mind during your review. 00:05:33.045 --> 00:05:36.463 Would you be looking to take a single great idea forward to prototyping? 00:05:36.463 --> 00:05:40.314 Or are you going to pick, say, a top  5 and take those forward? 00:05:40.374 --> 00:05:43.844 You should be looking to constantly *refine* your list and remove ideas that 00:05:43.864 --> 00:05:46.847 simply aren't feasible early in the process. 00:05:47.440 --> 00:05:51.778 The entire team takes part in the decision process  by participating in discussions 00:05:51.778 --> 00:05:54.231 and through voting for ideas. 00:05:54.231 --> 00:05:57.383 Once you have an idea or ideas you  want to prototype, 00:05:57.383 --> 00:06:01.516 the last part of decide day is to *create some storyboards for your ideas*. 00:06:01.516 --> 00:06:06.402 The storyboard should show each interaction with the user in a step-by-step process, 00:06:06.402 --> 00:06:09.436 and they'll be your specification for your prototype. 00:06:09.520 --> 00:06:14.344 You might also want to define a *user story*  or two to help beef up the specification. 00:06:17.520 --> 00:06:21.889 As the title implies, on prototype day you have  a single day to *create a prototype* 00:06:21.889 --> 00:06:24.861 that your users can test on the final day. 00:06:24.861 --> 00:06:29.817 First of all, storyboard what you're going to build if you haven't already done that. 00:06:29.817 --> 00:06:33.038 To build a prototype, you can use any tool of your choice. 00:06:33.038 --> 00:06:36.284 Just pick one that you master enough for  rapid prototyping. 00:06:36.284 --> 00:06:40.346 The important thing is, don't attempt to learn a new tool on this day. 00:06:40.346 --> 00:06:43.237 Just use *whatever you're most comfortable with*. 00:06:43.280 --> 00:06:46.205 Finally, remember to *leverage the whole team*. 00:06:46.205 --> 00:06:50.354 Assign tasks and get everyone building or helping with something. 00:06:50.354 --> 00:06:54.322 Prototyping isn't just for the engineers.  Get people to document, 00:06:54.322 --> 00:07:00.156 write, review, plan a user test – any activity that contributes towards your end goal. 00:07:00.511 --> 00:07:03.716 On day 5, you *validate your idea*. 00:07:04.560 --> 00:07:07.580 The most important part of the validation  is to bring in a group 00:07:07.580 --> 00:07:10.335 of your end users to test your prototype. 00:07:10.335 --> 00:07:14.878 It's important that the entire team gets to *observe the users interact with the product* 00:07:14.891 --> 00:07:18.149 either directly  or through watching recordings of your test. 00:07:18.240 --> 00:07:23.877 A *cognitive walkthrough* or *brief usability  test* are great tools to use in this phase. 00:07:24.000 --> 00:07:29.040 Other good activities to validate your design –  to bring in experts and management stakeholders 00:07:29.040 --> 00:07:31.253 to review your idea. 00:07:31.253 --> 00:07:35.200 Everyone on the team should make  notes and record what they feel they've learned. 00:07:35.600 --> 00:07:39.120 You want to take these notes and  summarize them at the end of the day. 00:07:39.120 --> 00:07:43.355 This should help you decide if  anything needs iterating and improving. 00:07:46.320 --> 00:07:51.144 At the end of the final day, take some time with  the whole team to reflect on your experience. 00:07:51.171 --> 00:07:55.481 As Google puts it, there can be three possible  outcomes to a sprint: 00:07:55.481 --> 00:08:00.252 an *efficient failure* – perhaps your ideas didn't work so well, but you learned a lot in the process 00:08:00.252 --> 00:08:04.351 and saved your team a lot of time from going down the wrong path; 00:08:04.420 --> 00:08:09.191 a *flawed success* – perhaps some ideas worked nicely, while others didn't: 00:08:09.191 --> 00:08:13.632 this gives you insights on what  can be improved and what you could work on next; 00:08:13.760 --> 00:08:20.560 finally, an *epic win* – the ideas your team had have  shown great promise and seem to work really well. 00:08:20.560 --> 00:08:24.259 You're ready to move into a more serious  implementation phase. 00:08:24.259 --> 00:08:26.645 Either way, you can only win! 00:08:26.645 --> 00:08:30.611 Whether it's by avoiding failure, learning where more work needs to be put in 00:08:30.614 --> 00:08:36.992 or generating a killer design, you can only emerge from the design *wiser and more experienced*. 00:08:37.251 --> 00:08:42.255 The added bonus is that the time you've sacrificed  for this is relatively *short*. 00:08:42.322 --> 00:08:45.000 Though this is a tried-and-tested method by Google, 00:08:45.000 --> 00:08:48.762 it's also a relatively new concept adapted from Agile methods. 00:08:48.800 --> 00:08:53.567 It might take a few tries within your organization  to keep the sprint to five days. 00:08:53.600 --> 00:08:58.648 That's OK. You can work towards delivering faster sprints as  you get more practice. 00:08:58.648 --> 00:09:04.578 Google design sprints should help you take a process that currently takes months and make it lean and efficient.  00:09:04.800 --> 00:09:10.117 It's not a substitute for all design processes,  especially not for very complex products, 00:09:10.240 --> 00:09:14.701 but it's one that lets you ideate and test  ideas incredibly fast. 00:09:14.701 --> 00:09:19.275 A highly productive design team working in sprints is more likely to add business value 00:09:19.275 --> 00:09:23.196 and be recognized for their work within the larger organization. 00:09:23.664 --> 00:09:27.765 Finally, we encourage you to take a look at Google's Design Sprint Kit 00:09:27.765 --> 00:09:31.805 to get more ideas and tools for how to run your own design sprint.