Design sprint, phase 1
Exercises and tools to plan and execute day one of a design sprint.
Exercises and tools to plan and execute day one of a design sprint.
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.
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.
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.
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.
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!
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.
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!
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.
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. 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.
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.
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.
With the guidelines established and the background material covered for this sprint, the team can seek ways of inspiration to create a fantastic product.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
Yakima Valley Farm Workers Clinic
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.
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!
You need instructions for this?
3Clayton Christensen Institute, “Jobs to Be Done,” http://www.christenseninstitute.org/key-concepts/jobs-to-be-done/.
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).