process & strategy
Design sprint
What is a design sprint?
A design sprint is a time-boxed process - classically five days - for answering a big product question by going from idea to a tested prototype in a week, without building the real thing first. Devised at Google Ventures, it compresses months of debate into a structured week: map the problem, sketch solutions, decide, build a realistic prototype, and test it with real users.
Also known as: design sprint, google design sprint, sprint
Prefer to watch?
Watch the recap 1:09
The demo
A big, risky product question - normally months of building and debate. A design sprint answers it in five days. Step through the week and watch idea become tested prototype, no real build required.
What this demo shows (text version)
A five-phase stepper walks through a classic Google Ventures design sprint, one phase per day: Monday maps and frames the problem; Tuesday is individual sketching of solution ideas; Wednesday the team critiques and decides on the strongest concept; Thursday they build a realistic but fake prototype; Friday they test it with five real users. Each phase is explained, and the demo contrasts the five-day route with the alternative of spending weeks or months building the real thing before learning anything.
That's a design sprint: a time-boxed, structured week that takes a high-stakes question from idea to tested prototype without building the real product. Its value is speed and de-risking - real user evidence in days, on a convincing fake rather than a costly build. Use sprints for big, ambiguous questions; they complement, rather than replace, ongoing iterative design.
A design sprint trades months of "let's build it and see" for a week of structured learning. Its power is speed and de-risking: instead of arguing in meetings or committing to a full build on a hunch, a small cross-functional team works through a fixed five-phase structure - understand/map the problem, sketch ideas individually, decide on the strongest, prototype a realistic façade, and test with five real users - to get evidence in days. Crucially, the prototype is a convincing fake, not a real product, so you learn whether the idea works before investing in building it. Use sprints to tackle high-stakes, ambiguous questions quickly; they're a focused burst, not a substitute for ongoing iterative design.
Step through the week and watch a vague, high-stakes question become a tested answer in five days - map, sketch, decide, prototype, test - without building anything real. That's the design sprint: compress the months of "build it and find out" into a week of structured learning, so you de-risk the big bet before committing to it.
The classic Google Ventures sprint runs five phases (originally one per day). Monday - understand: map the problem and pick a target. Tuesday - sketch: each person generates detailed solution ideas individually (divergent). Wednesday - decide: critique and choose the strongest concept to prototype (convergent). Thursday - prototype: build a realistic but fake façade, just enough to test. Friday - test: put it in front of five real users and learn. Modern versions compress or adapt this.
Its value is rapid, low-cost de-risking of important decisions. Rather than months of building and discussion, a focused, cross-functional team gets real user evidence on a high-stakes question in a week, surfacing whether an idea is worth pursuing before significant investment. The structure forces decisions, breaks deadlock, and aligns the team around shared understanding and a concrete test.
Sprints suit big, ambiguous, high-stakes questions - a new product direction, a risky feature, a major redesign - where the cost of building the wrong thing is high. They're not a replacement for ongoing iterative, human-centred design or continuous discovery: they're an intense, bounded burst that produces a learning, which then feeds back into normal iterative work. The prototype is deliberately disposable - built to answer a question, not to ship.