A Comprehensive Guide to Running Design Sprints

Featured in Creativity
Image credited to Adobe Stock.
A Comprehensive Guide to Running Design Sprints

Suppose you want to release a new product on the market and you’ve got an idea for a great solution. To test this idea, you want to build a lightest possible version of a product, launch it into the wild, measure and learn from the results, and iterate to improve the product. While this approach seems like a good idea at first, it has one significant problem — the outcome is directly related to the original idea.

So what happens when you start with a bad idea? When you invest a lot of time building out an idea, you don’t want to go back even when you realize that idea isn’t good. The product you’re building is your baby now, and it can be hard to see its faults. Launching it may result in a product failure, so the next iteration won’t be an improvement of this idea but instead a quest to find a different one.

It’s clear that following a traditional waterfall or Lean Startup approach for building products won’t guarantee that a final result will be any good. When you have an idea, you need to learn, really quickly, whether or not to invest time in it. But how do you do it? In an attempt to answer this question, Google Ventures (GV) proposed a shortcut to the full-circle design process — rather than going through the whole circle of Ideate-Build-Launch-Learn, the team uses the Ideate-Learn parts only. That’s how the idea of design sprint was born. These sprints helped Google improve Gmail and Google Hangouts.

A Design Sprint is a shortcut of learning. Image credited to GV.

In this article, I’ll review the concept of a design sprint. I hope that, after reading this article,  it will encourage you to run your first sprint.

What is a Design Sprint?

A Design Sprint is a five-day design framework for validating ideas and solving challenges. It helps you find answers to critical business questions through research, ideation, prototyping, and testing. It’s designed to iterate through decisions and test different alternatives in a very compressed time frame before even building a minimum viable product (MVP).

Design Sprints are very prescriptive — it’s almost like a cookbook which tells you what you should do and in what order. Each activity should be finished during the given amount of time, and you should be able to go from original idea to tested prototype in just five days. The GV team believes that the best ideas seem to come from the tightest constraints. Deadlines create time pressure and help a team get things done.

Why Design Sprints are good

The Sprint methodology shortcuts months of development — it allows you to fast-forward into the future to see your finished product and customers’ reactions to it before making any risky and expensive commitments.

This methodology has the following advantages:

  • Speed. Sprints allow you to compress months of work into a few days of focus and productivity.
  • Collaboration. Product team members and stakeholders work together on solving a problem, and this allows a deeper understanding of each other’s work.
  • Validation. You’ll get a feedback on new product ideas before building anything.

When is the right time to run a Sprint?

There are few cases when a Design Sprint is especially effective:

  • When you have a strict deadline and want to get things done quickly (e.g. you have a deadline for shipping a product or feature).
  • When big challenges need to be solved (e.g. you need to create a big product and it’s impossible to solve all challenges at once).
  • When you’re stuck with design decisions (e.g. there are a few thoughts about how design should be done in a team, and it’s not clear which one is the right one).

Who runs a Design Sprint?

Design Sprints are run by teams. If you don’t have a team, the Sprint doesn’t really happen. It’s essential to have a group of people coming together from different disciplines (e.g. product management, design, engineering).

To facilitate a Design Sprint, you need two specific roles — the facilitator and the decider.

  • The Sprint facilitator is a person who has Sprint expertise. The facilitator role keeps the sprint on track and makes sure the team is doing the right exercises. Facilitators focus on achieving a common goal to make sure that everyone works efficiently. It’s better to avoid combining this position with other roles (i.e. if a facilitator acts as a designer, s/he won’t be able to facilitate efficiently).
  • A decider is the person who has the ultimate say. While everybody can propose their solutions, at the end of the day it’s the decider who makes a decision about what solution to choose. You should pick this role on the first day of the Design Sprint.

In term of numbers, you should strive for a team of six people. The minimum possible number of team members is four (you should have a couple of disciplines in the room, with one of them being the facilitator). The maximum possible number of team members is eight (if you have more people on the team it can get unruly and hard to control).

The five phases of a Design Sprint

Each Design Sprint consists of the following five phases.

  • Day 1: Understand.
  • Day 2: Sketch.
  • Day 3: Decide.
  • Day 4: Prototype.
  • Day 5: Validate.

 

 

Image credited to thesprintbook.

Each phase solves an important part of the design process, and you’ll have just one day for each phase. At the end of the week, you’ll end up with a concrete working prototype.

Let’s walk through each step of the five-day process.

Understand (Monday)

This is a foundational day for the rest of your Sprint. To build a good solution, you need to understand the problem first. During this phase, you’ll try to get clarity on the business goals, the problem that you’re solving, and the user needs. The goal is to create a shared vision for the team to help them understand what they’re working towards.

Since this day is very loaded with actions, it’s recommended you split it into two parts — morning and afternoon. In the morning:

  • Start at the end. Setting your long-term goals is essential. Imagine where the product will be in 6/12/24 months and set an optimistic future. Encourage everyone to think about the perfect outcome. This will help you set the bar for your product.
  • Create a basic map for the product. Once you have your goals, it’s time to visualize what your product’s user experience might look like. Create a basic map for the project which shows how users will go through your product or service. Keep it simple — it should be 5-10 steps max.
List user personas on the left side and the end goal on the right side of the map. Personas reach the desired end goal in around 5 to 10 steps. Image credited to thesprintbook.

After lunch:

  • Ask the experts. Before trying to build something, you need to hear the opinions of people who are experts on some part of the problem. Bring them into the room and explain what are you trying to build. Show them the map you created and ask for their opinions. The big goal is to have them improve your map.
  • Use the “How might we…?” technique. While your team members listen to the expert’s interviews, ask them to take notes. Each team member should take notes in the form of a question, beginning with the words “How might we…” This technique ensures all notes have a similar format and makes it easier to organize, read, and evaluate them.
When taking notes always start with the words "How might we…" Image credited to Google.
  • Pick a target for the sprint. The final step of day one is to identify the one specific target for the sprint. The information collected during the expert’s interview and “How might we?” sessions will help to make this decision.

Tips:

  • Look at the problem from the perspective of technology, businesses, and users. It’s recommended to start with user research: talk to users and learn about their needs. Then invite stakeholders and ask them to tell you about their business objectives. Finally, ask engineers what’s feasible and what’s not.
  • Set the bar. Once you bring your product to the market, you need to make sure it’ll be successful. Thus, it’s essential to establish criteria for success by answering the following questions: What would success/failure look like? How will we measure success? What is our KPI?

Sketch (Tuesday)

While Monday is all about understanding the problem, Tuesday is all about solutions. During this phase, each team member will put pen to paper and sketch competing solutions. Sketching is a great way to move from abstract idea to something concrete that everyone can evaluate. Some of the sketches you’ll create on Tuesday will be the building blocks of the prototype you’re going to build on Thursday and test on Friday.

Sketch answers to specific questions such as 'What would an interface look like' in an easy-to-understand format. Image credited to Google.

It’s worth splitting Tuesday into two parts, as well. Start with an exercise called a lightning demo. Lightning demos allow you to review great solutions from other companies. Often, great ideas have been pitched in the past, and all you need to do is to find the one that fits your purpose. Choose one person from your team to capture ideas and use a whiteboard to record what people like about each example.

Look at competing products and things created by other teams. Image credited to sprintstories.

The afternoon is best used for actual sketching. To increase the speed of sketching it’s recommended to use the Crazy 8’s technique — each team member takes an idea that most excites them and rapidly sketches eight variations for this idea in eight minutes. For example, if you design a product page this might be eight variations of that page. By the end of the day, you should have a tall stack of solutions to the problem.

The Crazy 8’s technique. Image credited to tandemseven.

Tips

  • Make your sketch self-explanatory. Everybody on your team should be able to understand what you have on a sketch. It’s better to use real copy instead of Lorem Ipsum and place interactive elements, like buttons, in places where they’re supposed to be. This will also help translate the sketch from low-fidelity to high-fidelity.
  • Each team member should work alone and keep sketches anonymous. When sketching ideas, each person should work on their own. There should be no bias about which sketch belongs to whom.
  • Don’t try to make your sketch pretty. Don’t worry if your sketch is ugly. Finished sketches shouldn’t be works of art. As long as it clearly expresses your solution, it’s good enough.
  • Try to sketch a flow instead of individual screens. When you’re sketching, try to sketch in 3-4 step flows and not just in individual screens — it’ll help you unpack the ideas you want to make and lay them out in a storyboard. Use arrows and text description to make it clear how users will interact with screens.

Decide (Wednesday)

When you meet on the third day, you’ll have many solutions sketched up. Now it’s time to filter them down and choose the best one. At the end of this phase, the team comes to a conclusion about what they want to build for their prototype.

The first part of the day will be all about voting. The technique that is traditionally used for voting is called sticky decisions. Team members put all the solutions on the board and everyone votes for the solution they think is the right one. Each team member votes with colorful stickers, which they pin to the board next to the solution they like. Sometimes votes are separated equally between two or even three ideas — in such cases, you’ll need to build a few prototypes.

Sticky decisions. Everyone reviews the sketches and decides which one they like. Each member votes with a sticker by pinning it to the board. Image credited to Google.

During the second part of the day, the winning idea (or ideas) gets carefully storyboarded in greater detail. A storyboard is a frame-by-frame plan for your prototype. Team members will take the sketches and redraw or stick them (physically) to the whiteboard. At the end of the day, a storyboard should be as complete as possible. It’s essential to fill in all the missing pieces before moving to prototyping (if someone in your team asks “What happens next?” when reading the storyboard it’s clear sign some frames are missing).

Your storyboard is an entire experience. Image credited to thesprintbook.

Tips

  • Avoid inventing new ideas during the Decide phase. The best ideas always seem to come at the last minute. It’s tempting to add something new, especially when you know so much about the project, but it’s better to avoid that temptation. At this point in the Design Sprint, the team has already eliminated many ideas.
  • Follow the one-frame-per-minute rule. GV suggests that each frame of the storyboard should take no more than one minute during testing. When you convert your storyboard into a prototype, testing the prototype should take no more than 15 minutes.

Prototype (Thursday)

During this stage, you want to create an actual prototype that you’re going to test with real users. Prototyping is a culmination of all the work a team did so far in terms of creating a solution. Storyboards that your team created in the previous stage can be easily converted into a prototype.

Creating a prototype in just one day can sound unrealistic because normally the process of prototyping would take weeks. However, an important thing to remember when prototyping is that you’re not building a fully-functioning product — you’re creating something that allows you to get the feedback from your users. This means you don’t need to code anything, all you need to do is to build a realistic facade — something you can put in front of your users/stakeholders to get their reactions. Think about the absolute minimum that will give your users an accurate representation of the idea so they can provide feedback.

Thursday ends with a trial run, when the prototype gets stitched together to make sure it all makes sense. Test it with team members.

Tips

  • The prototype must appear real. The test participant shouldn’t need to use their imagination to understand the solution. The more real a prototype feels, the more natural a reaction you’ll get during usability testing.
  • Pick the right prototyping tool. The right prototyping tool is the one that your team is most experienced with. Start with the tools you normally use for creating things.
  • Make sure all team members participate in the process of prototyping. The GV team calls this “Divide and Conquer.” There shouldn’t be a situation when only one person on your team is responsible for building an entire prototype. Figure out which tasks fit each person’s skills and give everyone their own place to work.

Validate (Friday)

The validation stage answers the most critical question in product design — “How do I know if my work is any good?” During this phase, you test your prototype with real live users. You show a user the prototype you’ve built and watch their reactions.

Show your prototype to users in a series of one-on-one interviews.

During the interview sessions, you should look for patterns. Eventually, you’ll find parts that work successfully for all test participants and parts that didn’t work as well as expected (places where users were confused or weren’t interested).

At the end of the validation phase you should feel confident in what you validated and, if validation was successful, move to the Agile Sprints. This is basically a technology version of the Design Sprint where you bring engineering to the table and try to build a real product.

Tips

  • Don’t miss the opportunity to test your prototype with users. Some teams postpone the process of testing. Don’t be one of them! Validation is a mandatory part of a Design Sprint.
  • Use triple validation. Validate your prototype not only with users but also with stakeholders and engineering.
  • Test with five users. You don’t need too many test participants for a validation session. According to Jakob Nielsen, 85 percent of problems can be observed after testing with just five people. After five interview sessions, it should be clear what to do next.
  • Show, don’t tell. Avoid explaining how to interact with a prototype. A properly-designed prototype should stand on its own. You don’t have to explain too much, just describe the basic task for the user.
  • Avoid biasing your test participants. A good interviewer guides a test participant through an idea without biases. The questions are structured in a way that gets people reacting, instead giving feedback.

7 practical recommendations for Design Sprints

1. Document your progress

Try to write a daily summary after each day. This will help you look back at what was done and get better at designing Sprints in the future.

2. Find a good space

Space is really important for Sprints. A Design Sprint requires a sizable, dedicated space for the entire week with whiteboards to cover in maps, sticky notes, sketches, storyboards, etc. Generally, conference rooms aren’t good places for creativity. Choose a bigger space for your activities.

3. Avoid using devices in the room

You won’t have much time during the sprint, so it shouldn’t be wasted on reading news or checking emails. Use devices during breaks or step outside the room to use them, if necessary.

4. Avoid running Sprints virtually

Having people outside the room to participate in a Sprint is really challenging. There is so much happening in the space that it’s not enough to just participate in a chat, even using a video camera. You likely won’t have the same team spirit as if you have everyone physically come together in one place.

5. Honor the facilitator’s direction

The facilitator should be the most seasoned person in a Design Sprint; they should have been through multiple Design Sprints in the past and understand the direction. Make sure that the facilitator is being listened to and their directions followed. Without that, team members can easily end up in different directions.

6. Don’t break the five-day Sprint

When you run your sprint, make sure it’s five consecutive days. It doesn’t matter whether it’s Monday-Friday or Wednesday-Sunday, as long as the days are consecutive. You can’t break it at any point, come back to it, and expect to have the same momentum.

7. Adapt Design Sprints for large projects

If you work on a project, like a SaaS platform, don’t try to solve the whole thing in just one Sprint — you won’t be able to create an entire solution all at once. Instead, prioritize your challenges and pick a specific target you want to accomplish. Have a big goal in mind (like building a high-quality SaaS platform), but focus on a particular challenge you want to solve during the five days.

Design Sprint resources

Ready to start your own Design Sprint? Here are some resources to help you get started.

Conclusion

You just saw how you can move from idea to learning in just five days, and remember the idea of learning is at the core of Design Sprint methodology. If you succeed, at the end of the sprint you will have a design artifact that you can take to developers to turn into a real product.

But even if you’ve failed (e.g. users/stakeholders didn’t react well to the prototype) it’s also a good result. Now you know that this was a bad idea, and you were able to figure this out in just a few days, not months or years.

For the latest trends and insights in UX/UI design, subscribe to our weekly experience design newsletter!

Comments / Replies (0)

Recommended Articles