Design Sprints

In this video, we'll teach you how to use  Google's design sprint process to create great design faster. In an age of tight resources, companies  are more reluctant than ever to commit  to big design projects without a thorough  understanding of their chances of success. Google has developed a method to make the design process fast and still offer valuable insight. The process developed by  Google Ventures is called a *design sprint*.

It focuses on getting insights into *critical  business questions* within a very short timeframe – just five days. The process is based on *design thinking*, so it attempts to gain those insights via *rapid design*, *prototype development* and *user testing*. The design sprint is a five-phase process. Each phase takes approximately one day or eight  hours to perform. So, a sprint can be done in five days. The five phases of Google's design sprint are *understand*,

*sketch*, *decide*, *prototype* and *validate*. The design sprint is a *linear process*, but you  are strongly encouraged to *make revisions* based on your first sprint and then *reiterate the prototype and validate phases*. You can also move further back to earlier phases and reiterate from there. In the following, we'll look at each step in more detail, but let's start by taking  a quick look at how to plan a design sprint. To ensure that the design sprint will be  successful, some *planning ahead* is required.

Before the sprint begins, here are some things you should consider. You should *write a brief* to state the sprint's goal and bring everyone on the same page. You might also need to collect or *conduct user research* to get insights that can inform the work you do during the sprint. *Consider who should be on the sprint team.* Google's sprint process is designed to be run by teams rather than individuals. That means getting everyone together and ensuring  that they're all aiming in the same direction. The ideal team would include representatives from  all relevant functions and at all levels in the organization.

You could also invite external people –  for instance, a representative user or stakeholder. You need a *suitable space* for the  sprint, typically somewhere bright, quiet, with lots of wall space and enough room  for people to move about will be suitable. You have to *gather supplies* for the sketching  and prototyping phases. Typically, you need office supplies like Post-its, blank sheets of paper, color markers, tape, and so on. Finally, you should choose a good *icebreaker exercise* to kick off your design sprint.

Some members of your team might not have worked together before, so it's good to start off with an activity to warm people up. Now, let's take a look at each stage in the  execution of the actual sprint. In the understand session, your goal is to *create shared knowledge* about the business problem you're working on. You bring everyone together and unpack all of your  team's knowledge about the problem.

*Lightning talks*, where knowledge experts use 10 to 15 minutes to share their knowledge about the problem, is an important part of the understand session. Typical topics for a lightning talk are *business goals*, *insights from user research*, an *overview of competitive products*, *technical opportunities*, and so on. As part of the lightning talk, it can be a good idea to have a presentation by someone from senior management outlining why the problem  you're working on is important to the business. Other typical activities of the understand phase are demonstrations of solutions that are already available,

a detailed walkthrough of any proposed  solution, creating user journeys and performing user research. In the understand session, it's also  a good idea to be *clear on the metrics of success*. And remember, your metrics should be  useful and not pulled out of thin air. When you do the understand session, it's  important to involve the whole team. Don't let an individual or group dominate the  proceedings. The idea is to ensure everyone is on the same page, and the only way to do that  is if everyone is heard from.

Once everyone is on the same page, it's time to split the team up and get them to start working on solutions. Sketch day is an *individual effort*. Everyone is tasked with coming up with a detailed solution to the problem. It's a good idea to do this on paper for two reasons. First, it's quick and it takes no time  to make changes. Second, everybody is able to sketch so they can participate even if they don't know any wireframing tools.

For particularly complex, large-scale problem solving, you might want to break up the problem into *manageable chunks* and assign people a chunk rather than the whole problem. The aim of sketch day is to get as many ideas down as possible. 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 to quickly *reduce the number of ideas* to a more manageable number before you go into the third day of the sprint. As you might expect, decide day is all about  *making a decision* about which idea

you're going to take to the prototype phase. But there's more to decide day than making a decision. It's also about working out how your solutions  might conflict with your objectives and abilities. You can start the day by quickly  listing any assumptions that you are making about things like budget, users, technology capacity and business drivers. Then it's time to review each idea and look at  the conflicts that it generates. You should have an objective in mind during your review.

Would you be looking to take a single great idea forward to prototyping? Or are you going to pick, say, a top  5 and take those forward? You should be looking to constantly *refine* your list and remove ideas that simply aren't feasible early in the process. The entire team takes part in the decision process  by participating in discussions and through voting for ideas. Once you have an idea or ideas you  want to prototype, the last part of decide day is to *create some storyboards for your ideas*.

The storyboard should show each interaction with the user in a step-by-step process, and they'll be your specification for your prototype. You might also want to define a *user story*  or two to help beef up the specification. As the title implies, on prototype day you have  a single day to *create a prototype* that your users can test on the final day. First of all, storyboard what you're going to build if you haven't already done that. To build a prototype, you can use any tool of your choice.

Just pick one that you master enough for  rapid prototyping. The important thing is, don't attempt to learn a new tool on this day. Just use *whatever you're most comfortable with*. Finally, remember to *leverage the whole team*. Assign tasks and get everyone building or helping with something. Prototyping isn't just for the engineers.  Get people to document, write, review, plan a user test – any activity that contributes towards your end goal.

On day 5, you *validate your idea*. The most important part of the validation  is to bring in a group of your end users to test your prototype. It's important that the entire team gets to *observe the users interact with the product* either directly  or through watching recordings of your test. A *cognitive walkthrough* or *brief usability  test* are great tools to use in this phase. Other good activities to validate your design –  to bring in experts and management stakeholders to review your idea.

Everyone on the team should make  notes and record what they feel they've learned. You want to take these notes and  summarize them at the end of the day. This should help you decide if  anything needs iterating and improving. At the end of the final day, take some time with  the whole team to reflect on your experience. As Google puts it, there can be three possible  outcomes to a sprint: an *efficient failure* – perhaps your ideas didn't work so well, but you learned a lot in the process

and saved your team a lot of time from going down the wrong path; a *flawed success* – perhaps some ideas worked nicely, while others didn't: this gives you insights on what  can be improved and what you could work on next; finally, an *epic win* – the ideas your team had have  shown great promise and seem to work really well. You're ready to move into a more serious  implementation phase. Either way, you can only win! Whether it's by avoiding failure, learning where more work needs to be put in

or generating a killer design, you can only emerge from the design *wiser and more experienced*. The added bonus is that the time you've sacrificed  for this is relatively *short*. Though this is a tried-and-tested method by Google, it's also a relatively new concept adapted from Agile methods. It might take a few tries within your organization  to keep the sprint to five days. That's OK. You can work towards delivering faster sprints as  you get more practice. Google design sprints should help you take a process that currently takes months and make it lean and efficient. 

It's not a substitute for all design processes,  especially not for very complex products, but it's one that lets you ideate and test  ideas incredibly fast. A highly productive design team working in sprints is more likely to add business value and be recognized for their work within the larger organization. Finally, we encourage you to take a look at Google's Design Sprint Kit to get more ideas and tools for how to run your own design sprint.

Great agile teams commit to iterating on features. Now, it's interesting. When we did a bunch of  research on agile teams back in 2019 and 2020, we found one of the biggest complaints  people had was that their teams never went back and improved things that they'd already built. They would ship something, move it to the Done column and then never look at it again. Sometimes, they didn't even look at metrics to see if anybody was even *using* the feature.

The really unfortunate thing was that teams often shipped small or stripped-down versions of features just to get them out the door and then they *still* never went back and approved them. Obviously, this led to absolute nightmare products full of half-finished things that were inconsistent and didn't really make sense as a whole product. The thing is, that's one of the least agile  things you can do. The whole point of lightweight methodologies is that we're constantly getting things in front of users, getting feedback and improving them.

Do we sometimes ship things to  people that aren't quite perfect? Yeah – all the time. But we do it with the understanding that  we're shipping it in order to learn something, and once we learn something, we're going to go back and improve the product based on what we learned, and then we'll do it again... and then we'll do it again. That is iteration, and it's pretty much the core of agile. Great teams learn from their users and keep improving their product by iterating on features. They don't just keep churning out new half-baked features like they're some kind of widget factory.

So, teams that are truly committed to agile methodologies should be iterating and improving their user experience and their codebase *constantly*.