Glossary

Design Sprint

Glossary

Design Sprint

Design Sprint

Introduction

A design sprint is a structured, time-boxed process, classically five days, in which a small cross-functional team defines a problem, sketches solutions, decides on one, builds a realistic prototype, and tests it with real users, all before writing production code. Developed at Google Ventures and codified in Jake Knapp's book, it compresses months of debate into a week that ends with evidence. This article covers how a sprint runs day by day, what makes the final test day work or fail, and where sprints fit alongside continuous research rather than replacing it.

What is a Design Sprint?

A design sprint is a fixed-length, facilitated process for answering a critical product question through design, prototyping, and testing with customers, in a compressed timeframe. The canonical version comes from Google Ventures, where Jake Knapp and colleagues ran it with portfolio startups and then published it in Sprint (2016): five consecutive days, a team of about seven with a decider, a facilitator, and the expertise the problem needs, one big challenge, and a schedule that ends on Friday with five real users trying a prototype. The sprint borrows from design thinking (empathize, ideate, prototype, test) and from agile's time-boxing, and its distinctive contribution is the discipline of the calendar: decisions that would take weeks of meetings are forced by the clock, and the question is answered by Friday's users rather than by whoever argued longest.

The Five Days

Monday: map and target. Agree the long-term goal and the sprint questions, map the customer's journey through the problem, interview the experts in the room, and choose the specific target (which moment for which customer) the sprint will attack. Existing research (interviews, analytics, journey maps) feeds this day; a sprint without prior evidence maps assumptions.

Tuesday: sketch. Review existing solutions and analogous ideas, then sketch individually, in detail, in silence: the four-step sketch that ends with a solution each person can defend on paper. Individual sketching before group discussion is the sprint's defense against the loudest voice.

Wednesday: decide. Critique the sketches with a structured process (silent review, heat-map dot voting, brief critiques, a decider's vote), choose the direction, and storyboard the prototype step by step.

Thursday: prototype. Build a realistic facade of the solution, enough to test on Friday and no more: a clickable prototype, a landing page, a brochure, a mock storefront. The fidelity is "good enough to elicit honest reactions", not shippable.

Friday: test. Five one-on-one moderated sessions with target customers, the team watching from another room, noting reactions on a shared grid and looking for patterns. The sprint's answer is what those five people did and said.

What Makes Friday Work

1. Recruit the right five, and recruit early.
Participants from the target audience, screened on Monday or before; the most common sprint failure is testing with whoever was available. Screened panel recruitment that fills five slots within a day (a Ballpark study can recruit and, if the team prefers, run the sessions unmoderated in parallel with Friday's moderated ones for a larger read) removes the excuse.

2. Write real tasks.
Goal-based scenarios, not a tour of the prototype; the prototype is judged by whether people can use it for their goal.

3. Moderate neutrally.
The interviewer doesn't pitch, doesn't rescue, and asks what the participant expected; the team in the other room watches for the nudge as much as for the finding.

4. Look for patterns, not votes.
Five sessions find the big problems and the big reactions; they do not produce percentages, and a sprint that reports "80% liked it" has confused a pattern with a poll.

5. Decide what happens next before you leave.
Ship a next iteration, run a second sprint, or drop the idea: the sprint's value is a decision on Friday, not a slide deck on Monday.

Where Sprints Fit

A sprint is an event, and its strengths are an event's: focus, alignment, speed, and a decision under a deadline. It is the right tool for a big, contested question at the start of something (a new product, a major redesign, a strategic bet) and for teams that need to learn what evidence-based decision-making feels like. It is not a substitute for the ongoing work: a sprint's Monday is only as good as the research that preceded it, and its Friday is only the beginning of the iteration that follows. Teams that run continuous discovery use sprints as the occasional intensive inside the weekly rhythm; teams that only sprint learn once a quarter.

In Short

A design sprint answers a big question in five days: map the problem, sketch alone, decide with structure, prototype a facade, and test with five real customers. The clock replaces the meeting, and Friday's users replace the argument. Recruit the right participants early, write real tasks, moderate neutrally, read patterns rather than votes, and decide before the room empties. Use it for the big contested bets, feed it with the research that came before, and follow it with the iteration that comes after.

Further reading

For the method from its originators:

Articles:

1. The Design Sprint - Google Ventures
The GV team's guide to the five-day process, with materials and checklists for each day.

Books:

1. Sprint: How to Solve Big Problems and Test New Ideas in Just Five Days - Jake Knapp, John Zeratsky & Braden Kowitz
The full method, day by day, with the reasoning behind each step.