Google Design Sprint: The Five-Day Process Explained

Created by Jake Knapp - https://www.gv.com/sprint/

Overview

The design sprint is a five-day process in which a small team maps a problem, sketches solutions, decides on one, builds a realistic prototype and tests it with target customers. GV describes it as a process "for answering critical business questions through design, prototyping, and testing ideas with customers" and calls it a "greatest hits" of business strategy, innovation, behavior science and design thinking (GV: The Design Sprint). The name "Google design sprint" comes from where it started: Jake Knapp began running design sprints at Google in 2010, with teams such as Chrome, Google Search and Google X, and brought them to GV in 2012 (GV).

Knapp's own account of the early years is in his October 2012 post The product design sprint: A five-day recipe for startups. There he says he had planned and run over 40 sprints, first at Google and then with GV portfolio companies, and that the model is based on the design thinking structure championed by IDEO and Stanford's d.school. His stages then were Understand, Diverge, Decide, Prototype and Validate. He describes two lessons that shaped the process: in his experience the most successful ideas came from individuals working alone, and choosing ideas by consensus tended to produce compromises.

At GV the process became a team effort. The GV page credits Braden Kowitz with story-centered design, Michael Margolis with a way to get clear research results in one day, John Zeratsky with starting at the end and measuring results against each business's key metrics, and Daniel Burka with an entrepreneur's view of whether each step made sense. Knapp, Zeratsky and Kowitz published the process in 2016 as the book Sprint: How to Solve Big Problems and Test New Ideas in Just Five Days. The book page at Character Capital, where Knapp and Zeratsky are now founders and general partners, gives the same authors and the 2016 date.

The published design sprint process assigns one job to each day. On Monday the team sets a long-term goal, lists the risks as questions, draws a map of how customers move through the problem, interviews experts and picks a target. On Tuesday everyone reviews existing solutions and sketches alone. On Wednesday the team critiques the sketches, the Decider chooses, and the team turns the winners into a storyboard. On Thursday the team builds a prototype that only has to look real. On Friday five customers use it in one-on-one interviews while the rest of the team watches. The current day-by-day checklist, with times and supplies, is in Knapp and Zeratsky's Design Sprint guide.

Two roles hold the week together. The Decider makes the calls that would otherwise turn into debate, and the checklist says that without a Decider "decisions won't stick." The Facilitator manages time, conversations and the overall process. The sprint team is seven people or fewer, with different skills plus the people who work on the project day to day, and extra experts who cannot stay all week are booked for short interviews on Monday afternoon (Design Sprint guide).

Several versions of the process now circulate, and it helps to know which one a guide describes. The five-day checklist above is the original published method. Google's open-source Design Sprint Kit describes a flexible framework built for internal Google teams, organised into six phases, and points readers to the Sprint book for the five-day version. AJ&Smart's Design Sprint 2.0 compresses the week to four days (AJ&Smart). The section on variants below compares them.

The method is built for one kind of situation: a question that matters, that the team cannot answer from what it already knows, and that a realistic surface can test before anything is built. GV's framing is that the sprint lets a team see customer reactions to a finished-looking product "before making any expensive commitments." Hamster can hold the sprint's long-term goal, sprint questions and test scorecard as shared context, so the team and its agents work from the same record after the week ends.

Core Principles

Start at the End

The sprint opens with the long-term goal and the ways the project could fail, before anyone discusses solutions. The checklist asks the team to "get optimistic" about where it wants to be and then "get pessimistic" and turn each fear into a question it could answer that week (Design Sprint guide). Those sprint questions become the rows of Friday's scorecard, so the test measures what the team said mattered on Monday. A sprint that skips this step tends to test whatever is easiest to prototype.

Work Alone Together

Ideas are generated by individuals working silently, in the same room, before any group discussion. Knapp wrote in 2012 that the ideas from his group brainstorming workshops "didn't go anywhere," and that the most successful ideas tended to come from individuals given heads-down time (Knapp, 2012). Sketches are anonymous and must explain themselves, which keeps the loudest or most senior voice from winning by default. Discussion happens later, and it is about ideas that already exist on paper.

The Decider Decides

One person with real authority makes the final calls: the target on Monday, the solutions to prototype on Wednesday and the verdict on each question on Friday. Knapp's early workshops chose winners by consensus, and he found that consensus "tends to compromise" rather than picking the bold or unique idea. The current checklist says that if the Decider cannot attend the whole week, they should appoint a delegate who can (Design Sprint guide). The team still votes, and the Decider weighs those votes before choosing.

Prototype a Facade

Thursday's prototype only has to look real to the customer. GV calls this a "fake it" philosophy: a realistic facade is enough to test with customers, and focusing on the customer-facing surface is what lets a team finish in one day (GV). The checklist's term is "Goldilocks quality," enough quality to evoke honest reactions and no more. Because the prototype is disposable, a failed test costs one day of work.

Test With Five Target Customers

Friday's test uses five one-on-one interviews with people who fit the target profile, all on the same day. The checklist says that after five interviews "big patterns will emerge" (Design Sprint guide). The number matches Jakob Nielsen's advice to test with no more than five users and run many small tests, since "the first study with five participants has found 85% of the usability problems" in his analysis (Nielsen Norman Group). The whole team watches together, which gives everyone the same evidence.

Timebox Everything

Every activity has a fixed duration, from three minutes per Lightning Demo to eight minutes for Crazy 8s, and the checklist recommends a Time Timer to keep that visible (Design Sprint guide). The tight schedule forces decisions with incomplete information, which is the condition product decisions are made in anyway. It also protects energy: the checklist asks facilitators to break every sixty to ninety minutes and to hand long debates to the Decider.

Clear the Calendar

The sprint team commits to the full five days and shuts down messaging and media while it works, per the Design Sprint guide. Google's kit also says participants should be present for the entire sprint, while knowledge experts may join only for specific exercises (Design Sprint Kit FAQ). Someone who misses Monday's map will sketch against a problem the rest of the team has already reframed.

Steps

1. Map the problem and pick a target (Monday) Start by writing a long-term goal and turning the biggest risks into sprint questions the week could answer. Draw a simple map with the customers and key players on the left, the completed goal on the right, and a flowchart of five to fifteen steps between them (Design Sprint guide). In the afternoon, interview experts from the team and outside it for fifteen to thirty minutes each, while everyone writes How Might We notes. Cluster the notes, vote with two dots each, and move the winners onto the map. The Decider then circles one target customer and one target moment, which fixes the scope for the rest of the week.

2. Sketch competing solutions (Tuesday) The morning is for Lightning Demos: each person shows an existing solution worth borrowing from, three minutes per demo, while the Facilitator captures ideas on the whiteboard. The team then decides whether to divide the target area of the map or have everyone swarm the same part. In the afternoon, each person works through the four-step sketch: notes, rough ideas, Crazy 8s and a three-panel solution sketch that is anonymous and self-explanatory (Design Sprint guide). Someone also starts recruiting Friday's customers with a screener survey, since recruiting runs alongside the whole week.

3. Decide on the strongest solutions (Wednesday) Tape the sketches in a row and run the "sticky decision": a silent heat map with small dots, a speed critique of three minutes per sketch, a nonbinding straw poll, and then the Decider's supervote with three large dots. Sort the chosen sketches from the maybe-laters and decide whether the winners fit one prototype or need competing prototypes in a "Rumble" (Design Sprint guide). In the afternoon, draw a grid of about fifteen squares, pick an opening scene, and fill in a storyboard of five to fifteen steps using existing sketches where possible. Tough calls go to the Decider, and small ones wait so the team does not run out of energy.

4. Build a realistic prototype (Thursday) Pick tools that are rough, fast and flexible rather than the team's everyday production tools. Assign the roles from the checklist: Makers, a Stitcher who checks quality and makes sure the pieces fit together, a Writer, an Asset Collector, and the Interviewer, who writes Friday's script (Design Sprint guide). Run a trial run in the afternoon with the Interviewer and the Decider watching, early enough to fix what it finds. Remind every customer about Friday's test before the day ends, by phone if possible.

5. Test with customers and decide next steps (Friday) Run five interviews in one day, with the sprint team watching a one-way video feed from a separate room. The Interviewer follows the Five-Act Interview: a friendly welcome, context questions, an introduction to the prototype with a request to think aloud, tasks with light nudges, and a debrief (Design Sprint guide). Observers take notes on a whiteboard grid with a column per customer and a row per sprint question, and after each interview they vote yes or no on each question for that customer. At the end of the day the Decider sets a single yes or no for each question, and each person writes a hot take and proposed next steps before the Decider chooses.

Design Sprint Variants Compared

The table compares the published five-day sprint with the versions teams most often meet. Each row links the source that describes it.

The differences matter for planning. AJ&Smart describes Design Sprint 2.0 as its own four-day version, created after running hundreds of sprints, and as "the only update approved by Sprint-inventor Jake Knapp" (AJ&Smart). Knapp and Zeratsky's current guide still answers "Yes" to whether teams need five days, and says teams need the full week especially the first time (Design Sprint guide). Google's kit notes that "The Google Ventures model outlines a 5 day schedule," and says a one-day version is possible but harder than allocating 3-4 days (Design Sprint Kit FAQ).

When to Use

• A team is about to commit months of engineering to a new product, market or core workflow, and the case rests on assumptions. A week of prototyping and testing is cheap next to building the wrong thing.
• A cross-functional team keeps arguing about what customers will do, and the arguments come from different mental pictures of the customer. Watching the same five interviews gives everyone one shared set of evidence.
• A startup needs to know whether its core value proposition lands with target customers before it builds a first version. A facade prototype can test the riskiest moment in the journey without writing production code.
• An established product faces a redesign or a new feature where a wrong call is expensive or hard to undo, such as a change that forces customers to relearn a workflow.
• A project is stuck in circular planning, and the team has the people and the authority to decide. The fixed schedule and the Decider force a concrete choice by Wednesday.

When Not to Use

• The direction is already clear and agreed. Google's kit says that with a clear product direction and an agreed feature set "you probably don't need a Sprint," only dedicated working time (Design Sprint Kit FAQ).
• The team knows too little about its customers to choose a target. The same FAQ recommends doing research first when there is little user research, then planning the sprint.
• The main risk is technical, such as whether a system can handle the load or a model can reach the needed accuracy. A facade prototype cannot answer that, so a technical spike fits better.
• No one with real decision rights can take part or appoint a delegate. Without a Decider the week ends with a recommendation that still has to be sold.
• The change is small, cheap and reversible. Shipping it behind a flag and measuring is faster than a five-day process.