What a Design Sprint Actually Does

A design sprint answers a specific product question in five days by:

1. Understanding the problem deeply (Monday)
2. Generating solution concepts (Tuesday)
3. Deciding on one approach to prototype (Wednesday)
4. Building a high-fidelity prototype (Thursday)
5. Testing with 5 real users (Friday)

The output isn't code. It's a prototype that has been tested with real users and a set of validated insights about whether the proposed solution works.

Why this is valuable: you spend 5 days (and the cost of a week's team time + recruiting) to answer a question that would otherwise take 2–3 months of building and testing. The savings are massive when the question is the right one.

The Right Question for a Sprint

Design sprints work best for high-stakes, uncertain questions where getting the answer wrong is expensive. Examples:

• "Is this onboarding flow understandable to first-time users?"
• "Will users understand how to use this new interaction pattern?"
• "Which of these two positioning approaches resonates better with our target customer?"
• "Is there a way to solve this workflow that users will adopt without training?"

Design sprints are not right for:

• Questions that could be answered with a quick user interview
• Decisions that are already made (sprint results being ignored because leadership has already decided)
• Technical architecture questions (sprints are for product/UX questions)
• Very early-stage idea validation (discovery research comes first)

If your question doesn't have a clear answer that a prototype test could reveal, reframe it before running the sprint.

The Five Days, Concisely

Monday (Understand): Map the problem space. Interview experts. Create a simple problem map showing the user journey and where things break down. Define the sprint question: what one problem are you solving this week?

Tuesday (Ideate): Individual sketching, not group brainstorming. The Lightning Demos exercise (share examples of good solutions from other domains) followed by structured sketching (Crazy 8s then detailed solution sketches) produces more diverse, higher-quality ideas than group brainstorm sessions.

Wednesday (Decide): Review all sketches silently. Vote with dot stickers. Discuss the leading contenders. The Decider (typically the product or team lead) makes the final call. Create a storyboard of the prototype you'll build.

Thursday (Prototype): Build a realistic prototype. "Realistic" means high-fidelity enough that users will respond to it honestly — Figma prototypes work for most product questions. Don't code anything. One or two people build the prototype while others prepare interview scripts and logistics for Friday.

Friday (Test): Interview 5 users. Each interview is 45–60 minutes: brief context-setting, tasks to complete with the prototype, think-aloud commentary. The team watches via video feed and takes notes. After all interviews, debrief: what patterns appeared? What worked? What didn't?

Why Five Users Is Enough

Jakob Nielsen's research established that 5 usability test participants identify approximately 85% of usability problems. Each additional user beyond the first 5 reveals diminishing new insights. For a one-day test session, 5 users is the right balance between insight quality and schedule feasibility.

Recruiting 5 users in advance is the most common sprint logistical failure. Start recruiting at least 2 weeks before the sprint. Screen carefully — the wrong participants give you misleading data.

What Happens After the Sprint

The sprint is over in 5 days, but the work isn't. The Friday test gives you a decision: the proposed solution works (build it), the solution has specific problems to fix (adjust and test again), or the solution doesn't work (go back to problem definition).

A sprint that shows a solution doesn't work is a success, not a failure. You've just saved months of engineering time. Treat it accordingly.

Common mistake: running a sprint, getting mixed results, and then building the original solution anyway because it was already planned. If you're not prepared to change direction based on the sprint results, don't run a sprint.

Adapting for Remote Teams

A remote design sprint requires more structure but works. Key adaptations:

• Use FigJam or Miro instead of whiteboards and sticky notes
• Record all video calls so team members can catch up if needed
• Ship physical materials (sticky notes, markers) to participants if possible to increase engagement
• Schedule user interviews across a longer window (rather than 5 back-to-back)
• Build extra buffer into Thursday — remote prototype building is slower than in-person

The most important adaptation: have a skilled facilitator. Remote sprints drift more than in-person sprints, and a facilitator who can keep the group focused and on schedule is worth more in a remote context than an in-person one.