What Happens in a Five-Day Design Sprint
By CodexierPublished 6 min read
A design sprint compresses months of debate about a product idea into one week that ends with real users reacting to a realistic prototype. It is not a workshop and not a design project; it is a decision process with a deadline. This guide walks through the five days as we run them, and is honest about the one condition that makes or breaks the result: who is in the room.
Monday: map the problem
Monday starts with the end: what should be true in two years if this works? Then the pessimism exercise, listing the questions that could sink it, so they become testable statements instead of background worry. The afternoon maps the user journey in a handful of steps and interviews the people who know most, from support to sales. By the end of the day the team chooses one target on the map, the moment where the sprint will focus, and that choice belongs to the decision-maker, not the room.
Tuesday: sketch solutions
Tuesday is the least like a normal meeting. Nobody brainstorms aloud. Everyone, including the non-designers, works alone through a structured sequence that ends in a detailed sketch of one solution to the target moment. The morning is spent collecting existing ideas and examples from other industries; the afternoon is the solo sketching.
- Notes: each person reviews Monday's map and goals and writes down what matters.
- Rough ideas: quick doodles of possible approaches, private and messy.
- Crazy eights: eight variations of the most promising idea in eight minutes, to push past the first obvious answer.
- Solution sketch: a three-panel storyboard, self-explanatory, anonymous, with a title. This is what gets judged on Wednesday.
The reason for silence and anonymity is mechanical: group discussion rewards the loudest voice and the most senior title, and sketches done alone produce more distinct options for the decision on Wednesday.
Wednesday: decide
The sketches go on the wall and the room reviews them in silence, marking the parts that stand out. Each sketch gets a short critique, the creator responds last, and then the vote. Everyone votes, but the decision-maker's vote settles it. The afternoon turns the winning sketch, or a combination, into a storyboard of ten to fifteen frames that specifies exactly what the prototype must show.
| Role | Needed on | Why |
|---|---|---|
| Decision-maker, founder or product owner | Monday, Wednesday, Friday | Chooses the target and the solution, hears users first-hand |
| Facilitator | All five days | Runs the clock and the exercises, keeps the room out of debate |
| Designer or prototyper | All five days | Turns the storyboard into something users believe on Thursday |
| Someone from sales or support | Monday and Wednesday | Knows what customers actually say and object to |
| Engineer | Monday and Wednesday | Flags what cannot be built and shapes a realistic solution |
Five to seven people is the working range. Beyond that the decisions slow down and the decision-maker's voice gets diluted.
Thursday: prototype
Thursday builds a facade. The prototype must look and feel real enough that Friday's users react to the idea rather than to the roughness, and it must be built in one day, which rules out real code. In practice that means a clickable prototype in Figma or a similar tool, with realistic copy, real-looking data and only the path the storyboard describes. Nothing off that path works, and that is fine.
- Split the work: one person owns screens, one owns copy and data, one stitches the flow together and tests it end to end.
- Write the Friday interview script in parallel, so the questions match what the prototype can show.
- Do a full run-through by mid-afternoon with someone who has not seen it, and fix what breaks.
- Confirm the five Friday users and send them the logistics.
This is the day where a studio with practised prototypers changes the outcome. A prototype that looks like a wireframe gets feedback about wireframes; one that looks like a product gets feedback about the product. That craft is a large part of what a product design sprint buys, and the wider practice of testing before code is covered in a separate guide.
Friday: test with real users
Five one-on-one interviews, about an hour each, with people who match the target customer and were recruited earlier in the week. One person interviews; the rest of the team watches on a video link in another room and takes notes on a shared grid. Patterns that appear in three or more interviews are treated as findings; single reactions are noted and not acted on.
The sprint ends with a short session where the team reads the grid, writes down what they learned against Monday's questions, and decides the next step: build it, refine and test again, or drop it. That last option is a success, not a failure; a week that kills a bad idea has saved months. When a sprint is the wrong tool: when the decision-maker cannot give the days, when the problem is a known bug rather than an open question, when the product already exists and needs incremental fixes, or when there is no way to recruit real users by Friday. In those cases a UX audit or a few customer interviews is the cheaper, better buy, and we will say so on a short call. The full price and what is included is on the pricing page.
Frequently asked questions
Does a design sprint have to be five full days?
The classic format is five, and it works because the deadline forces decisions. Four-day variants exist that merge sketching and deciding. What cannot be compressed is the sequence: map, sketch, decide, prototype, test. Removing the test with real users turns it into a workshop with a nicer name.
What do we get at the end of the sprint?
A clickable prototype of one solution, recordings and notes from five user tests, a summary of what was learned against the questions set on Monday, and a recommended next step. You do not get production-ready design or code; you get evidence about whether to build.
Who needs to attend from our side?
The person who can make product decisions, present on Monday, Wednesday and Friday at least, plus someone who talks to customers daily and someone who knows what can be built. Delegating the decision-maker role is the most common reason a sprint produces a result nobody acts on.
Wondering whether your question fits a sprint?
Describe the decision you are stuck on in a fifteen-minute call. We will tell you whether a five-day sprint, a UX audit or a handful of customer interviews is the right way to answer it.
Book a free 15-minute call