Design
Sprint
Five focused days from problem to tested prototype. Answer a critical business question through design, prototyping, and real user testing — before writing a line of production code.
The five days
Each day has one job
Most teams spend months building something before a user ever sees it.
The Design Sprint was developed at Google Ventures by Jake Knapp, John Zeratsky, and Braden Kowitz between 2010 and 2016, tested across more than 150 startups and enterprises. Its core premise is radical: you do not need months to answer a critical question. You need five focused days, the right people in the room, a realistic prototype, and five real users.
The Design Sprint does not replace longer innovation processes. It accelerates the most expensive part of them — the moment between “we have a promising idea” and “we know if it works.”
Three uncomfortable truths
- 1Discussion without prototyping is largely wasted time. Teams can debate the merits of an idea for weeks without learning anything that a five-hour prototype and five user interviews would not reveal in a day.
- 2The people closest to a problem are often the worst judges of its solution. Subject-matter expertise creates blind spots. The Design Sprint deliberately brings in outsiders through user testing on Friday.
- 3The pressure of a deadline produces better creative work than unlimited time. The five-day structure is not arbitrary — it is tight enough to prevent overthinking and long enough to produce something testable.
Real-world grounding
When Slack was refining its onboarding experience, the team ran a Design Sprint focused on the moment new users first encountered the product. In five days they prototyped and tested three different onboarding flows, identified the specific points of confusion causing early churn, and had a clear direction for a redesign — before writing a single line of production code.
When to use it
Use it when
- →You have a defined challenge but are uncertain which solution direction to pursue
- →The stakes of getting the direction wrong are high
- →You have been discussing a problem for weeks without reaching clarity
- →You want to test a risky assumption before committing to development
Do not use it when
- ×The problem itself is not yet defined — run the Double Diamond's Discover and Define first
- ×The solution is already decided and the work is execution
- ×You cannot get the right decision-makers in the room for five consecutive days
Click any day to see how it works
Select a day to explore its activities and a real-world company example. Use the sprint readiness check first — or toggle to Design Sprint 2.0 to see how Monday and Tuesday merge into a single four-day format.
Five versions, one engine
The Design Sprint has evolved through close collaboration between its original authors and the practitioner community, producing named versions with documented changes. Select a version to see what changed and what stayed the same.
Where this connects
The Design Sprint answers “which direction should we build, and does it work for real users?” These are the frameworks and methods that answer the adjacent questions.
Sources & Further Reading
Sprint
Jake Knapp, John Zeratsky, and Braden Kowitz, 2016
Make Time
Jake Knapp and John Zeratsky, 2018
Design Sprint 2.0
AJ&Smart / Jonathan Courtney, 2018
The Sprint Book — sprintbook.com
Official companion resources