Design Sprint: Planning, Requirements, Overview.

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're 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 your 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 will 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–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 talks, 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're 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. Will 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 storyboards 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.

Another good activity to validate your design is 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 seemed 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 okay. You can work towards delivering faster sprints as you get more practice. So, what's the take away?

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.