How to Run a Design Sprint in 5 Days

The design sprint was invented at Google Ventures by Jake Knapp and refined across hundreds of startup engagements. The core idea is almost offensively simple: instead of talking about a problem for months, you spend one week solving it, prototyping it, and testing it with real users. By Friday afternoon you have data. Real data, from real people, about whether your idea holds up.

What makes it work is time compression. Most product decisions suffer from too much time, not too little. When you have three months to figure out a feature, you fill those months with opinions, politics, and second-guessing. When you have five days, you have no choice but to make fast decisions based on the best available thinking in the room.

The sprint also forces a bias for action that most teams struggle to maintain. You are not building a perfect solution. You are building the smallest possible prototype that can answer a specific question. That constraint is liberating. It kills perfectionism before it starts.

Sprints are particularly powerful when your team is stuck: stuck on a hard design problem, stuck debating which direction to take a product, or stuck because nobody wants to commit to a path without more information. The sprint gives you a structured process for making a bet, testing it fast, and learning regardless of the outcome.

One thing worth saying plainly: a design sprint is not a shortcut to a finished product. It is a shortcut to a validated direction. You will still need to build the real thing afterward. But you will build it knowing that the core concept actually resonates with users. That is worth five days of focused work from almost any team.

The sprint team is one of the most important decisions you will make before Monday morning. Get it wrong and you will spend the week relitigating decisions instead of making them.

The ideal sprint team is five to seven people. Fewer than five and you lack the diversity of perspective that makes the exercises productive. More than seven and the group dynamic becomes unwieldy. Every voice needs airtime. Every vote needs weight. Past seven, both of those things break down.

You need specific roles represented, not just warm bodies:

• The Decider: This is the most important role in the sprint. It is the person with the authority to make the final call on direction. Usually a founder, a product lead, or a VP. If your Decider cannot commit to being in the room for all five days, reschedule the sprint. A sprint without a real Decider turns into a committee, and committees do not make fast decisions.
• A designer: Someone who can sketch solutions quickly and turn a rough storyboard into a prototype on Thursday. Figma fluency is essential.
• An engineer or two: They bring technical feasibility into the room early, before the team falls in love with something impossible to build. Engineers also have strong pattern recognition for what causes problems at scale.
• A customer-facing person: Sales, customer success, or support. Someone who talks to users every day and can speak to what people actually complain about versus what they say they want.
• A wildcard: Someone from outside the immediate product team. A marketer, a domain expert, or even someone from a completely different function. Outsiders ask the questions insiders stopped asking years ago.

You also need a Facilitator, who may or may not be on the core team. The Facilitator keeps the schedule, runs the exercises, and protects the process when energy flags or debates run long. If you are a small team running your first sprint, consider bringing in an outside facilitator. It is hard to participate fully and manage the room at the same time.

Monday is about alignment. You start the week with a room full of people who each carry a different mental model of the problem. By end of day you need one shared map and one specific target to focus the rest of the sprint.

Start with the long-term goal. Ask the team: where do we want to be in two years if this product succeeds? Write a clear, ambitious statement. Something like: "Every small restaurant owner in the country can manage their entire front-of-house operation from their phone." That goal becomes your north star for every decision the rest of the week.

Then generate sprint questions. These are the assumptions baked into your long-term goal that could cause everything to fall apart. Frame them as "How might we fail?" questions: "What if restaurant owners do not want to manage operations from their phone?" "What if the setup process is too complicated for non-technical owners?" Write every scary assumption on the board. The best sprint question to target is usually the one that makes the most people in the room uncomfortable.

Next, map the problem. Draw a simple diagram showing who the key actors are, the steps they take to accomplish the goal, and where the critical moments of interaction happen. Keep it to one page. You are not building a process document. You are creating a shared visual language for the week.

In the afternoon, bring in experts. These are three to four people who know something specific and relevant: a loyal customer, a domain expert, a technical lead. Give each person 20 to 30 minutes. Ask them to share what they know and poke holes in your assumptions. Take notes using the "How Might We" format: every problem or insight gets reframed as an opportunity and written on a sticky note.

At the end of Monday, the Decider picks the sprint target: one specific moment on the map where your prototype will focus. This decision is non-negotiable. You are not solving the whole problem this week. You are solving one critical piece of it as well as you can in four days.

Tuesday morning opens with Lightning Demos. Each team member spends 20 minutes finding three to five examples of products or experiences that solve a similar problem, even if from completely different industries. You take three minutes each to show the group and highlight the one thing worth stealing. This is not about copying. It is about loading up your brain with raw material before the sketching starts.

Then comes the sketching. The process runs in four steps:

• Notes: Each person walks the map and their notes silently for 20 minutes. No talking.
• Ideas: Rough doodles. Fill a page with quick concepts, fragments, and possibilities. No one will see these. Just get the ideas out.
• Crazy 8s: Fold a piece of paper into eight panels. Sketch eight different ideas in eight minutes, one per panel. The time pressure forces quantity over quality, which is exactly what you want at this stage.
• Solution sketch: Each person creates one detailed, three-panel storyboard of their best solution. Anonymous. Words where needed. No names on the page.

Wednesday is about deciding without arguing. All solution sketches go on the wall. The team does a silent gallery walk, placing dot stickers on the parts they find most interesting. After the gallery walk, a structured critique session gives each sketch five minutes of discussion, focused on what works rather than who drew it.

Then the Decider votes with a supervote: three large stickers to place wherever they choose. The supervotes win. This is not a democracy. It is a structured process for capturing collective intelligence and then making a clear call. Whoever has the authority makes the call. That is how you end Wednesday with a decision and a storyboard ready for prototyping.

One common mistake: teams skip the anonymous sketching and go straight to discussion. Do not do this. Individual sketching before group discussion prevents anchoring and groupthink. The quality of ideas in a sprint correlates directly with how seriously you protect the sketching process.

Thursday is the most intense day in the sprint. You have roughly seven hours to build a prototype realistic enough that a user will engage with it as if it were a real product. That is a tight window. The way you spend the morning determines whether you make it.

The tool you want for this is Figma. It is fast, collaborative, and produces interactive prototypes that feel like real software. If your sprint involves a physical product or a service experience, use printed materials, role-play scripts, or a combination of both. The medium matters less than the fidelity. Your prototype needs to be "Goldilocks quality": realistic enough to provoke genuine reactions, but not so polished that you wasted time on aesthetics instead of content.

Start with a storyboard review. Take the storyboard you finished Wednesday and walk through every screen or step. Identify every piece of content, every button, every decision point. Assign each panel to a team member. Divide and conquer.

• The Maker: One or two designers building screens in Figma, turning storyboard panels into interactive frames.
• The Stitcher: One person connecting the frames into a working prototype flow, adding transitions and hotspots.
• The Writer: One person responsible for all copy: button labels, headlines, error states, empty states. Bad copy breaks prototypes faster than bad design.
• The Asset Collector: One person gathering images, icons, and any real data needed to make the prototype feel authentic.

By 3 PM you should have a working click-through prototype. Spend the last hour doing a dry run. One team member plays the user while the Facilitator reads from the interview script prepared for Friday. Fix any broken flows or confusing screens before you call it done. You want Friday to be about learning from users, not debugging your prototype in front of them.

Five users. That is all you need. Jakob Nielsen's research established decades ago that five usability test participants reveal roughly 85% of the usability problems in a product. More than five adds time and cost without proportionally adding insight. Fewer than five and you risk missing patterns that only emerge across multiple sessions.

Recruit your five participants before the sprint starts. Do not leave this to Thursday evening. Ideal participants match your target user profile closely: same job, same company size, same pain point you are trying to solve. If your product serves restaurant owners, your Friday participants should be restaurant owners, not restaurant managers or food service distributors.

The interview structure that works best is a five-part script:

• Welcome (5 min): Explain the session, get consent to record, remind them you are testing the prototype, not testing them.
• Background questions (10 min): Understand their current workflow. How do they solve this problem today? What tools do they use? What frustrates them?
• Prototype introduction (2 min): Set the scenario. "Imagine you just signed up for this product and today is your first time using it."
• Tasks (20 min): Give three to four specific tasks to complete. Watch without helping. Ask them to think aloud.
• Debrief (10 min): What stood out? What was confusing? Would they use this? Why or why not?

While the Facilitator runs each interview, the rest of the team watches on a shared screen in a separate room. Each observer takes notes using a simple grid: user name across the top, key moments down the side. After all five sessions, gather the team and look for patterns. If three out of five users got stuck at the same point, that is a real signal. If one user complained about something nobody else noticed, note it and move on.

By end of Friday you will have a concrete picture of what works, what is confusing, and what needs rethinking. That is a remarkable output for five days of work.

Running a sprint badly is worse than not running one at all. You burn a week of team time and come out the other end with false confidence. Here are the mistakes that derail sprints most often:

Picking the wrong problem to sprint on. Design sprints work best on specific, bounded problems with a clear user journey. If your sprint challenge is "how do we improve our entire product," you will spend Monday spinning and never land on a useful target. The best sprint challenges are specific: "how does a new user complete their first successful task in under five minutes?" Specificity gives the sketch phase direction and makes Friday's test results actionable.

No real Decider in the room. This is the single most common sprint failure. Teams go through all five days, generate great ideas, and then the actual decision-maker shows up on Friday and overrides everything. The Decider must be present for the full sprint, engaged in the exercises, and empowered to make binding calls on the spot. If you cannot get that commitment, wait until you can.

Too many people. Every person you add past seven increases the coordination overhead exponentially. Large groups produce politics, not ideas. If stakeholders insist on being included, give them the Expert role on Monday. They come in, share their knowledge for 20 minutes, and leave. They do not vote, they do not sketch, and they do not slow down the core team.

Skipping user testing. Some teams run Monday through Thursday and then skip Friday because "we already know what we want to build." This misses the entire point. The prototype is a hypothesis. Friday is the experiment. Without Friday you have done a lot of creative work with no validation whatsoever. Book the five users before the sprint starts so there is no temptation to cancel.

Treating the sprint as a commitment to build. The output of a sprint is learning, not a spec. If Friday testing reveals that users do not care about the feature you prototyped, that is a success. You just saved months of engineering effort. Celebrate it and sprint on something else.

The sprint ends Friday evening. You have notes, recordings, a prototype, and a clear picture of how five real users responded to your idea. Now what?

Start with honest interpretation. Gather the team on Monday morning and synthesize the Friday observations into three categories: what worked, what did not work, and what you still do not know. Be rigorous here. It is tempting to rationalize away negative signals because the team fell in love with a particular concept. Resist that. If users consistently failed at a task or expressed confusion about a core concept, that feedback overrides your internal enthusiasm.

From that synthesis, you have three paths:

• Strong positive signal: Users understood the concept, completed the tasks, and expressed genuine interest. You have enough confidence to move into detailed design and development. Bring your engineering team up to speed on the sprint output and start scoping the build.
• Mixed signal: Parts of the prototype worked well, others failed. This is actually the most common outcome and it is a good one. You now know exactly which elements to redesign. Consider running a focused second sprint on the specific area that did not land, or iterate the prototype and test with five more users before committing to a build.
• Negative signal: Users did not understand the value, did not complete tasks, or were not interested in the solution. This is the most valuable outcome of all, even if it does not feel that way. You have just avoided building something nobody wants. Go back to the problem definition and sprint on a different approach.

If you are moving forward with development, the sprint output becomes your foundational design brief. The storyboard, the prototype, and the annotated user testing findings replace a hundred hours of design discovery. Your engineers can start with a validated concept instead of a vague description. That alignment alone pays for the week you spent sprinting.

If your product needs to get from sprint to launched software quickly and cleanly, we can help. Book a free strategy call and we will walk you through how to turn your sprint results into a production-ready product.