A design sprint is a time-boxed, structured process, typically four or five consecutive days, in which a small cross-functional team defines a critical problem, sketches competing solutions, decides on one, builds a realistic prototype and tests it with real users. In a design workflow it compresses months of debate and building into a single week of evidence.
The method was formalized in product teams in the early 2010s and popularized as a five-day format with one activity per day. Its purpose is not to ship a product but to answer high-risk questions quickly and cheaply, before a team commits budget, engineering time or brand reputation to a direction.
The five phases of a design sprint
The classic sprint follows five phases, one per day, each producing a concrete artifact that feeds the next. The sequence moves from understanding to divergence, then convergence, then making and finally learning.
| Day | Phase | Key activities | Output |
|---|---|---|---|
| Monday | Map | Long-term goal, sprint questions, expert interviews | Problem map and chosen target |
| Tuesday | Sketch | Lightning demos, Crazy 8s, solution sketches | Individual solution concepts |
| Wednesday | Decide | Heat map voting, straw poll, storyboard | Selected concept and storyboard |
| Thursday | Prototype | Building a realistic facade | Testable prototype |
| Friday | Test | Five one-on-one user interviews | Patterns, answers, next steps |
Two ideas hold the structure together. The long-term goal states the optimistic outcome the team wants in one or two years, and the sprint questions reframe the biggest risks as questions the Friday test can answer. Every later decision is judged against them, which keeps the week focused.
The sprint also replaces open discussion with structured individual work. Ideas are captured as How might we notes, solutions are sketched alone and presented anonymously, and preferences are expressed through silent dot voting before anyone argues. This reduces the influence of the loudest or most senior voice and gives quieter specialists equal weight. The Thursday prototype is deliberately a facade: only the screens, pages or materials that the test needs are built, often in a single day, because realism matters for the reaction of users, while completeness does not.
Roles and preparation
A sprint team is deliberately small, usually up to seven people, so that discussion stays efficient. It combines the people who own the decision with those who understand the customer, the technology and the business. Preparation before the sprint matters as much as the week itself: recruiting test participants, booking a room or digital board and clearing calendars.
| Role | Responsibility | Typical person |
|---|---|---|
| Decider | Makes final calls on target and concept | Product lead, founder, executive sponsor |
| Facilitator | Runs the agenda, timeboxes and exercises | Designer, researcher or external coach |
| Experts | Share knowledge on Monday interviews | Engineering, support, sales, legal |
| Makers | Build the prototype on Thursday | Designers, writers, developers |
| Interviewer | Leads the Friday user sessions | UX researcher or trained designer |
The Decider role is what distinguishes a sprint from a workshop. Without someone authorized to choose, the team falls back into consensus by committee, and the storyboard becomes a compromise that tests nothing clearly.
Design sprint compared with related practices
The term sprint also appears in agile development, which causes frequent confusion. An agile sprint delivers working increments of software over one to four weeks, while a design sprint delivers learning about whether an idea deserves to be built. They can follow one another, but they answer different questions.
| Practice | Duration | Main output | Best for |
|---|---|---|---|
| Design sprint | 4-5 days | Tested prototype and validated answers | High-risk, well-scoped questions |
| Agile sprint | 1-4 weeks | Working software increment | Delivering an agreed backlog |
| Design thinking program | Weeks to months | Research insights and concepts | Broad, poorly understood problems |
| Hackathon | 1-3 days | Rough technical demos | Exploring feasibility and energy |
| Design critique | 1-2 hours | Feedback on existing work | Improving a design in progress |
Variants and remote sprints
Many teams now run a four-day variant, which merges mapping and sketching into one day and lets experts attend only part of the week. Others run condensed two- or three-day sprints for smaller questions, accepting less depth in exchange for speed.
Remote sprints use digital whiteboards such as FigJam for mapping, sketching and voting, and design tools such as Figma for prototyping. They work well with shorter daily sessions, about four to five hours, stricter timeboxes and more explicit facilitation, because fatigue and distraction rise quickly on video calls.
When a design sprint fits and when it fails
A sprint is most valuable when the stakes are high, the question is specific enough to prototype, and the team is stuck between competing opinions. It is a poor fit for small changes that can simply be shipped and measured, or for vast problems that first require open-ended user research.
| Failure mode | Symptom | Remedy |
|---|---|---|
| Scope too broad | Map covers the whole product | Pick one target moment on Monday |
| No real Decider | Endless debate, compromise concept | Secure an authorized decision maker |
| Wrong test users | Feedback from colleagues or friends | Recruit five matching customers early |
| Prototype too rough | Users react to gaps, not the idea | Build a realistic facade |
| No follow-up | Insights fade after Friday | Plan next steps and owners before the sprint |
The Friday test with five users is designed to reveal strong patterns, not statistically significant results. Teams should report findings as directional evidence and validate important conclusions with further research or live experiments.
Put simply
A design sprint is a one-week shortcut for testing a big idea. A small team spends one focused week on a single question. They understand the problem, sketch ideas, pick the best one, build a convincing mock version and show it to real customers.
It is like building a full-size cardboard model of a kitchen before ordering expensive cabinets. By Friday, the team knows what works and what does not. Nobody has written months of code or spent a large budget yet.
In practice
A regional insurance company wants customers to file small claims through its mobile app, but internal teams disagree about whether photo-based claims would be trusted. The product director acts as Decider, and six colleagues from claims, engineering, design and customer service join a four-day sprint.
On day one they focus on the moment a customer reports a damaged windshield. After sketching and voting, they storyboard a flow with guided photos and an instant estimate, and designers build a clickable prototype in a single day. In five interviews with recent claimants, four complete the flow without help, but most hesitate at the estimate screen because the wording sounds final. The team rewrites the estimate as provisional and approves the feature for development with a clear list of open questions.