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 the 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
which is called design sprint. Rather than going through the whole circle of
Ideate-Build-Launch-Learn, the team uses the Ideate-Learn parts only. These
sprints helped Google improve Gmail and Google Hangouts.
A Design Sprint is a shortcut of learning. Image by 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
that 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 the
original idea to the 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.
What are the advantages of Design Sprints?
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 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 terms 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.
Visual example of design process. Image by The sprint book.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 design 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 by The sprint book.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 you are 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.
Examples of notetaking in design. Imageby Google.When taking notes always start with the words “How might we…”
- Pick a target for the design 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 of the design sprint, 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 by 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 by Sprint storiesThe 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 by tandem seven.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. Remember that design sprints is all about the speed. Thus, 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 that
participates in the design sprint 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.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 the prototyping phase of design sprint (if someone in your team asks, “What happens next?” when reading the storyboard it’s a clear sign some frames are missing).
Whiteboard of an app design. Image by The sprint book.Your storyboard is an entire experience.
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 of design sprint, 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
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 web 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 during design sprint 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 of the design sprint, you test your
prototype with real live users. You show a user the prototype you’ve built and
watch their reactions.
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 of 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 Design 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.