Phase one of the design sprint is dedicated to learning about the situations the
customers are in, the pain points that they have with current solutions, what
their outcomes and motivations are. As a team, we'll expose our assumptions and
knowledge gaps. From there, we can make plans to fill knowledge gaps and
validate or invalidate our riskiest assumptions.
Throughout Understand, the team should be working on defining the business, who
is going to be using the product, how this product is solving a problem that
those users have.
- What are the situations that users will be using the product or feature?
- What are their motivations behind using it?
- What are any outside motivators that might affect their use?
The whole team should define what success looks like for the product and the
At the end of Understand, the team should have captured a problem statement or
jobs statement, drawn-out a critical path, and established a base level
understanding of what the team will be solving.
A Guide for Understand:
As you work through the understand phase of a sprint there will be a lot of
questions that come up from the information that is uncovered.
Ask obvious questions and embrace the beginners mind.
Shoshin(初心) is a concept in Zen Buddhism meaning beginner's mind. It refers
to having an attitude of openness, eagerness, and lack of preconceptions when
studying a subject, even when studying at an advanced level, just as a
beginner in that subject would.
Example Schedule for Understand
Team intros (15min)
Introduce the design sprint team and their roles both in the sprint and outside
of it. Define what the roles mean in the sprint. Acknowledge the others involved
with the project but not participating in the design sprint.
Intro to the Design Sprint Process (5min)
High Level overview and goals of each phase of the sprint. Set expectations
about how we might feel at certain steps in the process.
A design sprint is a five phase process to quickly and collaboratively using
design thinking to solve problems and validate those solutions.
Understand phase is for the team to build common knowledge around the situation
and motivations of people that might use the software. After understand you'll
feel a little overwhelmed.
Diverge phase is a chance for us to explore many solutions to get people to help
people make progress. Because we've come up with so many solutions as a team,
after diverge people typically feel a little lost and directionless.
During the Converge phase we narrow the solutions to the one or two we feel
solve the problem the best.
Prototype phase will be mostly heads down on the prototype of choice. We'll all
feel rushed, like we're cramming for a final exam.
During the testing phase, we'll invite a handful of people to interview and test
out the prototype. How we feel at the end depends on the results of the test.
Remember though that the only failure is this team not learning anything through
Intro to Day 1: Understand (9:30am: 5min)
Give a more detailed overview of the phase and set expectations for the phase.
As I mentioned before, Understand Phase is about developing a common
understanding of the context within which we are working and all the elements in
that context (the problem, the business, the customer, the value
prop/hypothesis, success, etc). Our goal is to expose risky knowledge gaps and
identify risky assumptions so that we can make plans for reducing those risks
and move forward confident we are heading in the right direction. By gathering
info we will empower our decision making abilities and eliminate the need for
guesswork later on.
Give a brief overview of the assumptions board and why we want to track those
Throughout the day and rest of the week we will ask questions we don’t have
answers to and identify assumptions that we are relying on. We will capture
these Assumptions on a sticky note and put them together on a board for later
organization and analysis.
Give a brief overview of the back-burner board and how we use it to stay focused
on one problem.
We will also be generating a lot of ideas throughout the week. Some of the ideas
will be pertinent to the tasks at hand, but others, although interesting, won’t
be. We will capture these good but not immediately relevant ‘back-burner ideas’
on a sticky note board.
Review existing research and competition (10:00am: 1hr)
Start to establish a base level understanding of the business. Review existing
research, prototypes, and documents. The
Review the competition. How are existing solutions already solving this problem?
How are they talking to customers? What are they doing that is working well for
current customers? What are some pain points with their solution and how might
we make something better?
Statement]() (11:00am: 1hr)
Identifying the problem or Job-to-be-Done will help to align the team to the
pain-points and outcomes that the team should be solving for. Its serves as a
north star for the rest of the sprint and potentially product.
LUNCH (11:00am: 1hr)
As a group, use your common understanding to collaboratively map out the user
story that’s important in this sprint. The facilitator (or another volunteer)
should stand at the whiteboard and sketch the flow. This doesn’t have to be
fancy to be useful.
Ask the Experts and How might we (2:00pm: 1.5 hours)
Interview experts on your sprint team and guests from the outside. Aim for
fifteen to thirty minutes each. Ask about the vision, customer research, how
things work, and previous efforts. Pretend you're a reporter. Update long-term
goal, questions, and map as you go.
While the guests are speaking create how might we sticky notes. Reframe problems
as opportunities. Start with the letters "HMW" on the top left corner. Write one
idea per sticky note. Make a stack as you go.
Organize How might we (3:30pm: 30min)
Stick all the How Might We notes onto a wall in any order. Move similar ideas
next to one another. Label themes as they emerge. Don't perfect it. Stop after
about ten minutes.
Each person has two votes, can vote on his or her own notes, or even the same
note twice. Move winners onto your map.
Daily Recap (4:00pm: 15min)
Consolidate notes and write daily summary.
Other activities for Understand:
Start with a feature wish list and condense into columns of priority for
"Needs"(aka Must Haves, Top Priority), "Wants"(Nice to Haves), "Desires"Would
love to have someday...). This activity is great for ironing out which features
are most important and which could potentially be put on the back burner list.
This activity is meant to dig down deep into what the actual reasons are for a
problem or what the problem actually is. It is good to use when the apparent
problem seems to only be a symptom of a larger problem. It is based off of a
game found in Gamestorming.
This activity is meant to get consensus on what the problem that is trying to be
solved when the opinions are widely different. It gives everyone a chance to
voice they opinions on what. It is based off of a game found in Gamestorming.
Card sorting helps categorize and prioritize features, ideas and different
concepts so that it is easier to understand the problem. It is useful for
working through user flow, moving features to the back burner board and merging