The Design Sprint is a five-day process, developed at Google Ventures, for going from a business problem to a tested prototype without building the real product first.
The idea
Rather than debating a product decision in meetings for weeks, a Design Sprint compresses design, prototyping, and validation into a single week with a small, focused team. Each day has a fixed goal, moving from problem to a validated (or invalidated) solution:
- Monday — Understand: map the problem and pick a target.
- Tuesday — Sketch: individually sketch possible solutions.
- Wednesday — Decide: critique the sketches and commit to one direction.
- Thursday — Prototype: build a realistic-looking, but fake, prototype.
- Friday — Test: put the prototype in front of real users and observe.
When to use it
- A high-stakes product or feature decision where building the real thing first would be expensive
- A team stuck debating a direction without real user data to settle it
- Kicking off a new product, feature, or major redesign with alignment across stakeholders
How to apply it
- Assemble a small cross-functional team and a facilitator for the week.
- Block five consecutive days with no other commitments.
- Follow the Monday–Friday structure: understand, sketch, decide, prototype, test.
- End Friday with real user feedback on a realistic prototype, not just opinions.
Watch out for
- It requires a full week of dedicated time from the whole team, which is a real cost to clear
- A sprint is only as good as the problem framing on day one — sprinting on the wrong question wastes the week
- Prototype feedback from a handful of users is directional, not statistically conclusive
Related models
- Lean Startup — a related philosophy of validating ideas quickly before fully building them.
- ICE Framework — useful for choosing which problem is worth a sprint in the first place.
Sources
Jake Knapp, John Zeratsky, and Braden Kowitz, Sprint: How to Solve Big Problems and Test New Ideas in Just Five Days (2016).