Design sprint: from map to customer test in 5 days

In short

GV describes the design sprint as a five-day process for answering critical business questions through design, prototyping and testing ideas with customers.

The idea is simple: instead of building a product for months and only checking it afterwards, you build a realistic prototype in one week and show it to customers. The week ends with an answer. No code has been written along the way.

• Duration: five days, Monday to Friday.
• The days in order: Map, Sketch, Decide, Prototype, Test.
• To start, GV asks for two things: the right challenge and the right team.

From Google to GV: where the method comes from

According to GV’s sprint page, Jake Knapp started running design sprints at Google in 2010. In 2012 he brought the method to GV. “Google design sprint” and “GV design sprint” therefore mean the same process.

In 2016 the process became a book: Jake Knapp, John Zeratsky and Braden Kowitz, Sprint: How to Solve Big Problems and Test New Ideas in Just Five Days. The US edition was published on March 8, 2016 by Simon & Schuster and has 288 pages.

The UK edition was published by Bantam Press. The publisher’s page presents the authors as three partners at Google Ventures and says the process has been proven at more than 100 companies. GV’s page calls the book a New York Times bestseller.

A design sprint in 5 days: Monday to Friday

Each day has exactly one job, and the next day starts with its output. Press a day in the planner below to see its goal and output.

Sprint planner

Day 1: Monday Map

Goal

Map out the problem and pick an important area to focus on for the week.

Activities

• Start at the end: the team agrees on a long-term goal.
• Draw a map of the challenge.
• Ask the experts in the company: everyone shares what they know.
• Pick a target: an area that can be solved in a week.

Output of the day

A written long-term goal, a one-page map and a marked target on it.

Day 2: Tuesday Sketch

Goal

Come up with solution ideas for the chosen target. The day starts with inspiration.

Activities

• Review existing ideas that can be adapted and improved.
• In the afternoon, each person sketches a solution alone, following a four-step process.
• Start finding customers who fit the target profile for Friday’s test.

Output of the day

A solution sketch from each person. The search for Friday’s customers has started.

Day 3: Wednesday Decide

Goal

Critique the sketches and choose the ones most likely to reach the long-term goal.

Activities

• In the morning, the sketches are critiqued one by one.
• The solutions closest to the goal are chosen.
• In the afternoon, the choice becomes a storyboard: a step-by-step plan of the prototype.

Output of the day

A storyboard that shows every screen of Thursday’s prototype in order.

Day 4: Thursday Prototype

Goal

Turn the storyboard into a realistic prototype in one day. GV calls this approach “fake it”.

Activities

• Build only the facade the customer sees, not what lies behind it.
• Finalise the test plan for Friday.
• Write the interview guide.

Output of the day

A prototype you can show customers and a finished interview guide.

Day 5: Friday Test

Goal

Talk to customers and watch how they react to the prototype.

Activities

• One-on-one interviews with customers from the target profile.
• Watch how customers react to the prototype.
• At the end of the day, see how far there is still to go and what comes next.

Output of the day

An answer to the week’s question and a decision on the next step.

Press a day or move between the days with the arrow keys: the goal, activities and output of the day appear below. Goals and activities are based on GV’s sprint page, shortened by me. The output lines are my wording.

Monday: Map

The week starts at the end. The team first agrees on a long-term goal and then draws a map of the challenge. In the afternoon, the experts in the company share what they know, and the team picks a target that can be solved in a week.

Tuesday: Sketch

The day starts with inspiration: the team reviews existing ideas and collects what can be adapted. In the afternoon, each person sketches alone. In GV’s four-step sketching process, critical thinking counts for more than drawing talent.

The same day, the search for customers for Friday’s test begins too. Anyone who leaves this to the last day stands in an empty room on Friday morning.

Wednesday: Decide

By the end of Tuesday there is a pile of solutions on the table. On Wednesday morning they are critiqued, and the ones closest to the long-term goal are chosen. In the afternoon, the chosen ideas become a storyboard: a step-by-step plan of the prototype.

Thursday: Prototype

GV describes this day with a “fake it” approach: the storyboard becomes a prototype that looks realistic to customers. According to GV, this is done in one day. The same day, the team sets the test plan and writes the interview guide.

Here the prototype is a clickable interface made of design screens. What level of detail is enough is described in the guide wireframe, mockup and prototype.

Friday: Test

The team talks to customers and watches how they react to the prototype. According to GV, this test makes the entire sprint worthwhile. At the end of the day you know how far there is still to go and what comes next.

How to set up the interviews is in the usability testing guide; how many people to test with, in the article how many users to test.

Before the start: setting the stage

GV asks you to set the stage before the sprint. That takes the right challenge, the right team, and time and space set aside for the sprint.

The right challenge is a question whose answer is unclear and whose wrong answer is expensive. “Will the new sign-up flow lose customers who come from the store?” is a good sprint question. You don’t give up a week for “What colour should the button be?”.

Time and space are what teams underestimate most often. I insist that calendars are clear in the sprint week and that one room belongs to the team all week. The map and sketches on the walls should stay in that room.

Who takes part: decider and facilitator

GV’s page only talks about the “right team” and doesn’t list who belongs to it. The Wikipedia article on design sprints suggests a team of 4 to 7 people. The article gives no source for this suggestion, so I read it as a rough range.

The same article lists these roles: facilitator, designer, decision maker, product manager, engineer and someone from a core business area such as marketing or operations. It adds that in a startup, the CEO often decides.

In a sprint I settle two roles before anything else:

Decider

The person who has the last word on Wednesday about which solution is tested. If they aren’t in the room, the decisions are reopened the following Monday. If they can’t be there all week, they should at least be there on Monday morning and on Wednesday.

Facilitator

Keeps an eye on time and pulls fraying discussions together. If the day’s output isn’t on the table in the evening, they are responsible. To stay neutral, they shouldn’t be the same person as the decider.

I fill the remaining seats with people who know the product from different angles. Someone who talks to customers in support every day is often the most valuable expert at the table.

How it relates to the Double Diamond and design thinking

I see the design sprint as a timebox. It takes the familiar design steps and packs them into a week.

In the language of the Double Diamond, Monday narrows the problem, Tuesday opens up solution options, and Wednesday narrows them again. Thursday and Friday are a small-scale test phase. This mapping is my interpretation. It isn’t on GV’s page.

Design thinking is a broader approach and can stretch over months of a project. The design sprint is one week of that approach devoted to a single question. I use both together: within a long project, the sprint quickly answers the riskiest question.

An example week: the city water utility app

The week below is a made-up example, not a real project. It is meant to show how the days connect.

A city water utility is frustrated that reports of water leaks come in by phone. The app has a report form, but it is hardly used. The team takes a week and writes the question down like this: why don’t residents prefer to report a leak through the app?

• Monday: The long-term goal is “Most leak reports come in through the app”. A call center agent is heard as an expert. The waiting after the report is chosen as the target.
• Tuesday: Everyone sketches a solution. One suggests reporting by photo, another status tracking by text message.
• Wednesday: The decider, the head of digital services, chooses status tracking. The storyboard covers six screens.
• Thursday: The six screens become a clickable prototype. No system runs behind it.
• Friday: The team talks to five residents. It sees that the problem isn’t the form but the silence afterwards.

On Friday evening the team has a decision: status tracking comes first. Shortening the form can wait.

When it fits and when it doesn’t

A design sprint helps when you face a big decision. You don’t know the answer, and a wrong decision means months of wasted development. A new product idea or a sign-up flow being redesigned are examples.

If the problem and solution are clear, there is no need for a five-day test; then I go straight to implementation. If the product is live but nobody knows where it is going wrong, a UX audit shows the problem faster.

The difference between a GV sprint and the Design & Ship Sprint

The names are similar, but the two do different things. GV’s design sprint takes five days and ends with a prototype and a customer test; no production code is written. The ux.center Design & Ship Sprint takes two weeks and includes code that goes live alongside the design.

Common mistakes

Not getting the decider into the room. After the sprint, a manager who was never in the room changes the solution chosen on Wednesday. The whole week is lost.

Breaking up the week. If the team goes to other meetings in the afternoon, the sprint becomes five half days.

Polishing the prototype. A team that wants to build a real product on Thursday stands there on Friday morning with half a prototype. The facade the customer sees is enough.

Ending Friday without a test. If no customer can be found, the team rates the prototype internally. What remains is an opinion, and the week’s question stays unanswered. That is why I start the customer search on Tuesday.

My note

For me, the most valuable moment in a design sprint is the Monday when the long-term goal is written down. The team agrees on the same sentence for the first time. In most teams, this agreement had never been put in writing before.

Whether I run a sprint depends on the size of the question. The team’s enthusiasm isn’t a measure. Giving up five days and six people’s calendars for a small question is expensive. Sometimes a two-hour sketching session and three user interviews give the same answer.

On Friday evening you have a decision. If the prototype worked, the real work starts the following Monday: firming up the design and turning it into code.