The design sprint, popularized by Jake Knapp during his time at Google Ventures, compresses months of debate, design, prototyping, and user testing into five focused days. It’s one of the few product development processes that consistently produces actionable results – not because the methodology is magic, but because it forces a team to stop talking about what they might build and start showing it to real users. Done well, a design sprint saves weeks of wasted development time by validating (or killing) ideas before a single line of code is written. Done poorly, it becomes an expensive week of Post-it notes that leads nowhere.
Before the Sprint: Setting Up for Meaningful Results
The week before the sprint determines whether it produces real insights or an exercise in corporate theater. Three setup tasks are non-negotiable.
First, define the sprint question. This is the specific challenge the sprint will address, framed as a question. “How might we reduce the time it takes a new customer to complete their first order from 15 minutes to under 3 minutes?” is a good sprint question. “How do we make our product better?” is not. The question should be important enough to justify pulling a cross-functional team away from their regular work for a week, and specific enough that the team can evaluate whether the prototype answers it.
Second, assemble the right team. A design sprint typically includes five to seven people: a Decider (someone with the authority to make product decisions and commit resources), a facilitator (someone experienced in running sprints), a designer, one or two engineers, a product manager or domain expert, and ideally someone from customer support or sales who hears user pain points daily. Having an engineer in the room prevents the team from prototyping something technically impossible, and having a customer-facing team member keeps the conversation grounded in real user behavior rather than assumptions.
Third, recruit test users. You’ll need five users for Friday’s testing sessions. Research by Jakob Nielsen demonstrated that five users uncover roughly 85 percent of usability issues. These should be people in your target audience who haven’t been involved in the sprint – fresh eyes who will interact with your prototype the way a real customer would. Recruit them before the sprint starts and schedule 60-minute sessions for Friday. Offering compensation ($50-100 gift cards for consumers, more for specialized B2B users) dramatically improves show-up rates.
Monday: Map the Problem Space
Monday is about building shared understanding. The team maps the user journey, identifies the biggest pain points, and selects a specific target for the sprint.
Start with expert interviews. Invite three to four people who understand different facets of the problem – a customer support lead who knows the top complaints, a data analyst who can share behavioral metrics, a sales rep who hears objections daily. Each gives a 15-minute presentation followed by questions. The team takes notes in the form of “How Might We” (HMW) questions: “HMW reduce the number of fields in the signup form?” or “HMW show the value proposition before asking for personal information?”
Next, create a customer journey map on a whiteboard. This isn’t a polished artifact – it’s a rough flow diagram showing the key steps a user takes from their initial motivation through completion of the task. For an e-commerce onboarding sprint, the map might flow: Discover product, Visit landing page, Create account, Browse catalog, Add to cart, Enter shipping info, Pay, Receive confirmation.
Cluster the HMW notes along the journey map. Patterns will emerge: maybe the pain is concentrated at the account creation step, or maybe the checkout flow generates the most confusion. At the end of Monday, the Decider selects the specific moment in the journey that the sprint will focus on. This decision narrows the scope and prevents the team from trying to solve everything at once.
Tuesday and Wednesday: Sketch and Decide
Tuesday is the most creatively demanding day. Individual team members sketch solutions independently, then the group evaluates and selects the strongest ideas.
Begin with “Lightning Demos” – 15-minute presentations of existing products (competitors, analogous solutions from other industries) that handle the target problem well. Studying how Duolingo onboards users, how Stripe handles checkout, or how Airbnb builds trust can spark ideas that go beyond the team’s usual thinking patterns.
Then move to individual sketching. This is not brainstorming – it’s the opposite. Each person works alone for 60 to 90 minutes, developing their best solution in detail. The output is a three-panel storyboard (Knapp calls it the “Solution Sketch”) that shows the key screens or steps of their proposed solution. Anonymous sketching prevents groupthink and gives introverted team members equal voice.
On Wednesday morning, the team reviews the sketches using a structured process. Tape all sketches on a wall. Each team member silently reviews them for 20 minutes, placing small dot stickers on elements they find compelling. Then discuss the clusters of dots – what drew people’s attention and why. Finally, the Decider selects the sketch (or combination of elements from multiple sketches) that will become the prototype.
Create a detailed storyboard – typically 10 to 15 panels – that maps out the user experience of the selected solution from start to finish. This storyboard is the blueprint for Thursday’s prototyping work.
See also: Designing Data-Heavy Applications: Tables, Charts, and Dashboards
Thursday: Build a Realistic Prototype
Thursday is prototyping day, and the key word is “realistic.” The prototype must be convincing enough that test users interact with it as if it were a real product. Cardboard mockups and napkin sketches won’t generate valid feedback. But you also don’t need to build a functional application – you need a facade.
Figma is the standard prototyping tool for digital products, and for good reason. A skilled designer can build a clickable prototype in Figma that looks and feels like a real application in six to eight hours. Include realistic content (not lorem ipsum), appropriate imagery, and functional navigation between the screens in your storyboard. Use Figma’s prototyping features to add transitions, hover states, and conditional flows that respond to user clicks.
Divide the work. The designer handles visual design and interaction prototyping. Another team member writes realistic content – product descriptions, error messages, confirmation text. Someone else prepares the testing script and discussion guide. The engineers can help with any technical components that need to feel real – if the prototype includes a data visualization, they might create a realistic chart in a tool like Observable or even a static screenshot from a development environment.
A common mistake is over-prototyping. You don’t need every screen – only the ones in the storyboard that test users will encounter during the test scenarios. If a secondary settings page isn’t part of the test flow, don’t build it. Spend the time instead on making the critical-path screens as polished and believable as possible.
By end of day Thursday, do a dry run. Have someone who wasn’t involved in the sprint walk through the prototype while the team watches. Fix any confusing transitions, missing screens, or dead-end clicks.
Friday: Test With Real Users and Synthesize Findings
Friday is the payoff. Five test users, each in a separate 60-minute session, interact with the prototype while the team observes.
The facilitator runs the sessions one-on-one in a quiet room, while the rest of the team watches via a screen-share or live stream in another room. This separation is important – having six people staring at the user while they click through a prototype changes behavior. The observers take notes on a shared grid: one column per user, one row per key moment in the prototype.
Use the “think-aloud” protocol: ask the user to narrate their thought process as they interact with the prototype. “I see a form here… I’m not sure what this field means… I think this button will take me to checkout.” The narration reveals mental models, expectations, and moments of confusion that clicking behavior alone doesn’t capture.
After each session, the team spends 10 minutes noting their observations. After all five sessions, patterns become clear. If four out of five users struggle with the same interaction, that’s a strong signal. If three users spontaneously praise a particular feature, that’s validation. If users consistently try to use the product in a way the team didn’t intend, that’s a discovery.
Synthesize the findings into three categories: things that worked (validate and keep), things that need iteration (the concept resonated but the execution needs refinement), and things that failed (users didn’t understand them, didn’t want them, or actively disliked them). Present these findings to the broader organization on the following Monday with specific recommendations for next steps.
After the Sprint: Turning Insights Into Action
A design sprint is not a product launch plan. It’s a learning event. The sprint’s value is realized only when the organization acts on what it learned.
For validated concepts, the next step is typically a more detailed product specification and a development plan. The prototype and test results serve as a communication tool for engineering: “here’s what we’re building, here’s why users responded to it, and here’s the specific interaction patterns that tested well.” This drastically reduces ambiguity compared to a written requirements document.
For concepts that need iteration, schedule a follow-up mini-sprint (two to three days) to revise the prototype based on user feedback and test again. Don’t jump straight to development with a half-validated concept.
For failed concepts, celebrate the learning. You spent one week and discovered that an idea doesn’t work, instead of spending three months building it and discovering the same thing in a much more expensive way. Document what didn’t work and why, so the organization doesn’t revisit the same dead end later.
Design sprints work best as a recurring practice, not a one-time event. Run a sprint at the beginning of each major product initiative, when facing a strategic decision that the team can’t resolve through discussion alone, or when user feedback suggests a fundamental problem with an existing feature. Over time, the sprint process becomes a shared vocabulary for how the team approaches uncertainty: don’t debate, prototype, and test.
A well-run design sprint can save your team months of building the wrong thing. If you’re planning a sprint and want an experienced facilitator or need help turning sprint results into a development roadmap, reach out to us.