Based on the book “Sprint” by Jake Knapp
Imagine spending six months building a product, only to discover users don’t want it. It happens more often than anyone likes to admit. A Design Sprint offers a different approach: a five-day process that helps teams solve big problems and test new ideas before committing more resources.
Jake Knapp created this method at Google Ventures after working with many startups. The main idea is to avoid spending months building something that might not work in the end.
It’s like taking a shortcut. Instead of launching a product and hoping customers like it, you build a realistic prototype and show it to real users in just five days.
Why Use a Design Sprint?
Design Sprints solve several common problems teams face.
Endless debates can slow teams down. People share many opinions in meetings, but reaching decisions is hard. A Design Sprint adds structure, helping teams move quickly from debating to doing.
Wasting resources is another major concern, especially for entrepreneurs. Building the wrong product is expensive. A startup might spend six months and a lot of money on features no one uses. With a Design Sprint, teams can test and validate ideas early, saving both time and cost.
During a Design Sprint, everyone sketches solutions individually. The team then reviews these ideas anonymously to choose the best solution, regardless of who suggested them.
Example: A company wants to build a new onboarding flow for its app. A traditional approach might involve weeks of planning, months of development, and only then discovering that users find it confusing. With a Design Sprint, the team can prototype the flow, test it with five users, and learn what works before writing any code — all within a week.
Before You Start: The Team
A Design Sprint needs the right people in the room. Knapp recommends a team of four to seven people with two essential roles:
The Decider is the person who makes the final decisions. This is usually the CEO, founder, product lead, or department head. If the team can’t agree, the Decider chooses. Without a Decider, Sprints can get stuck in endless debates.
The Facilitator runs the Sprint by tracking time, guiding activities, and ensuring everyone stays focused. They don’t need to be a design expert, but they should be organised and comfortable leading the group. An Agile coach or Scrum Master can be a perfect fit for this role.
The rest of the team should bring different perspectives. Include engineers who know the technical side, designers who can build prototypes quickly, customer-facing staff who understand user problems, and subject matter experts who know the challenge well.
One key rule: no laptops or phones during Sprint activities. Given the short Sprint duration, devices can distract, so everyone needs to stay focused and present.
The Five-Day Process
Monday: Map and Target
The team begins by defining the problem. Create a simple journey map that shows how customers interact with your product or service, from first discovery to reaching their goal. Keep it simple: actors on the left, end goal on the right, steps in between.
Key activities:
Set a long-term goal. Think about what you want to achieve in six months, a year, or even longer. Write this goal on a whiteboard so everyone can see it all week.
List your Sprint questions. Ask yourself what assumptions you are making, or what constraints you have that might cause the project to fail. These questions will help guide your testing on Friday.
Ask the Experts. Interview stakeholders and subject matter experts on the team. The Facilitator guides short conversations (15–30 minutes each) where experts share what they know about the customer, the technology, and past attempts to solve this problem.
The team takes notes and captures “How Might We” questions — these are open-ended prompts that reframe problems as opportunities. For example, “Users abandon checkout” becomes “How might we make checkout feel effortless?” These questions guide ideation on Tuesday.
Pick a target. Choose one specific customer persona and one specific moment in the journey to focus the Sprint on. You can’t solve everything in five days, so pick the moment that matters most.
Example: A coffee delivery startup maps out the customer journey: Customer sees an ad, downloads the app, browses the menu, places their first order, receives coffee, and then reorders. After talking to experts, they learn that 60% of users leave during checkout, so they decide to focus on the “Place first order” step.
Tuesday: Sketch
Tuesday is dedicated to coming up with solutions. The focus is on thinking carefully and working on your own ideas, instead of group brainstorming.
Key activities:
Lightning Demos. The team spends the morning reviewing inspiring solutions from competitors, other industries, and even unrelated products. Each person presents a three-minute demo of something worth borrowing. The point isn’t to copy, it’s to collect raw material for new ideas.
Sketch solutions. In the afternoon, everyone draws their own solution on paper. You don’t need design skills; stick figures and boxes are fine. What matters most is your thinking behind the sketch.
Solutions remain anonymous during Wednesday’s upcoming review, so people judge ideas on merit, not on who proposed them. By the end of Tuesday, each person will have a complete solution sketch ready for the next day.
Wednesday: Decide
The team reviews all sketches and decides which ideas to prototype. This uses structured voting to avoid endless debate.
Key activities/techniques:
Art museum. Tape all solution sketches to the wall. Everyone walks around quietly, reviewing each one of them.
Heat map. Each person puts small dot stickers on the parts they find interesting. There is no discussion at this stage. Groups of dots show which ideas stand out.
Speed critique. The Facilitator leads a quick three-minute discussion about each sketch, focusing on the best ideas and any major concerns. The person who created the sketch remains silent until the end.
Straw poll. Each team member, except the Decider, votes for one solution they think should be prototyped.
Supervote. The Decider makes the final call with three special votes. These votes determine what gets prototyped. The Decider considers the straw poll but isn’t bound by it.
Storyboard. The team creates a step-by-step plan for the prototype, usually with 10 to 15 frames that show the user’s journey through the chosen solution. This plan will guide the team’s work on Thursday.
Example: The coffee app team looks at six sketches. Dot voting shows strong interest in two ideas: a “quick reorder” button and a “build your own bundle” feature. The Decider picks the quick reorder idea because it directly addresses the checkout abandonment problem.
Thursday: Prototype
Build a realistic-looking prototype in one day. This is not a working product; it is just a model that looks real enough to get honest reactions from users.
Key principles:
Pick the right tools. Use whatever helps you move fast. Keynote, PowerPoint, or Figma. The goal is something clickable that simulates the real user experience.
Divide and conquer. Assign roles to the team: Makers build the prototype, Stitchers put the pieces together, Writers create realistic text, Asset Collectors find images and icons, and the Interviewer gets ready for Friday’s tests.
Focus on the storyboard. Only build what you need to test the target customer journey. Leave out anything that is not necessary.
Example: For the coffee app, the team creates Figma screens that show the ordering flow with the new quick reorder feature. The buttons do not actually process orders, but users can tap through the experience as if it were real.
Friday: Test
Five target customers test the prototype in one-on-one interviews. The team watches and takes notes during these sessions.
Key activities:
Five interviews. Knapp recommends testing with exactly five users. Research shows that this number finds most usability issues. Testing with more users gives less new information, while fewer users may miss important patterns.
The interview structure:
- Friendly welcome to put the user at ease
- Context questions about their background and current habits
- Introduction to the prototype
- Tasks: Ask them to complete specific actions while thinking aloud
- Debrief: Quick questions about their overall reaction
Watch together. The team observes from another room using screen share or video feed. This way, everyone sees the same reactions and builds a shared understanding.
Take notes. Each team member writes down quotes and observations on sticky notes. Use one colour for positive reactions and another for negative ones.
Find patterns. After all five interviews, the team reviews the notes together. If three or more users have the same reaction, it is important. You will quickly see what works and what confuses people.
By Friday afternoon, you will have evidence to answer your Sprint questions. You might find that your idea works well, needs some changes, or should be dropped. All three outcomes are valuable because you have learned in days what could have taken months.
Benefits of Design Sprints
- Speed. You compress months of work into a week. Even if the idea fails, you’ve only spent five days instead of six months.
- Evidence over opinions. Instead of debating who’s right, you test with real users. The data decides.
- Team alignment. Everyone participates in the same intensive process. By the end, there’s a shared understanding of the problem and solution.
- Reduced risk. Testing before building means you invest resources in ideas that have evidence of working.
- Momentum. The time pressure helps everyone focus. There’s no room for perfectionism or office politics; the goal is to learn quickly.
- Cross-functional collaboration. Engineers, designers, marketers, and executives work side by side. This breaks down silos and builds shared understanding across disciplines.
When Not to Use a Design Sprint
Design Sprints aren’t right for everything:
- Incremental improvements. If you just need to tweak button colours or fix minor bugs, a Sprint is overkill.
- Well-understood problems. If the team already agrees on the solution and has high confidence, just build it.
- Lack of Decider availability. Without someone empowered to make decisions present for all five days, the Sprint stalls.
- Team unavailability. Everyone needs to be present and focused for all five days. If key people can only join for part of the time, wait until everyone’s schedules match.
- Premature optimisation. Don’t run a Sprint to perfect something that’s already working. Save it for big, uncertain challenges.
Getting Started
If a Design Sprint sounds right for your challenge, preparation matters. A well-run Sprint requires more than enthusiasm; it needs the right conditions. If you’re considering running a Design Sprint, then start with:
- Find a real challenge. Choose something your team is truly struggling with, not just a theoretical problem. Good Sprint challenges matter to the business, have a clear outcome you can test, and involve real uncertainty.
- Get Decider commitment. Make sure someone with authority can participate for all five days. Partial attendance from the Decider undermines the entire process.
- Assemble the right team. Four to seven people with diverse perspectives. Include at least one person who can quickly build a prototype.
- Block the calendars. Set aside five full days with no interruptions. Make sure everyone’s schedule is clear. This is essential because the time pressure is what makes Sprints work.
- Prepare the space. You need a dedicated room with lots of whiteboard space, sticky notes, markers, and dot stickers. No distractions. It will be even better if you can assemble in a room and do this face-to-face.
- Read the book. Jake Knapp’s “Sprint” provides detailed facilitation guides for each exercise, including scripts for Friday interviews and tips for common problems.
- Start small. Run your first Sprint on a contained problem before tackling your biggest challenges. The team needs to experience the process before applying it to high-stakes decisions.
The Design Sprint doesn’t promise success, but it promises learning. And unlike traditional approaches, you learn in days, not months. That’s the real value: turning uncertainty into insight before the stakes get high.
Leave a Reply