Skip to main content

Understand

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 sprint.

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 this process.

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.

Introduce an Assumptions Board *(9:40am:

5min)*

Give a brief overview of the assumptions board and why we want to track those assumptions.

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.

Introduce a Back-burner Board *(9:50am:

5min)*

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?

Define Problem Statement or [Jobs

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)

Create a Critical Path (1: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:

Needs / Wants / Desires

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.

Five Whys

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.

Who / What / Where / When

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.

Open Card Sorting

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 similar ideas.

Talk to one of our product experts about building success into your process.

This site uses cookies. Learn more by visiting our privacy policy.