Run Design Sprint

Compress months of design-build-test cycles into five focused days to answer a high-stakes product question.

Why This Is Best Practice

Adopted by: Google Ventures (ran 150+ sprints with portfolio companies), Slack, Airbnb, LEGO, and adopted by NHS and UN for service design Impact: GV data shows design sprints reduce average time to validated prototype from 6–12 weeks to 5 days; Knapp reports 85% of sprint teams make a major strategic decision based on Day 5 test results

Why best: A sprint forces the team to make decisions with incomplete information by creating real user data on Friday. It replaces weeks of debate and assumption with a concrete test result.

Steps

1. Monday — Map and target — Draw the problem as a journey map from user to goal. Interview experts (engineering, sales, support, data). At the end of the day, vote on the long-term goal and the most critical point to focus the sprint on.
2. Monday — How Might We notes — Throughout interviews, each participant writes "How Might We…" prompts on sticky notes. Cluster and vote to surface the team's shared priorities.
3. Tuesday — Sketch solutions — Each person independently sketches 3–8 solution ideas using the "Crazy 8s" exercise (8 frames, 8 minutes). No group ideation — individual sketching produces more diverse ideas.
4. Wednesday — Decide — Use the "sticky vote" method to evaluate sketches without discussion first. The Decider makes the final call on which solution to prototype. Storyboard the prototype in 8–12 frames.
5. Thursday — Prototype — Build a facade (not functional code) using Keynote, Figma, or paper. Divide roles: maker, writer, asset collector, interviewer preparer. The prototype only needs to test the critical question — it does not need to be complete.
6. Friday — Test — Run 5 back-to-back user interviews against the prototype using the think-aloud protocol. Observers watch in a separate room, noting patterns on sticky notes in real time.
7. Friday — Synthesize — After interviews, identify patterns across 5 users. Decide: proceed as prototyped, iterate, or pivot. Document the decision and evidence in a one-page sprint report.

Rules

• Maximum 7 people in the sprint room. More than 7 slows every decision.
• No laptops during activities — phones and email are out during sprint hours (9 AM–5 PM).
• The Decider (usually a product leader) has final say on all votes; sprints are not democracies.
• The prototype is not code — never write production code during a sprint.
• Friday's test result is a signal, not a verdict; 5 users reveal patterns, not statistical significance.

Examples

Slack used a sprint to test whether users would understand a "Shared Channels" concept before building it. Day 5 tests with 5 users showed 3 of 5 were confused by the metaphor but loved the core idea. The team rebuilt the mental model (renamed, reframed) before writing a line of code.

Common Mistakes

• No clear Decider — Without a designated decision-maker, "sticky vote" results get relitigated; the sprint stalls.
• Building real code Thursday — Engineering sprints that build working software miss the point; a Keynote prototype tests the idea 10× faster.
• Recruiting wrong participants — Testing with colleagues or non-representative users produces invalid signal; recruit screened participants matching the target persona.

When NOT to Use

• Do not run a design sprint when the critical question has already been answered by existing user research or live product data — a sprint adds cost without new signal.
• Do not use a design sprint for execution work where the solution is already decided and the team needs to build, not explore — a sprint is a decision tool, not a delivery tool.
• Do not run a sprint when the Decider (a senior product or business leader with authority to commit) cannot be present all five days — without decision authority in the room, the sprint's outputs become recommendations that get relitigated after Friday.