Five-Day Design Sprint

What It Is

The Five-Day Design Sprint is a structured process created by Jake Knapp at Google Ventures for answering high-stakes product questions in one week. A small team maps a problem, sketches solutions, picks a winner, builds a realistic prototype, and tests it with real users — all in five days. It replaces months of debate and speculative building with direct evidence from customers.

When to Use It

• When the team faces a big decision with high stakes and genuine uncertainty.
• Before committing significant engineering resources to a new feature or product direction.
• When internal debate has stalled and the team needs external data to break a tie.
• At the start of a new initiative, when you need to rapidly explore and validate a direction.
• Not appropriate for small tweaks, routine bug fixes, or problems that just need more execution.

How It Works

Monday — Map

• Define the long-term goal and the sprint questions (what are we trying to learn?).
• Create a simple map of the user journey or system.
• Interview internal experts (stakeholders, support, sales).
• Pick a specific target: one customer, one moment in the journey.

Tuesday — Sketch

• Review existing ideas and inspiration (Lightning Demos).
• Each person sketches solutions individually and in detail (four-step sketch: Notes, Ideas, Crazy 8s, Solution Sketch).
• No group brainstorming. Individual work produces better, more diverse ideas.

Wednesday — Decide

• Present all solution sketches silently (art museum style).
• Vote using dot stickers, then discuss only the contentious points.
• The Decider (one person with authority) makes the final call.
• Create a storyboard — a step-by-step plan for the prototype.

Thursday — Build

• Build a realistic-looking prototype. It does not need to work — it needs to look real enough to get honest reactions.
• Divide roles: Makers, Stitcher (ensures consistency), Writer (real copy, not lorem ipsum), Asset Collector, Interviewer (prepares Friday script).
• Use slides, Figma, video editing, or whatever tool lets you move fastest.

Friday — Test

• Run five one-on-one interviews with target users.
• Show them the prototype and observe their reactions. Use a structured interview script.
• The rest of the team watches via live stream and takes notes.
• After all five sessions, look for patterns: strong positives, strong negatives, and surprises.

Key Principles

• Five users is enough. Research shows five interviews reveal ~85% of usability patterns. More users yield diminishing returns for this kind of test.
• A Decider must be in the room. Without someone empowered to make calls, Wednesday stalls. This person is typically a founder, PM lead, or exec sponsor.
• No devices, no distractions. The sprint demands full-time attention from the team for the entire week.
• Prototype, don't build. Thursday's output is a facade. If it takes more than one day, you are overbuilding.
• Learn, don't launch. Friday's purpose is learning. A "failed" sprint that saves months of wasted engineering is a massive success.

Common Mistakes

• Inviting too many people. The ideal team is seven or fewer. Larger groups slow decisions and dilute individual contribution.
• Skipping Friday. Building a prototype without testing it turns the sprint into an expensive design exercise. The user test is the entire point.
• Running a sprint for the wrong problem. Sprints are for big, uncertain questions. Using one to decide button color is a waste of a week.

Source

Jake Knapp, Sprint: How to Solve Big Problems and Test New Ideas in Just Five Days (2016). The entire book walks through the process day by day with detailed facilitation instructions.