Design sprint: the five phases, timing and who runs it

A design sprint is a five-day process for answering a big product question by building a realistic prototype and testing it with real users, instead of debating it for months. Jake Knapp created it at Google Ventures, and it compresses map, sketch, decide, prototype and test into one focused week so a team learns whether an idea works before it commits to building it.

The format comes from the 2016 book Sprint by Jake Knapp with John Zeratsky and Braden Kowitz, written from the sprints they ran with Google Ventures portfolio companies. It caught on because it replaces the usual cycle of meetings, specs and quiet doubt with a single week that ends in evidence. This article covers what a design sprint is, the five days in order, who runs it, the shorter four-day version, and where teams most often get stuck.

What is a design sprint?

A design sprint is a time-boxed, five-day workshop that takes a team from a hard product question to a tested prototype. The point is speed of learning: rather than build the real thing and wait for the market to react, you build a convincing facade in a day and put it in front of five target users the next. By Friday afternoon you know whether the idea is worth pursuing, and you have watched real people succeed or struggle with it.

It works best on high-stakes questions where the team is stuck or divided: a new product direction, a risky feature, a redesign nobody agrees on. It is not a general-purpose meeting format, and it is overkill for small decisions. The sprint earns its week when being wrong would cost months of engineering, because a week of five people is cheap next to a quarter of a build that no one wanted.

What are the five phases of a design sprint?

Five days, one goal each, run in order. Monday builds a shared map of the problem and picks a target. Tuesday generates competing solution sketches. Wednesday decides on one. Thursday builds a prototype of it. Friday tests that prototype with five real users. The sequence matters, because each day depends on a clean decision from the day before.

Monday sounds slow but it is the day that makes the rest work: the team maps how a customer moves through the problem, interviews internal experts, and the decider picks one target moment to attack. Tuesday is divergent by design, everyone sketches alone so the loudest voice does not set the agenda. Wednesday converges through silent review and voting rather than open argument. Thursday is a build day with a strict deadline, and Friday is five one-on-one interviews watched by the whole team.

Who runs a design sprint?

Two roles matter most: the facilitator and the decider. The facilitator runs the clock, the exercises and the room, and stays neutral on the content. The decider is the person with real authority over the product, often a founder or a product lead, who makes the final call on Wednesday and breaks ties. A sprint without a real decider drifts, because the whole method is built around one accountable choice.

The rest of the sprint team is small, ideally no more than seven people, and deliberately mixed: someone from design, engineering, product, and anyone who talks to customers or controls the money. You also want at least one troublemaker, the person who sees the problem differently. The tester who runs Friday's interviews can be the facilitator or an outside researcher, and the five users should match your real target, not colleagues.

How long is a design sprint?

The original is five consecutive days, Monday to Friday, with the team clearing their calendars for the week. That full length is part of the design: momentum dies if you spread it across weeks, and the whole point is to learn in days instead of quarters. Most teams that struggle to protect five straight days are really struggling to give the question the priority it needs.

That said, a four-day version is now common, popularized by the agency AJ&Smart, which merges the map and sketch work and trims the schedule. It trades some depth on the mapping day for a calendar that busy teams will actually agree to. Either length works; what does not work is a two-hour version, because you cannot prototype and test real users in an afternoon, and skipping the test is skipping the only day that produces evidence.

Design sprint versus brainstorming

A design sprint is not a brainstorm, though it contains one. Classic group brainstorming produces a pile of verbal ideas and stops. A sprint uses structured, mostly silent divergence on Tuesday, forces a single decision on Wednesday, and then does the two things a brainstorm never does: it builds the chosen idea and tests it with users. The sketch and decide days are where sprints most resemble a good brainstorming session, and also where they most often stall.

They stall for the same reasons any ideation stalls. Tuesday produces four versions of the obvious idea because the first sketch anchored everyone, and Wednesday turns into a debate the loudest person wins. Forced-angle generation fixes the first problem and silent voting fixes the second, which is the job a dedicated design sprint tool does for those two days. The wider theory of splitting a session into a diverge phase and a converge phase is covered in our guide to divergent and convergent thinking.

How do you prepare for a design sprint?

Preparation is mostly logistics and people. Book the whole team for the whole week, get the decider to actually attend rather than drop in, and recruit five target users for Friday before the sprint starts, because five-day-late recruiting is the classic reason a sprint ends without a test. Line up the interview questions and the map inputs, and clear the room of laptops and phones except when a tool is in use.

The other half is the question. Write down the single big question the sprint will answer and the long-term goal behind it, so Monday's mapping has a target. If the team cannot even agree on the question, that disagreement is worth surfacing before you spend a week. Once the prototype is tested on Friday, the honest final step is watching real people use it, which is why teams pair the sprint with a way to watch how users actually behave in the sessions rather than trusting a show of hands in the room. Feed what you learn back in, and if the answer was no, you spent a week instead of a quarter finding out.

The recurring users of this format are product teams and the agencies who run sprints for clients. Both benefit from tooling the two idea-heavy days so the week does not stall in the middle, which is exactly what the product team workflow is built around, and the studio at the top of this page runs the sketch-and-decide core on your own sprint question in a couple of minutes.