Design Sprint
The Design Sprint is a five-day method that takes a small team from a business question to a prototype tested by customers. Jake Knapp created it at Google in 2010, then developed it at Google Ventures (GV). He published it in 2016 with John Zeratsky and Braden Kowitz in the book Sprint. On Monday, the team maps the problem and picks a target. On Tuesday, each person sketches solutions alone. On Wednesday, a Decider picks one or more solutions. The team then writes the test scenario. On Thursday, the team builds a facade prototype that imitates the product with nothing built behind it. On Friday, five customers try it in one-to-one interviews.
Goal
The Design Sprint answers a specific business question in one week. The team tests a solution with customers before anyone builds it. An organisation that hesitates between several ideas often debates them for months. The Design Sprint replaces that debate with a decision on Wednesday and five observations on Friday.
The decision it prepares concerns the next step for the project: develop a tested solution, correct it or drop the idea before investing in it. The week produces:
- the long-term goal, the sprint questions and the map of the problem with its target;
- the solution sketches and the Decider's choice;
- the storyboard and the prototype built from it;
- the Friday grid, which answers each Monday question from what the five customers did.
The name invites confusion. The Scrum Sprint is a development iteration of one month or less that delivers a product Increment (Scrum Guide 2020, section "The Sprint"). The Design Sprint delivers a decision and a finding. A Scrum team can run one before it writes the first items of its backlog.
Usage
When to use it
- A costly decision rests on an untested idea: five days against months of development.
- Several departments each defend their own solution: the Decider decides on sketches, then the customers respond.
- A new service or a customer journey to redesign: the facade prototype takes one day to build.
- A steep hierarchy: solitary sketching and silent voting put a junior's idea on the same level as a manager's.
- Target customers you can reach: five people with the right profile must come on Friday.
- Five full days blocked for the whole team: in a room or remotely on a digital whiteboard.
When not to use it
- The team has not yet identified the problem: frame it first through interviews and observation.
- The solution is already decided and funded: build it, then measure its effect with an A/B test.
- Half a day can settle the question: a brainstorming session followed by dot voting is enough.
Description
The Design Sprint is a fixed sequence. Each day answers one question and delivers what the next day needs.
The roles
The Decider owns the decision in the organisation: a director, a product manager, a head of department. The Decider picks the target on Monday and the solutions on Wednesday. On Friday, the Decider answers yes or no to each Monday question and decides what comes next. A Design Sprint can have two Deciders. A Decider who cannot attend the whole week names a delegate with the authority to decide. A Decider who delegates to someone without real authority wastes the week: the following Monday, the real hierarchy reopens the debate.
The facilitator runs the week. The facilitator keeps time, moves the team from one activity to the next and takes notes on the whiteboard. We advise giving these two roles to two people: whoever decides cannot keep time on a debate they arbitrate.
The team has seven people at most. It brings together the skills the solution depends on: finance, sales, customer service, technology, design. The team questions the other experts on Monday only.
The setting
The team blocks five consecutive days in its calendars. The day runs from 10:00 to 17:00 with an hour for lunch around 13:00. The team takes a short break around 11:30 and another around 15:30. Friday starts at 9:00 to fit in the interviews. Everyone closes their email and social media during the Design Sprint. Anyone who must check their messages leaves the room or waits for the break.
Each activity has a duration fixed in advance as in time boxing. The facilitator shows a timer that everyone can see. Each person writes their ideas alone and in silence, then the team compares them. The method does not use out-loud brainstorming.
Why these constraints
The authors state it: without a Decider, decisions do not hold. The person who chooses also holds the budget and the next step of the project. In our experience, a team vote produces a compromise that nobody then defends in front of management.
The sketch is anonymous and the vote silent. The team therefore judges the idea on paper before it hears its author. Eloquence and rank carry less weight.
The fixed duration stops anyone from reopening the previous day's choices. The five customers come on Friday. The team therefore decides with what it knows.
Before the week
The Decider and the facilitator choose the problem. They book a room with two large whiteboards for the week. For a remote Design Sprint, they open a digital whiteboard. They also book a second room for the Friday interviews. They invite the Monday experts. During the week, one person spends one to two hours a day recruiting the five customers. That person uses a screening questionnaire that does not give away the profile sought. For a rare profile, we start before Monday: finding five people free on a given Friday takes more than four days.
Monday: map and pick a target
The team starts at the end. It writes the long-term goal: where the organisation wants to be in six months, a year or five years thanks to this project. The sentence is optimistic and fits on one line.
The team then looks for ways the goal could fail. Each reason for failure becomes a sprint question: "Does the customer understand the affordability calculation without an adviser?" Friday must answer it.
The team draws the map of the problem. The actors are on the left: the customers and the other parties involved. The end is on the right: the customer has obtained what they wanted. Between the two, arrows link five to fifteen steps. The map is simpler than a customer journey map and records neither emotions nor touchpoints. The team uses it to choose where to focus the week.
The team interviews the experts one by one. Each one explains what they know about the problem: a sales adviser, a support manager, a lawyer, a developer. Each interview lasts 15 to 30 minutes. The series takes two to three hours. The team corrects the map as the experts speak. Meanwhile, everyone writes what they hear as How Might We notes. The team sticks these notes on the wall, groups them by theme, ranks them by dot voting and places the notes with the most votes on the map. For this vote, each person has two votes.
Finally, the Decider picks the target: one customer and one moment on the map. The rest of the week covers that moment alone.
Tuesday: look, then sketch alone
The morning opens with lightning demos. Each member spends three minutes presenting an existing solution that is relevant to the target: a competitor's product, a service from another sector, an idea abandoned inside the company. The facilitator draws the useful element of each demo on the whiteboard. The team builds its own solutions on these elements.
Before lunch, the team decides who sketches which part of the map (divide or swarm). For a wide target, it assigns each part to one person. For a narrow target, everyone sketches the same part.
In the afternoon, each person sketches alone in four steps:
- notes (20 minutes): each person rereads the wall and copies what matters;
- ideas (20 minutes): quick private doodles;
- Crazy 8s (8 minutes): eight variants of the best idea at one minute per variant;
- the solution sketch (30 to 90 minutes): the detailed solution in three panels. It is anonymous and clear enough to be read without its author.
The sketch can be clumsy. Its text must be real copy: the Writer reuses it on Thursday.
Wednesday: decide
In the morning, the team reviews the sketches without open debate. The steps follow in this order:
- the Art Museum: the team puts the sketches up on the wall like a gallery;
- the heat map: each person reads all the sketches in silence and sticks one to three small dots beside each part that interests them;
- the speed critique: three minutes per sketch. The team discusses the parts that the dots have marked. The facilitator notes the standout ideas and the objections. At the end, the author says what the team missed;
- the straw poll: each person puts one vote on the solution they prefer;
- the supervote: the Decider places three large dots marked with their initials on the solutions they keep.
The Decider keeps one or more solutions. If the solutions conflict, the team builds two or three competing prototypes and tests them on Friday: this is the Rumble. The other sketches wait on a list for later.
The heat map and the two votes apply dot voting. The team's vote informs the Decider without binding them.
In the afternoon, the team draws the storyboard on a whiteboard: a grid of about fifteen comic-strip panels. It tells what the customer will experience on Friday from start to finish. The first panel is the opening scene: the way the customer usually comes across the product. The storyboard sets the content of the prototype. An idea that is not on it does not get built on Thursday.
Thursday: prototype a facade
The prototype only has to look real for the length of an interview. GV sums up this principle as "fake it". Depending on the solution, the facade is a series of clickable screens, a web page, a brochure or the script of a service counter played by a colleague. It is a throw-away prototype: the team discards it after the test. You will find the other forms of mock-up under prototyping.
The team splits the work by role. The Makers build the screens or the pieces. The Stitcher joins the pieces and keeps them consistent. The Writer writes the text. The Asset Collector gathers the images, logos and content. The Interviewer prepares the Friday interview guide from the storyboard and the Monday questions.
Around 15:00, the team walks through the prototype in storyboard order. The Interviewer and the Decider attend. This rehearsal finds the dead link and the placeholder text before a customer sees them.
Friday: test with five customers
The Interviewer receives the five customers from the target profile one after the other. The authors structure the interview in five acts. The Interviewer puts the customer at ease, asks about their context and introduces the prototype. Next, the Interviewer asks the customer to complete tasks while thinking aloud. Finally, the Interviewer collects the customer's impressions. The Interviewer does not sell the solution. The Interviewer asks the customer what they are looking for, what they think they see and what they would do next.
The rest of the team watches the interview on video from another room. Sound and image go only from the interview room to the team room. During the interview, each person writes on sticky notes what the customer does and says. A grid on the whiteboard shows the five customers in its columns and the Monday questions or the prototype's hypotheses in its rows. After each interview, each person votes yes or no on each question for that customer. The Decider weighs these votes and settles the cell. At the end of the day, the Decider gives a single yes or no per question. Each person then writes their immediate opinion and the next steps they propose. The Decider decides what comes next.
An elicitation interview asks a stakeholder about their needs. The Friday interview observes what a customer does when faced with a solution.
The number five comes from usability testing. In 2000, Jakob Nielsen calculated that five users find about 85% of an interface's usability problems and that a single user finds 31%. The calculation holds for comparable users. Two very different customer profiles call for three or four people each. Nielsen does not mention the Design Sprint.
What makes a Design Sprint fail
Choosing the problem during the week. A team that spends Monday wondering what to work on has no target by Wednesday.
A team that comes and goes. The member who misses Monday votes on Wednesday on a map they did not build. They reopen points already settled.
Polishing the prototype. A team that wants a polished prototype does not finish it on Thursday. The Friday customer reacts to the content and the flow. The finish goes unnoticed.
Reading five interviews as proof. Five customers reveal obstacles and misunderstandings. They measure neither market share nor purchase intent. A Design Sprint gives a first finding on five people. Nielsen recommends several small tests over a single large one. A second test on a corrected prototype confirms or refutes the first.
Promising a proven result. The published cases come mostly from the method's authors and from teams that have practised it. We know of no controlled study that compares a Design Sprint with another way of deciding. The method guarantees only a decision and a test in one week.
AI considerations
Before the week, an assistant prepares the lightning demos. It lists solutions that address a neighbouring problem in other sectors. Each member then checks the one they present against the product itself. An assistant sometimes describes a feature that does not exist.
On Monday, the assistant transcribes the expert interviews and summarises them by map step. The team keeps its own How Might We notes. An AI-generated list would replace the listening that produces them.
On Thursday, the assistant fills the facade. It drafts the screen copy, the error messages and the confirmation emails. It produces the illustrative images and the dummy data. The Writer reviews every text. Vague text in the prototype provokes a vague reaction on Friday.
On Friday, the assistant transcribes the interviews and proposes where each quote goes in the grid. The team compares this sorting with what it saw. A twenty-second hesitation over a button appears in no transcript.
The solitary sketch on Tuesday stays human. Sketches drawn from the same model resemble each other. The heat map then has nothing left to compare. The Decider's choice and the reading of Friday's reactions stay human too.
The recordings show identifiable customers. The Interviewer obtains their written consent before recording. No recording goes to an AI service that the organisation has not approved.
Examples
The grid below closes a Design Sprint that a cantonal bank ran on an online mortgage agreement in principle.
| Monday question | Customer 1 | Customer 2 | Customer 3 | Customer 4 | Customer 5 | Decider's answer |
|---|---|---|---|---|---|---|
| Q1. Does the customer understand the affordability calculation without an adviser? | no: takes the imputed rate of 5% for their future rate | yes: redoes the calculation alone | no: takes the imputed rate of 5% for their future rate | no: looks for a phone number | yes: understands after the tooltip | No. Three customers out of five fail. Two of them misread the imputed rate. |
| Q2. Does the customer upload their documents before a first contact? | yes: payslip and debt enforcement register extract | yes: everything | yes: everything | no: refuses before speaking to someone | yes: everything | Yes. Four customers out of five. |
| Q3. Does the customer trust an agreement in principle issued online? | no: asks whether it commits the bank | yes: "same as for my car lease" | no: asks whether it commits the bank | no: wants a signature | no: asks whether it commits the bank | No. Four customers out of five: three do not know whether the agreement commits the bank, one wants a signature. |
The third row answers no for a reason that the prototype created: the text does not say what the agreement commits the bank to. The Decider has the text rewritten and tested again before any development.
Visualisations
The week diagram shows what each day produces for the next. It marks the three moments when the Decider decides and shows Tuesday's many ideas narrowing to the solutions chosen and prototyped on Thursday. The Monday map follows an online request for a mortgage agreement in principle and shows the target that the Decider circled. The Wednesday diagram separates what the team signals from what the Decider chooses. The Friday grid shows the deliverable.
Cost
| Dimension | Level | Justification |
|---|---|---|
| Preparation | Medium | Five days to block for a team of seven people at most, five customers to recruit, experts to invite, a room to book. |
| Execution | High | Up to seven people for five days make up to 35 person-days. On top of that come the Monday expert interviews and one to two hours of recruiting per day. Each of the five customers receives a voucher. |
| Documentation | Low | The team photographs the walls. The Friday grid and the decision fit on one page. |
Tools
In a room, the team needs two large whiteboards, yellow sticky notes, markers, dots in two sizes and a timer that everyone can see. Each person sketches on A4 sheets.
On Thursday, the prototyping tool depends on the facade. The authors advise against everyday tools: these are built for quality. The authors ask instead for rough, fast and flexible tools. Presentation software such as Keynote or PowerPoint is enough for clickable screens. Figma works if it stays a quick sketching tool. A word processor is enough to lay out a brochure.
On Friday, a video-conferencing tool relays the interview to the observation room. The authors run most of their Design Sprints remotely. In a remote sprint, a digital whiteboard such as Miro or Mural replaces the walls. Working in the same room adds the sketches displayed side by side, the shared silence and everyone's attention.
Sources
No standards body defines the Design Sprint. Its authors at GV define the method.
- Knapp, Jake, Zeratsky, John and Kowitz, Braden (2016), Sprint: How to Solve Big Problems and Test New Ideas in Just Five Days, Simon & Schuster: the original book of the method.
- Knapp, Jake and Zeratsky, John, Design Sprint: How to solve big problems and test new ideas in just five days, Character Capital: the authors' hour-by-hour checklist, from choosing the Decider to the Friday grid.
- GV, The Design Sprint: the official summary of the week, from Monday's long-term goal to Friday's interviews.
- Character, Sprint: the book's page that Jake Knapp and John Zeratsky maintain. It dates the creation of the method at Google to 2010.
- Nielsen, Jakob (2000), Why You Only Need to Test with 5 Users, Nielsen Norman Group: the share of usability problems that one user and five users find; the calculation holds only for comparable users.
- Schwaber, Ken and Sutherland, Jeff (2020), The Scrum Guide, section "The Sprint": the Scrum Sprint and its duration of one month or less.