Design Sprints

What Is a Design Sprint?

A Design Sprint is a 5-day process for solving big problems and testing new ideas quickly. It was invented by Jake Knapp while he was working at Google Ventures, and it has become one of the most important tools in the world of design and product development.

The idea is simple: instead of spending months building a complete product only to discover it doesn't solve the problem, you can build a prototype in 5 days and test it with real users. This saves an enormous amount of time, money, and effort.

A Design Sprint isn't just for large companies. Any team — even two people — can use this methodology. And as a UX/UI designer, understanding Design Sprints gives you a major advantage in the market because you can lead this process.

Jake Knapp documented the methodology in his book "Sprint," which has become one of the most important books in the field. If you haven't read it, it needs to be on your reading list.

Day 1: Understand (Map)

Day 1 is all about understanding. The goal is to get the entire team on the same page regarding the problem you're solving.

Activities:

Define the long-term goal: Start with the question: if everything goes right, where will we be in two years? This guides all subsequent decisions.

Sprint questions: Flip the goal into questions. Instead of "we want to increase sales" say "can we make the purchase process 50% easier?"

Draw the map: Draw a simple map of the user journey from start to finish. It doesn't need to be detailed — the goal is for it to be clear to the entire team.

Ask the experts: Set aside time for team members with specific expertise to share their knowledge. This could be someone from the sales team, someone from technical support, or even a customer.

Choose a target: At the end of the day, the team selects a specific part of the map to focus on for the rest of the Sprint. You can't solve everything in 5 days, so you must focus.

Tips for Day 1:

• Keep the team small: 4–7 people. More than that becomes chaotic.
• Having a Decision Maker in the room is essential. There must be someone who can make decisions.
• Use Post-it notes heavily. Every idea or observation on its own note.

Day 2: Ideate (Sketch)

Day 2 is the day of solutions. Each team member works individually to sketch proposed solutions.

Activities:

Lightning Demos: Each person presents inspiring examples from other products. They don't have to be in the same industry — inspiration can come from anywhere. Allow 3 minutes per presentation.

Individual sketching: Each person sketches their proposed solution on paper. This is the most important activity of the day. The sketch must be detailed enough for someone else to understand it.

The sketching technique:

1. Notes: Write initial notes and ideas.
2. Ideas: Draw quick, simple ideas.
3. Crazy 8s: Fold a piece of paper 8 times and draw 8 different ideas in 8 minutes. This forces you to think outside the box.
4. Solution Sketch: Draw a detailed solution in 3 parts (3 steps or 3 screens).

Why individual sketching matters:

In traditional group brainstorming, the loudest voice in the room wins. Individual sketching allows everyone to think deeply and present their best solution without pressure.

Tips for Day 2:

• Don't worry about drawing quality. The idea is what matters.
• The sketch must be understandable without explanation — that's the test.
• Encourage bold ideas. There are no wrong ideas at this stage.

Day 3: Decide

Day 3 is where you make a decision: what solution will you build as a prototype.

Activities:

Art Museum: Post all the sketches on the wall and let everyone look at them in silence. This prevents the sketch's author from influencing others' evaluations.

Heat Map Voting: Each person takes dot stickers and places them on the parts they liked in any sketch. This is silent voting.

Speed Critique: The team discusses the sketches with the most votes. 3 minutes per sketch. The author doesn't speak — the others discuss.

Super Vote: The Decision Maker makes the final call. They can choose one solution or combine parts from different solutions.

Create the Storyboard: After choosing the solution, the team draws a storyboard of 10–15 steps showing the complete user experience. This will be the roadmap for the prototype.

Tips for Day 3:

• Keep the voting silent to avoid groupthink.
• The Decision Maker has veto power — this is important for accountability.
• The Storyboard must be realistic and specific. You don't want anything vague.

Day 4: Build (Prototype)

Day 4 is the hard work day. The team builds a prototype realistic enough to be tested with real users.

The prototype doesn't need to be complete:

The core rule: the prototype must be realistic enough for the user to interact with it naturally, but it doesn't need to be a finished product. This is what Jake Knapp calls "Goldilocks quality" — not too much, not too little.

Prototyping Tools:

• Figma: Best for most cases. You can build an interactive prototype quickly.
• Keynote/PowerPoint: If the prototype is a presentation or a step-by-step process.
• HTML/CSS: If you need complex interactions.
• Framer: If you need advanced animations.

Role Distribution:

• Makers (2–3 people): The ones who actually build the prototype.
• Stitcher (1 person): Connects the pieces together and ensures the flow is smooth.
• Writer (1 person): Writes the copy. Realistic text matters — Lorem Ipsum reduces the authenticity of the test.
• Asset Collector (1 person): Gathers the images, icons, and content needed.

What to include in the Prototype:

• The core happy path (the ideal scenario)
• 2–3 main screens with sufficient detail
• Basic interactions: navigation, buttons, inputs
• Realistic content, not placeholders

Tips for Day 4:

• Start early. This is the longest day of the Sprint.
• Don't try to build everything. Focus on the core experience.
• Do a trial run at the end of the day. Ask someone not on the team to try the prototype.

Day 5: Test

The final day is the moment of truth. You test the prototype with 5 real users and learn.

Why 5 users?

Jakob Nielsen showed that 5 users uncover 85% of usability problems. More than that yields diminishing returns. The tests are conducted one-on-one, not in groups.

Preparing the Test:

• Prepare a clear scenario. What will you ask the user to do?
• Prepare open-ended questions. Instead of "Is this easy?" ask "Tell me what you're thinking right now."
• Set up the space: camera or screen recording, paper and pen.
• Decide who will run the test and who will observe. The rest follow along from another room or screen.

During the Test:

• Start with general questions about the user's background. Let them get comfortable.
• Ask them to think out loud while using the prototype.
• Don't help or guide them. If they get stuck, ask "What are you looking for?"
• Record every observation. Use Post-its in different colors: green for positives, red for negatives, yellow for observations.

After the Tests:

• Gather the team and do pattern recognition. What things came up repeatedly?
• Categorize the findings: things that worked, things that need adjustment, things that failed.
• Write down the next steps. What will you do based on what you learned?

How to Convince Your Team to Run a Design Sprint

One of the biggest challenges is convincing management or the team to dedicate a full week to a Design Sprint. Here are some strong arguments:

• Cost savings: Instead of building a product over 3 months and discovering it's wrong, you discover that in 5 days.
• Focus: The team clears their schedule and concentrates on one problem. This is rare and highly valuable.
• Alignment: After the Sprint, the entire team understands the problem and solution the same way.
• Evidence: Instead of opinions and assumptions, you have real data from real users.

You can start with a Mini Sprint lasting two or three days to prove the value, then run a full Sprint.

Real-World Design Sprint Examples

Slack: Before launching Slack Channels, they ran a Design Sprint to test the concept. Testing revealed that users needed a clearer way to organize conversations, which significantly changed the final design.

Blue Bottle Coffee: Used a Design Sprint to design the online ordering experience. They discovered that users didn't need all the options they were considering adding, and simplified the experience significantly.

Savioke: A robotics company used a Design Sprint to design the interface for a hotel delivery robot. In 5 days, they discovered that guests treated the robot as a person and expected social interaction — this completely changed the design.

Modifications to the Original Methodology

Jake Knapp's original methodology doesn't need to be applied literally. Over time, many people have adapted it:

• Remote Design Sprint: After COVID-19, many teams run the Sprint remotely using Miro or FigJam. It works well but requires stronger facilitation.
• 4-Day Sprint: Jake Knapp himself developed a 4-day version by merging days 1 and 2. Can work for simpler problems.
• Lightning Sprint: An intensive one-day version. Doesn't offer the same depth but can be sufficient for specific problems.

More important than following the methodology literally is understanding the philosophy behind it: focus on the problem, build a quick solution, and test with real people. That's what separates a designer who hopes their solution is right from a designer who has evidence.