Latest Articles

Design sprint, phase 1

Exercises and tools to plan and execute day one of a design sprint.

By Richard Banfield, C. Todd Lombardo and Trace Wax
March 7, 2016
Wilma Rudolph wins the women's 100 meters running during at the 1960 Summer Olympics in Rome. Wilma Rudolph wins the women's 100 meters running during at the 1960 Summer Olympics in Rome. (source: Wikimedia Commons)

Phase 1. Understand

The first day of a design sprint is primarily an opportunity to bring the working team to a mutual understanding of the problem to be solved. If the team members haven’t already met one another, then this is the time when everyone will get acquainted. Getting to know each other helps to develop empathy, which is a cornerstone of any design-thinking exercise. In this chapter, we’ll give you tools and exercises to help break the ice and inject a little fun into the process. These exercises will also help you get inspired. Whether you need to be inspired by facts or out-of-the-box ideas, we’ve included a collection of tools to get you there. Together you’ll answer the questions: “Who is the customer, who is the user, and what are their problems?” You’ll all share the relevant context so the answers to these questions can be understood clearly, but you won’t need to come up with solutions yet.

What Happens During the Understand Phase?

  • Get the Background: ~1.5 hours
  • Get Inspired: ~1.5 hours
  • Define the Problem: ~1 hour
  • Know the User: ~3 hours

As discussed in Chapter 4, a design sprint is a flexible framework, and you’ll need to adapt it to your particular situation. If the conversation requires it, exercises can be added, reordered, skipped, shortened, or extended. Your mileage may vary on the duration for each of the exercises; we’ve done journey maps in 15 minutes, and some have taken up to three hours. It all depends on the level of detail your project needs.

Learn faster. Dig deeper. See farther.

Join the O'Reilly online learning platform. Get a free trial today and find answers on the fly, or master something new and useful.

Learn more

Whatever you do, don’t forget to take frequent breaks and get a good lunch! (Yum.)

You might not finish these exercises by the end of the first day. In that case, do the retrospective at the end of the day, then continue the exercises on the second day. If that happens, be sensitive to the time constraints to finish up the background work so that you have enough time for the additional phases of the design sprint.

Get the Background

The goal for this part of the day is to understand all the relevant data and information on hand. The team should explore what they know and what they don’t know to gauge what knowledge gaps exist for the problem. You’ll cover existing research done before the design sprint and review analysis of competitive or similar product offerings.

Introductions

Give the design sprint team the opportunity to introduce themselves. Everyone should say their name and their role in the design sprint team and the project to follow. The facilitator can go first to set the stage and provide a good example, followed by the main product sponsor or stakeholder, followed by the rest of the team going around in a circle.

Depending on how familiar the team members are with each other you could include an icebreaker to get the team to open up and be comfortable working together. You’ll be spending an intense few days together— might as well get the edge off up front!

How

  1. Select your icebreaker from the list on the next page or another you know how to do already.
  2. Describe your icebreaker to the group.
  3. Blueprint it by going first to set the stage and give an example for everyone.
  4. Pick an order and go around the room and make sure that each person completes the icebreaker.
  • Difficulty: Easy
  • Size: The whole group
  • Materials: 5 x 7 index cards to fold
  • Don’t let someone talk for a long time. This is a time for simple introductions, not for people to drone on about their background and opinions.
  • Approximate time: 30 to 60 seconds per participant

A Few of Our Favorite Icebreakers

Word Ball: Bring a plush ball. Toss the ball to someone else in the room, and as you throw it, say a random word. Each person does the same thing in turn, until everyone’s had a chance to throw the ball.

What Neighborhood Do You Live In?: Great for people in cities who love to talk about their ’hoods. At the end of each person’s intro, each person says the neighborhood they live in. One of Trace’s favorites.

Draw Your Name and Draw ______: Give each participant an index card and ask them to fold them in half: on one side, they should write their names in a decorative font, and something tangential and/or related to the topic of the week. For example, at a recent sprint, C. Todd asked everyone present to draw how they’d make pancakes. The manager present drew a car and an International House of Pancakes sign (he liked their blueberry syrup).

Little-Known Fact: Ask participants to state their name, title, and/or function, then add a fact that no one in the room likely knows about them.

Hopes and Fears: We learned about this one from Karen Cross at Atlassian. She uses this to help bring out potential project issues, in addition to getting others to know one another:

“It’s basically a 20-minute brainstorm exercise at the very beginning of a sprint. Everyone sits, and has two colored Post-its (usually red and blue). Depending on the number of people involved, I usually limit them to maybe three hopes and two fears, two hopes, or maybe one hope. And then everyone writes them down, and they all put them face down in the middle of the table, and then they draw from them, and then have to read someone else’s and explain what they think it means. By doing that, it gets them to be empathetic [to one another].”

After the introductions, acknowledge the others involved with the project but not participating in the design sprint.

Introduce the Idea Parking Lot

After that, introduce the concept of the Idea Parking Lot. During the sessions, the team may generate ideas or have other “aha” moments that may not apply to the main topic, or they may propose solutions on the first day that shouldn’t be explored until the Diverge phase. An Idea Parking Lot is a place where such ideas and topics can be captured, so you can come back to them when you’re ready. Unlike a real parking lot (especially during the holidays), there’s always room in the Idea Parking Lot!

How

  1. Place a large piece of paper on the wall. A page from a Post-it easel pad is ideal.
  2. Label it “Idea Parking Lot” at the top. Draw a picture of a car. Drawing pictures of cars is fun.
  3. Throughout the sprint, when anyone has an idea you want to capture that doesn’t fit the sprint, write it on a small Post-it and stick it in the Idea Parking Lot.
  • Difficulty: Easy
  • Size: The whole group
  • Materials: Post-its (you can also use a Google Doc or Trello Board
  • Approximate time: 3–5 minutes

Review Agenda

There’s a lot to cover on the first day of the design sprint. Give the team a sense of what’s to come, so they know what to expect.

How

  1. Review the printed agenda, or bring it up on a large TV screen.
  2. In about a sentence each, describe the exercises you’ll be doing.
  • Difficulty: Easy
  • Size: The whole group
  • Materials: A printed agenda (or a large TV screen)
  • Don’t go into too much detail.
  • Approximate time: 5 minutes

Rules of the Design Sprint

It might seem strange to start a creative thinking process by establishing rules. This counterintuitive approach is often shunned by the uninitiated as being restrictive or dampening the creative process. This couldn’t be further from the truth.

The guidelines we recommend are intended to level the playing field for all participants. Human beings are complicated enough without the additional pressure of having to solve problems while stuck in a room full of peers or strangers for five days, some of whom speak more forcefully than others. Put them all in a small space together to understand a problem, generate solutions, and make prototypes, and it can get downright chaotic. The humans involved in the design sprint phases are more than just sources for ideas and hands to make things. They bring with them their own experiences, biases, emotions, preferences, and politics. Guidelines reduce the risk of those biases and focus the team on the customer’s problems. Our goal with these guidelines is to get the team to fall in love with solving the problem and not with one of their own subjective solutions.

By providing guidelines and rules for the team, you can empower the team. Again, constraints increase creativity, and these guidelines can help. You reduce the opportunity for mental fatigue and ensure that each person’s contributions will be given attention and value.

One of the most important elements of a design sprint is that these are established on day 1 or even before the design sprint begins. These are not guidelines to impose on everyone in an authoritarian fashion—rather, ask the entire team to co-create them. Our recommendation is to select a few from this list (or your own!) then place blank bullet points and ask the team to help you fill them in. If no one adds any to the list, add some yourself. By adding it on the fly, you’re more likely to get things moving.

Here’s a sampling of guidelines we use. What could you add to this list?

  • Everyone participates
  • Have one conversation at a time
  • Withhold judgment of others’ ideas
  • Get up and draw
  • Be comfortable
  • Be easy on people, tough on ideas
  • Be timely
  • Be present
  • The phone stack
  • One computer at a time
  • No jargon/TPS reports
  • No HiPPOS
  • No “Yes, but…”

Everyone participates. We mean everyone. Design sprints are not for the faint of heart, nor the introvert that struggles to speak up. Rather, design sprints are intended to encourage participation by all, regardless of roles with the company or project team. There will be mechanisms to allow the quiet voices in the room to be heard, and the facilitator’s role (see Chapter 4) is important in identifying who isn’t participating and draw them out.

Have one conversation at a time. Have you ever been in a meeting and seen lots of side conversations? We don’t want those in a design sprint because we believe that all comments are valuable and want everyone to hear them. This will prevent everyone from talking over one another and prevent she/he-who-speaks-loudestwins.

Withhold judgment of others’ ideas. This is increasingly important during the Diverge phase when participants are generating ideas. To bring forth an idea can be a courageous act, and if there is harsh judgment, it can begin to erode confidence and diminish the quality of ideas. There will be mechanisms for judging ideas and bringing the better ones forward; those are when judgment is necessary and even welcome. So hold judgment until that time arrives.

Be comfortable. We don’t want people to feel like they have to stand up or sit down all day, so if someone is sitting and feels the need to stand, or, if they need to leave to go to the restroom, that’s OK. It seems almost too obvious to call out, but it does make a difference and establishes the tone of the sprint. Take frequent breaks so everyone stays refreshed and brings their A-game.

Be easy on people, tough on ideas. Along the same lines as withholding judgment, we want people to feel like they can contribute. There’s no better way to do that than to value what they contribute and go easy on them for doing so.

Be timely. Timeboxing helps force movement. Facilitators take note: this one is mostly on you. Your job is to make sure the time doesn’t go over what was stated and agreed on. If you said you’d have lunch at 12:30 p.m., make sure you’re breaking at 12:30 p.m. Otherwise, everyone will be looking at their watches thinking “Weren’t we supposed to break for lunch now?” and they will become disengaged. And hangry.

Be present. A design sprint is an intense exercise and many participants will get tired and distracted. Stay in the room, listen intently, and participate actively in the conversations.

The phone stack. Who loves their mobile phones? Most people. Who also doesn’t put them down in meetings? Most people. To keep the team focused and avoid the inevitable buzzing phone distraction, we ask everyone to pile their phones up on top of each other. This is known as the phone stack. The first person to reach for the phone might receive a small punishment, such as having to buy the next round of coffees or drinks.

One computer at a time. Sometimes you’ll need a computer projecting on a screen to review the agenda, instructions, or materials, but everyone else should keep their computers away. Only one computer should be in use at a time. Unless necessary, refrain from using your computer during the sprint. People will use the computers to multitask and will stop paying attention to the conversation. To take notes, write them down on paper instead. Everyone will be able to listen better when they’re looking at one another instead of their screens.

No jargon/TPS reports. Do you know what a TPS report is? Neither do we! Keep the jargon and acronyms to a minimum so everyone in the room understands. If necessary, start an acronym dictionary in the back of the room to keep track and let everyone know what “BTKO” really means.

No HiPPOs. The Highest Paid Person’s Opinion can often trample on other people’s ideas. Make this a rule so that a senior member doesn’t keep junior participants from defending their own points of view.

No “Yes, but…” Any time the word “but” is said, it often invalidates what was said earlier, so “yes, but…” is really a disagreement. Disagreeing is OK, but preceding that disagreement with a “yes” can be subtly counterproductive. There will be times for debate and disagreement in design sprints. Or instead of disagreeing, build on the last idea by saying “Yes, and…” or “Yes, because…”

If you ever see anyone breaking these guidelines during the sprint, call them out on it. If you violate these guidelines, call yourself out. If you are called out, admit it and move on.

After reviewing the rules you’ll be following over the next few days, it’s time to get started! Proceed with the following exercises to begin the design sprint itself.

Pitch Practice #1

The project sponsor should begin each day by walking the design sprint team through the business opportunity and market, and the problem you’re solving as they see it.

Pitch practice makes sure that everyone is aware of the original intent of the sprint, and allows the project sponsor to practice and refine the application’s elevator pitch over the week. The pitch can be modified as needed as new information, options, and decisions come to light.

How

  1. Have the project sponsor give her elevator pitch. Use a pitch deck if one is available. Cap it to a few minutes.
  2. Ensure that she covers the business opportunity, market, and the problem the team wants to solve.
  3. Allow quick questions at the end, but save most of the discussion for the rest of the day’s activities.
  • Difficulty: Easy
  • Size: The whole group
  • Materials: The project sponsor’s brain and her pitch deck if one is available
  • Don’t let the project sponsor drone on and on and on (there’s a 12-step program for that called On-and- On-Anon). Keep them timeboxed!
  • Approximate time: 5–10 minutes
  • Credit: Alex Baldwin at thoughtbot, Jared Spool for the On-and-On-Anon joke

Review Research and Past Work

Following the pitch, share a deeper dive into the background and motivation for the project. Reviewing the current body of knowledge together will help to get everyone on the same page, and allow people to build upon what has come before.

How

  1. Make it clear that what was done previously will inform the activities during the design sprint, but there will be an opportunity to take things in a different direction if it’s better.
  2. Have a brief discussion of the background information or research that was sent out before the sprint.
  3. Go over any other materials or things people know about the problem space but haven’t yet shared.
  4. Review any previous initiatives, including applications or prototypes the company has made to solve a similar problem.
  • Difficulty: Easy
  • Size: The whole group
  • Materials: Presentations of past project work (if applicable); screenshots or walkthrough of product (if existing); any relevant metrics, perhaps from a business intelligence report or marketing report
  • Don’t overload the team with information. Cognitive (over)load is a thing. Also don’t judge or get into debates. There will be plenty of opportunity to discuss different perspectives later in the day and throughout the design sprint.
  • Approximate time: Up to 1 hour
  • Credit: The team at thoughtbot

With the guidelines established and the background material covered for this sprint, the team can seek ways of inspiration to create a fantastic product.

Get Inspired

When considering new possibilities, you will want to know where you’re starting from so you can later diverge in order to generate a multitude of options. Going into a project, it’s important to understand what constitutes success. Everyone on the team arrived with their own notions of what success is. Like the North Star for ships sailing in the 1700s, understanding in detail what the goals are can help you as you search for inspiration and direction.

Goals and Anti-Goals

In this exercise, you’ll define the objectives of the project so all get on board and agree with it. This can also help define the project’s guardrails.

How

  1. Draw two columns on a whiteboard, one for the project’s goals, and one for its anti-goals. Anti-goals are things that are explicitly not goals of the project.
  2. Ask the team to brainstorm goals for the project. These should be high-level objectives, not features. For example, “Save $75 million per year in increased production efficiency” is a high-level objective, but “Allow users to propose savings ideas” is a feature.
  3. As each goal is suggested, allow the team to discuss it and agree that it’s a goal for the design sprint or following project. If it’s not, move it to the anti-goals column.
  4. Ask the team to similarly brainstorm the anti-goals that are not needed for the project’s success.
  5. Identify the top three goals. Underline the #1 goal.
  6. Capture and upload the list so the team can refer to it later.
  • Difficulty: Easy
  • Size: The whole group
  • Materials: Whiteboard and markers
  • Don’t list features, list too many goals. You’ll go nuts trying to meet them all.
  • Approximate time: 30 minutes
  • Credit: Graham Siener, Pivotal Labs

Existing Product, Competitors, and Substitutes

As you continue to look for inspiration, it can come from an analogous solution in another industry. A competitor. An elegant solution to a different product you’d like to emulate in some way. With digital products, many solutions exist, so rather than reinvent the wheel, seek out solutions from other industries that might apply to your problem. They don’t have to fit your problem exactly (remember, you’re only seeking inspiration at this point). We often take a section of a wall and print out apps, screenshots, drawings, or web pages of things we find inspiring, useful, or maybe even want to replicate (or all this can be viewed online and projected onto a screen).

There’s a risk of opening Pandora’s box here, in that sometimes a team can get too focused on replicating what already exists, instead of solving what a user or customer really needs. Don’t spend too much time on a deep dive of each of these; stick to a broad overview.

How

  1. Sync your monitor or phone to a large TV screen. Have someone bring up your existing site or app if one already exists, and walk through it to give the participants context. Discuss what’s working well and what’s not working well.
  2. Invite participants to identify competitive and substitute products. Bring them up on the screen, or put a printout up on the wall. Discuss the strengths and weaknesses of each. Also consider what “non-products” are used. For example, when a customer uses pencil and paper to track event participants.
  3. Do the same for aspects of apps or sites from other industries. For example, an onboarding flow or data visualization you might want to replicate.
  4. Take notes on the areas that are inspiring. If you’ve put screenshots up, have everyone stick Post-its or dot stickers next to the areas they like the most.
  • Difficulty: Easy
  • Size: The whole group
  • Materials: Printouts or displayed screens of anything that inspires the team
  • Context: This is a good generative exercise best completed at the start of the sprint.
  • Don’t go too deep or spend too long. Approximate time: 30–45 minutes
  • Credit: The team at thoughtbot

Facts and Assumptions

Another way to find inspiration is to acknowledge the biases we each bring to the table, so everyone’s aware of them and can overcome them when they need to. It’s human to make assumptions and form biases. Just get over it: we are biased. These biases can influence our decisions, which will affect our ability to solve the right problem. Before we can solve tough problems and open new pathways, we need to escape the confines of our existing biases, break out of our mental habits, and call out the assumptions that we may have. Einstein famously observed that “You can’t solve problems at the same level of thinking that created them.” Pushing our brains to identify all the assumptions we have about a problem will unlock ways for us to try and solve it; facts and assumptions help to reduce your bias by identifying them.

Let’s take a simple example: “I went to the supermarket yesterday and bought an apple because I was hungry.” How many assumptions do you think are in that statement? More than you think. First, there’s an assumption of causality: that being hungry causes the purchase of an apple. We don’t know about you, but we often look in our cupboard or refrigerator first before going to the store for an apple. Second, that the supermarket has apples in it. Yes, in the United States this is common, but depending on time of year and location, it is not always true, and hence an assumption.

These same subltle assumptions and biases can haunt you if not properly identified at the start of a project.

This exercise is used to identify what data is on hand, what is still unknown, and most importantly, what assumptions the team is making. This helps to minimize confirmation bias (it never is eliminated) and baseline everyone in the room to understand the context of the problem at hand. This also helps to identify what knowledge gaps exist.

How

  1. Allow participants 3–10 minutes to individually document facts and assumptions (one fact/assumption per Post-it). Use one color Post-it for facts and another color for assumptions.
  2. Invite each participant to share their assumptions as they post them to a wall or display board.
  3. Ask participants to rewrite any successfully challenged facts on the assumption colored Post-its.
  4. Document questions that arise during the group discussion process.
  5. Ask participants to approach the wall or board of facts and assumptions in pairs to work silently grouping the facts and assumptions by commonality.
  6. Partway through the process, replace the categorizers with two new participants, allowing them to undo or redo any work previously done; continue to replace categorizers every few minutes until all Post-its are categorized.
  7. Once half the Post-its are categorized, give the categorizers medium-sized Post-its to add category headings.
  • Difficulty: Hard
  • Size: Individuals, pairs, and the entire group
  • Materials: Sharpies, medium-sized Post-its, small Post-its in two colors
  • Context: This is a good generative exercise completed at the start of the sprint. It must be done before determining insights.
  • Don’t let questionable facts go unchallenged, as they may be assumptions (anyone can challenge a fact or an assumption). Let the group jump to insights without a full exploration of the facts and assumptions.
  • Example: “9% of current customers use feature X” is a fact; “current customers don’t understand how to use feature X” is an assumption.
  • Approximate time: 20–30 minutes
  • Credit: InnoLoft team at Constant Contact with inspiration from Craig Launcher of Assumption Storming

Question Formulation Technique (QFT)

In addition to our biases, we likely have questions—lots of questions: Will this work? Is my idea as awesome as I think it is? How are users currently solving this problem? What are the best ways for your organization to solve this? A question-storming approach can be quite helpful in understanding the problem you’re trying to solve. Phil McKinney, former Hewlett-Packard CTO, made himself into a question specialist for the corporate world, and argues that crafting good questions is what allows people to make innovative breakthroughs: “The challenge is that, as adults, we lose our curiosity over time. We get into ruts, we become experts in our fields or endeavors.” Dan Rothstein, founder of The Right Question Institute, studies the art and science of asking questions.

“Wielded with purpose and care, a question can become a sophisticated and potent tool to expand minds, inspire new ideas, and give us surprising power at moments when we might not believe we have any.”

Dan and his cofounder Luz Santana created the Question Formulation Technique, which was initially made for teachers to teach children the skill of asking questions. However, we have found that this also helps teams generate questions about the project and uncover some interesting opportunities.

This exercise is used to bring to the surface the questions each participant has about a particular topic. This can align teams so they all know what questions everyone has on a particular topic.

How

  1. Provide a question focus: the area that needs exploration.
  2. Inform participants about the QFT guidelines:
    1. Ask as many questions as possible.
    2. Do not stop to answer, judge, or to discuss the questions.
    3. Write down every question exactly as it is stated.
    4. Change any statement into a question.
  3. Establish a time limit.
  4. Post-up and sort per your preference.
  • Difficulty: Easy
  • Size: Individual and group
  • Materials: Sharpies and Post-it notes
  • Context: This is a divergent exercise, so it is best used in the beginning of a sprint. It could precede or follow Facts and Assumptions. A good follow-up exercise is to converge onto the important questions to answer by voting.
  • Don’t allow questions to be answered—it can be a rat-hole in the making. Don’t let this go un-timeboxed.
  • Approximate time: 5–15 minutes
  • Source: The QFT is © The Right Question Institute 2011. Used with permission: http://rightquestion.org.

By this point in the day, you know which direction to go—you’re feeling inspired and you’re ready to dig deeper into the problem. If someone comes to you with a problem, most people start thinking about a solution. Hopefully the questions you’ve generated are more about the problem and not leading to one solution or another, because as soon as you start thinking of a solution, you risk missing out on possibilities for a deeper understanding of the problem.

Define the Problem

What’s the problem you’re attempting to solve? This is one of the most important aspects and sadly, it is one that’s overlooked frequently by the many teams and clients we have worked with. Since most designers and engineers are trained to design and build things, the propensity to create and deliver often overpowers the desire to understand why they are creating something. You can look at the copious amount of digital products that were created and went nowhere. Let’s take a look at a few examples you might have heard of.

Airtime, the face-to-face video chat web application that was launched on June 5, 2012 with quite a splash. Shawn Fanning and Sean Parker (the famous Facebook investor), who created Napster, did a number of talk-show appearances and held a launch party that any record company would envy, well, except for the glitches.1 The result? $33M of funding with no users after 16 months of operation.2

What was the problem they were trying to solve for? Skype, Google Hangouts’ and Apple’s Facetime already had been in the market to solve these needs and Airtime offered little extra in the way of solving for another need. Had Airtime been more focused on the problem of video chat, it could have worked toward a better solution—instead they kept building and didn’t pay attention.

Facebook Home is (or was) a mobile digital product you might have tried on your Android device. We didn’t. Did it even make any sense? It seemed to solve a problem for Facebook, which was keeping their users in their app, but it did not solve any real problem or need for the user. We have seen many companies start design sprints to solve their own problems rather than solve a problem for their users and/or customers.

To understand the problem you’re solving for, you need to understand what information you have on hand about the current user behavior. Now that you’ve dug into the data and information you already have, and explored your facts, assumptions, and questions, you’ll consider the problems your users have faced. Are there tangential related problems? Are there seemingly unrelated problems? The objective is to paint as complete a picture as possible to understand the context of the situation.

Problem Statement

You can’t define a good solution until you understand the problem you’re solving. Defining that together gets the team on the same page and sets it as the North Star for the rest of the design sprint. This keeps ideas focused on the problem at hand, and other great ideas that solve a different problem can get added to the Idea Parking Lot.

How

  1. Distribute large 3 × 5 Post-its and ask participants to individually write down potential problems the target user might have (one problem per Post-it). The following questions can serve as prompts:
    1. What is the job-to-be-done?3
    2. What is the problem that this product or service will solve?
    3. What is the motivation behind what the user wants or needs?
  2. Place the Post-its on a whiteboard, grouping similar ones together, drawing lines between them as needed to indicate themes.
  3. Discuss the problem statement, and agree on the general problem to be solved.
  4. Refine the problem statement and finalize the wording.
  5. Rewrite the problem statement in a large format on a whiteboard or big Post-it and keep it visible throughout the sprint. This will be important to reflect and revisit if the conversation veers too far from the established problem.
  • Difficulty: Medium
  • Size: The whole group
  • Materials: Whiteboard, markers, and large Post-its
  • Don’t write a compound problem statement that solves all problems and tries to be all things to all people. Use conjunctions like “and” and “or” sparingly, if at all. In addition, don’t try to solve the problem yet. You’re just trying to understand it.
  • Approximate time: 20 minutes
  • Credit: The team at thoughtbot

Reframe the Problem with Challenge Maps

Now that we’ve defined the problem, how might we reframe the challenge given what we collectively know? Taking all the information in, you may realize that your initial hypothesis might be the wrong one. If so, that’s great! You’ll congratulate yourself as this process has worked for you. As we mentioned earlier, there are plenty of stories about products being built that no one needs nor wants.

Why reframe? Often we see organizations thinking and speaking in terms of their features and their products, not the customer or the user’s eyes (the paying customer and the user may not be the same person).

For example, have you ever purchased a pair of socks? Our guess is you probably have purchased many socks over your lifetime, and they are always sold in pairs.

In 2003, Jonah Staw, a product designer at the prestigious Frog Design was joking with Arielle Eckstut about how they could solve the problem of missing socks by wearing all the surviving socks that did not match. That silly joke inspired them to start LittleMissMatched. They reframed the problem from “I have missing socks” to “I can combine and wear these leftover socks” to ”None of my socks match, and that’s awesome!” They sold socks in “pairs” of three that have matching color palettes but no matching design patterns. Your suit-wearing Wall Street businesswoman might not wear them, but 11-year-old girls absolutely loved it. Eleven years later, the company is reportedly grossing over $30M annually in sales.4

The ability to reframe a situation can lead to incredible breakthroughs, and it can also lead to small insights that you can leverage to delight your users. It all depends on your perspective and the ability to shift perspective once you have all the context in front of your team. If you ask a team of engineers how to improve the experience of the Amtrak ride between Boston and New York City, they may offer all sorts of suggestions for improvements in the rail structures, suspensions on the train, and more comfortable seating. However, for the amount of funding it would take to implement that type of system and infrastructure, you might also be able to hire exceptional waitstaff as servers to serve top-shelf liquor and gourmet hors d’oeuvres to passengers during the trip. Rather than a shorter trip, passengers may start requesting a longer duration.5

This reframed the problem from a structural, smooth ride to creating an experience. The effort to improve that experience could be a much smaller implementation. These are the little details you’ll want to seek out as you reframe the problem you’re solving.

A technique that can help with this is to create challenge maps. A challenge map asks the questions “Why?” and “What’s stopping you?” and forces you to consider the relationship between the possibilities. Once you’ve created a challenge map around a particular issue, you can start to see what might be blocking the way to a solution. Many times you start out in one area and learn that’s not the area you need to focus on! With challenge maps, you can explore the problem you’ve identified and determine whether you need to restate it, reframe it, or solve a different problem altogether.

Challenge Maps

How

  1. Divide into pairs or small groups.
  2. Write the Problem Statement on a large Post-it note, and place it in the center of a whiteboard or a flipchart page. Add “How Might We” (or “HMW” for short) before the text of the Post-it.
  3. Challenge this initial statement by asking the group “Why should we do this?”
  4. Answer that “why” question on another Post-it note and place it above the initial Post-it note. Add “How Might We” to the beginning of it. Now challenge that new statement with the same “why should we do this?” question, adding Post-its going upward. Repeat this until a natural endpoint is reached (such as “to make more money”).
  5. You may find there are multiple reasons, so answering “why else?” will lead you to put Post-its to the left or right of each other.
  6. In the downward direction, challenge each “How might we…” statement with the question “What’s stopping us from doing this?” Answer that question, then rewrite it to a “How might we…” question, and place it below that Post-it.
  7. You may also find multiple reasons for what’s stopping you. Place Post-it notes to the left or right answering “what else is stopping us?”
  8. Continue until a natural endpoint is reached.
  9. With the entire group, review the Post-its that were created and see if any of the added statements would make a more applicable Problem Statement. If so, use that Post-it note to revise the Problem Statement accordingly.
  • Difficulty: Difficult—really, this is quite difficult
  • Size: Best in pairs
  • Materials: Flipcharts; large and small Post-its
  • Don’t do this in groups of more than four people.
  • Context: Good to start before or at the beginning of the sprint to explore the problem space before attempting to solve.
  • Approximate time: 15–20 minutes to start (can take longer depending on the size and nature of the project)
  • Credit: Min Basadur

Know the User

In order to be successful, it is important to understand all the stakeholders surrounding a project, product, or service.

Regardless of what anyone else says, people are the ones to buy and use your product, so keep them at the center of your work. Personas are a good way to explore who those people are.

Personas are composite constructs of people, representations of the different types of people who use your product. They may be imaginary but they are not fictional, as they are based on knowledge of your customer base and/or user base. Personas are less about demographic data, and more about context, attitude, and behavior. If you already have personas from past work, that’s excellent. You can bring the group up to speed and double-check that your assumptions are correct. If you don’t have personas yet, that’s OK; this is a great time to investigate the who you’re solving for.

That said, it’s important to define the difference between a user, a customer, and a persona. It’s probably obvious, but to be clear, the user is a person who uses your product or service. A user might not be the person paying for or administering the product. A user may or may not be your customer. For example, a customer of Google’s AdWords may be the one setting up the ad (and paying for it), while another user may be a marketing director viewing the reports. Customers pay you money. Users use your product. They may be one and the same, but that’s not always the case. Further, when you have multisided markets, as is common in marketplace apps like Airbnb or Lyft, you have multiple user types (i.e., multiple whos!).

The Who/Do exercise (from our friends who wrote Gamestorming) is a great way to begin to explore the stakeholder ecosystem. It answers two simple questions: who are the different stakeholders and what do you want to them to do with your product?

Once you know who the stakeholders are, you can flesh out more of the information about them. You won’t have to consider all the stakeholders from the Who/Do exercise—one (or two) will suffice.

Who/Do

How

  1. Draw a two-column table with “Who” on the left and “Do” on the right.
  2. Ask the group: Who are the stakeholders? Who might be an obstacle? Whose support is critical to this project’s success? Generate an exhaustive list of whos, writing each on the whiteboard or on a Post-it.
  3. The Do column is typically more challenging. For each who, ask: What do they need to do, or do differently? What do they need to do for this project to be successful?
  4. If necessary, you can add columns—for example, “Gives” and “Gets.”
  5. You can then rank and prioritize. If the choice isn’t obvious, you can have each participant indicate the most important whos/dos by sticking dots on them.
  • Difficulty: Easy
  • Size: Teams or pairs
  • Materials: Sharpies; large and small Post-its in a variety of colors; wall or display board (horizontally oriented); dot stickers (optional)
  • Context: Good when first examining stakeholders of a project/product. Empathy maps, personas, and user stories or job stories are natural follow-ons.
  • Don’t always drive toward action, as there is a tendency to say, “we just want them to understand.” Ask the group, “What will happen when they understand?”
  • Approximate time: 10–30 minutes
  • Credit: Dave Grey at XPLANE

Personas

Now that you know who your most important stakeholders are, you can go deeper into their personas. This will humanize your users and give the product team a sense of empathy for the people they’re designing and developing for.

How

  1. Do a quick recap of all the user information you have, both qualitative and quantitative (Discovery Interviews, site analytics, market research, etc.).
  2. Categorize your personas with some or all the following information:
    1. Persona category (i.e., information seeker)
    2. Name (fictional names are often used, but sometimes using the first name of a real customer/user can help humanize further)
    3. Job titles and major responsibilities
    4. Backstory (demographics such as age, education, ethnicity, and family status; also include their physical, social, and technological environment)
    5. Motivations (the goals and tasks they are trying to complete using the site)
    6. Quote (this sums up what matters most to the persona as it relates to your product; preferably a real quote obtained during a Discovery Interview)
    7. Images (photographs and images representing this user group)
  • Difficulty: Moderate
  • Size: Entire group (if more than five people are in the room, split into teams)
  • Materials: Sharpies; flipcharts; wall or display board (horizontally oriented)
  • Context: If you do not have preexisting personas, a great place to start is a Who/Do exercise and then base personas from the selected whos. Combine that with any data from your market research, and other primary Discovery Interviews to create a composite.
  • Don’t talk about a product or solution yet. Talk in abstractions. In addition, don’t add aspects to a persona that aren’t based on real-world research—just consider their world and what they’re trying to get done.
  • Approximate time: 30–60 minutes, depending on depth of data you have
  • Credit: Alan Cooper is considered the pioneer of personas

Discovery Interview

This is the first part of the design sprint where the team will get to talk to users and/or customers…you know: people! Research you may already have on hand will tell you the what and when of a user’s actions, but the why remains elusive and the best way is to converse directly with an actual user to discover this information, and any other relevant information that may help drive the design of a product or service.

As an example, when Dana Mitroff-Silvers began a design sprint for the Denver Museum of Nature and Science, she started by running all the participants through an introductory “wallet project” design-thinking exercise from Stanford’s d.school:6

“It’s essentially the wallet exercise from the Stanford d. school, but I change it out every time with a different design challenge based on where I’m going and who the group is. We’ve designed a morning commute. We designed the ideal neighborhood. We designed a Sunday night experience. It all depends on who I’m working with.”

By completing this exercise up front, she was able to navigate the remainder of the sprint and refer back to it to reinforce its concepts as necessary during the rest of the sprint, ultimately bringing a sense of empathy to the team. After the introductory exercise, she sent everyone out into the museum to observe and interact with museum goers:

“We get ready to go out and do the real interviews; we talk about what the design challenge is, and then we talk about questions you might ask. Sometimes I let people draft their own questions; sometimes I give them starter questions. It depends on how much time and the group’s comfort level and then I send them off to do interviews. Sometimes we do some observation of museum visitors out in the gallery: “What are they doing? What are they using? What kind of figures are you seeing?”

Larissa Chavarria at The Advisory Board does something similar: although she doesn’t have the luxury that the museum has with a location full of users to access, she has her teams get on the phone with users. Because of the nature of their product, sometimes users are internal employees and there’s easier access, but for many teams, scheduling interviews on short notice is a challenge.

“After each interview, the team gets together and does a team debrief. After every interview, we have sticky notes, and it’s two minutes to write down, ‘what do you think the user really wanted or what was surprising?’ Having the sticky notes helps people who are maybe more introverted or some people who are stronger at the table can sort of overpower a meeting. The sticky note process is great because everyone silently brainstorms. You put them up on the wall and you say, ‘OK, this is a recurring theme. You group those together. This is an outlier, we didn’t think about it.’ Then you vote, ‘do you think this is important? Or is this a totally random thought?’ It’s a good process to make everyone equal.”

Once they have completed the interviews, her team creates a matrix to determine which observations are important to drive the next phase.

Conducting a Discovery Interview is a great way to delve deeper into the context of the problem. We encourage video and audio recordings of these whenever possible so that the entire team can hear the customers’ own words.

How

  1. Create a brief description (up to two sentences) of a goal of what you seek to learn.
  2. Select some icebreaker questions—something that will build rapport with the interviewee. Remember: They are a human, too!
  3. Make a topic map rather than specific questions.
  4. Have one person ask the questions where possible. Let the user focus on them. Downplay the other people present.
  5. After an introduction, briefly describe the reason for the interview, and work through the topic map.
  6. Thank them and ask for their email address (to follow up with a thank-you note!)
  • Difficulty: Difficult
  • Size: Best in pairs, but if users are in limited supply, the whole team can listen in
  • Materials: A/V recorder; notepad and pen; camera; topic map; users to talk to
  • Context: Best on the first day of the design sprint after everyone’s received a data-dump and has completed the earlier exercises.
  • Don’t talk more than you listen, or ask leading questions.
  • Approximate time: 15–30 minutes per interview; 60 minutes total (or longer if the schedule allows)

User Journey Map

Now that you’ve gotten to know the user, you’ll want to look from a holistic viewpoint at what the users are doing before, during, and after the time they use your product. This will add context to your project and highlight opportunities you may have otherwise missed. We often see teams focusing only on areas where the customer is engaged in using the product, and they miss out on many opportunities to create delightful experiences based on that behavior or entry point.

Using an experience map or a user journey map is an excellent way to visualize the journey. In a user journey map, you break down the journey of each persona into different stages. Once you have all of those stages (and goals for each stage), you can see the touchpoints where the user would interact with your product or service. “Touchpoints” are the interactions of personas with the product or service. Keep in mind that the different personas you created earlier may have different needs, attitudes, and behaviors—however, their journeys may remain the same. They might not, hence the need for this journey map.

Let’s consider a search engine optimization (SEO) example. Before a user is thinking about SEO, she is writing content for her blog, creating marketing collateral, or perhaps responding to a review on Yelp. Maybe she’s taking a call from a customer or writing an email in response to a support ticket. All these activities can yield insight into how you might engage users who are undertaking SEO activities. Understanding the user’s situation is key to defining the context and the opportunities your team has to create a solution that not only meets, but also delights.

A journey map documents the stakeholder experience from beginning to end, inside and outside of the product to identify opportunities for ideation. Further, the team will keep the waystations on the user’s journey map in mind as they sketch their ideas during the Diverge phase of the design sprint.

How

  1. Divide group into smaller teams according to the number of key stakeholders or personas you are completing journey maps for.
  2. Each team defines the stages of the current stakeholder experience from beginning to end on large Post-its in a horizontal line at the top of the wall or display board.
  3. For each stage, define the goal(s) the stakeholder has for that stage; write these on small Post-its, one goal per Post-it, and place directly beneath the corresponding stage.
  4. Continue this process for tasks and tools.
  5. Next, map the stakeholder mental state by either drawing a moving line(s) across all the stages (high = happy, low = unhappy) or by noting significant points of mental state with happy or sad faces, or the corresponding emotion label (e.g., relieved).
  6. Based on low points on the mental state, list needs, then opportunities, on small Post-its, one need/opportunity per Post-it, and post below the corresponding stage.
  7. If necessary, perform a vote (using dot stickers) to determine primary opportunities to move forward with.
  • Difficulty: Moderate
  • Size: Teams
  • Materials: Sharpies, large and small Post-its in a variety of colors, wall or display board (horizontally oriented), dot stickers (optional)
  • Context: Good to do after background activities and before ideation activities. It’s not necessary to complete every level of analysis for all journey maps. Choose the analysis points that meet the needs of each design sprint. It’s best that journey maps focus on existing workflows, but they can be modified to map out proposed goals and needs to define what should be built.
  • Don’t just focus on the product workflow; you’ll want to include product elements that are part of the user’s current path that does not involve interaction with the product. Don’t leave out the user’s mental state, as this is a significant eye-opener.
  • Approximate time: 60–90 minutes
  • Credit: Various sources

Patient Experience Map

Yakima Valley Farm Workers Clinic

Daily Retrospective (Plus/Delta)

What have we learned? We’ve taken the data we have and considered those constraints. We’ve spent all the energy and effort up to this point understanding and identifying the problem. This is a good time to take a
step back to reflect on your work and appreciate what was accomplished, and allow everyone to propose improvements and share concerns, and plan action items.

The end of the day is an ideal time to do a retrospective, even if that falls in the middle of one of the design sprint phases. It’s a great way for the team to come together before everyone leaves for the night, giving
closure to the day by reflecting on it and planning for tomorrow.

There are many common retrospective formats. We recommend a Plus/Delta approach.

How

  1. Draw two columns on a whiteboard: one for a “+” (plus: what went well) and one for “Δ” (delta: the Greek symbol for change).
  2. Ask the group to reflect on what was positive and capture those thoughts under the “+” column.
  3. Ask the group then to candidly brainstorm what they would change about the day, and put these under the “Δ” column.
  4. For each item in the “Δ” column, list any action items that can be taken. For example, “revisit the challenge statement to include Larissa’s feedback about older users.” Address these action items in the next day’s activities, or note them for future sprints.
  • Difficulty: Easy
  • Size: Everyone
  • Materials: Whiteboard or Post-its
  • Context: Done at the end of every phase, except the Prototype phase, which requires a longer, more indepth retrospective of the entire design sprint.
  • Don’t ignore or skip over this exercise; daily reflection will help you continually monitor your progress. Don’t think that every delta is an immediate action item, or allow deltas to become just “what I didn’t like.”
  • Approximate time: 10–15 minutes at the end of each day, 30 minutes at the end of the design sprint
  • Credit: Plus/Deltas are found in the book Gamestorming. The earliest known use of the Plus/Delta game is at The Boeing Co circa 1980.

Team Drinks: Less Filling and Tastes Great!

As the first day concludes, take the opportunity to go out with the team if you can. Getting out of the conference room will give you a fresh perspective, and the conversations you have will forge connections with your colleagues that will last the duration of your project and beyond. You will likely be tired toward the end of the remaining days of your sprint, so take advantage of this.

Drinks are a low-pressure way to get together without a big time commitment. The people who are local will then be able to get home to their families at a reasonable hour. Make sure you leave early enough; we prefer to leave for drinks no later than 4:30 p.m. (or 5 p.m. at the latest). If people want to spend more time after, anyone who chooses to can go out to dinner.

If there isn’t a good place to go nearby, raid the beer and soda fridge and have a chat in your company’s lounge or café. It’s almost as good, and you can’t beat the price!

Pace yourself; the second day of a design sprint is coming up soon and will be an intense one. Equally attractive nonalcoholic beverages (EANABs) are also always an option!

How

You need instructions for this?

  1. Go forth and get drinks!
  2. Enjoy.

1Erin Griffith, “Big Celebs, Big Ideas: The Double-Edged Sword of a Big Flashy Launch,” June 5, 2012. http://bit.ly/celeb-ideas.

2Milo Yiannopoulos, “There Is Literally No One Left on Sean Parker’s Airtime,” October 28th, 2013, http://bit.ly/yiannopoulos.

3Clayton Christensen Institute, “Jobs to Be Done,” http://www.christenseninstitute.org/key-concepts/jobs-to-be-done/.

4http://bit.ly/mismatched-socks

5From Rory Sutherland’s TED talk (http://bit.ly/brand-over-brain)

6The Wallet Exercise is 90-minute project through a full design cycle. Participants gain an experiential introduction to the phases of the design approach and some shared vocabulary. (http://bit.ly/wallet-proj).

Post topics: Design
Share: