InVision Presents

Enterprise Design Sprints

by Richard Banfield

A Design Sprint provides a simple, timeboxed problem-solving framework for product teams to get answers quickly and effectively. The exercises embedded in the five phases are designed to reduce politics, increase collaboration across functions and put the focus on answers (outcomes) and not just assets (outputs). 

Go to Chapter
What Design Sprints Do for Enterprises

A design sprint is a flexible, timeboxed problem-solving framework that increases the chances of making something people want. The goal of a design sprint is to validate or invalidate ideas so teams can have more confidence in their choices and priorities. There are five phases to every design sprint: Understand; Diverge; Converge; Build and Test.

Go to Chapter
Go to Chapter
When To Sprint

Design sprints are for when you need answers to big questions. Design sprints first gained traction in the digital products space, but they are a flexible framework and can be tailored to fit almost any problem-solving effort.

Go to Chapter
Go to Chapter
Getting Senior Buy-in And Support

Having the right people or opinions at a design sprint will determine its impact and success. It’s important to provide compelling reasons for senior executives and influencers to participate and to understand how design sprints add to existing processes, like Lean and Agile.

Go to Chapter
Go to Chapter
Planning Your Design Sprint

Adequate preparation will make the design sprint more impactful. Understanding who to invite, who to get input from, where to host it and what to bring will set you up for success. Plus, helpful tips on how to run a successful design sprint when your team is partially or completely remote.

Go to Chapter
Go to Chapter
The Design Sprint

Practical and real-world tested exercises will give you the best chance of delivering on the promise of a design sprint. This chapter provides a step-by-step guide for teams of all sizes.

Go to Chapter
Go to Chapter
Beyond the Five-Phases

The design sprint isn’t really over at the end of the fifth phase. Collecting insights, compiling notes and capturing experimental data is critical to knowing what to do next. Thoughtful preparation and communication will ensure your hard work finds the traction it needs to either move you forward or help you make tough decisions.

Go to Chapter
Go to Chapter

Downloads, recommendations and workshops. We’ve collected the most helpful resources for you and your team to succeed with your enterprise design sprint.

Go to Chapter

The Design Sprint


by Richard Banfield

With a few minor exceptions, there are five phases to every design sprint. As mentioned in chapters 1 and 2, completing all five phases in five days is the best approach to delivering design-sprint value. In this chapter, I’ll explain the logic behind each phase and why the exercises work best in this order:

  1. Understand
  2. Diverge
  3. Converge
  4. Build
  5. Test

Phase One: Understand


The first day of the design sprint is about reducing the noise of assumptions and establishing a clear signal for why we should be addressing this particular problem. The team will review the background research, identify gaps in knowledge and expose the riskiest assumptions.

Introductions, agenda review, and roles (20 mins)

My recommendation is for the facilitator to introduce team members to one another well before the sprint starts. A video conference works well for this, allowing everyone involved to see who will be there and start getting comfortable together. For larger organizations with distributed teams, it’s likely people will be meeting each other face-to-face for the first time on day one. So plan for a little extra time for socialization and a round of quick introductions. Use name tags if necessary.

It’s also a good idea to get everyone to share their concerns from the start. Use the Hopes vs. Fears exercise to provide an opportunity to get personal expectations out in the open. Once this is done, the facilitator should assign roles and walk everyone through the agenda.

List assumptions and facts (30 mins)

The first exercise of the day is to list the assumptions on a whiteboard, or equivalent space that everyone can see. The facilitator asks questions like: What do we assume about the customer? What about the current buying experience do we assume is working for the user? Are we sure that the customer can articulate our product’s value? Have we asked customers what they want?

The facilitator uses these questions as prompts for conversation between team members, ensuring that everyone has a chance to provide suggestions or questions of their own.

The assumption board will be referenced and updated throughout the design sprint, so place it somewhere visible. Next to each assumption write down how the assumption can be tested, and what a validated or invalidated test result would be. Although this process is done primarily during the Understand phase, continue adding assumptions and associated tests as the team discovers them over the course of the sprint.

Assumption Test with… Validated if…
Customers want a shorter checkout process Prototype and interview TBD
Customers understand the value of this feature Interview TBD

Enterprises can harbor institutional-level assumptions that are based on years of habits and even successes. But these assumptions can be extremely dangerous in today’s rapidly changing business environments, especially if they’re incorrect or founded on outdated information.

Review background research and findings (1-2 hours)

It’s important to collect, organize and distribute background research several days before a design sprint starts. But it’s difficult to ensure the team will review it before arriving. So it’s best to go through the research on day one. For complex problems, reviewing the research will take up a good part of the day. But it must be done. Without background knowledge, the team will be poorly equipped to work on the exercises that follow.

The aim of the research review is to make sure the team has a firm grasp on the business challenges, the customer’s current expectations and the value proposition offered by the business or product. This understanding will make comparisons to competitive options more fact-based and less likely to be influenced by opinion or presumption. (If there is no product yet, and this design sprint is being used to discover a new product opportunity, you might not have a clear value proposition yet.)

Needs, Wants, and Desires or Real Pain Points (1 hour)

Identifying the needs of your customer is probably the most important exercise of the day. Sorting between what the user needs, versus what they want, will help the team better understand the problem. For example, users may need to get from location A to location B but, how they choose to do that might be different from one another. One user may want to ride a bicycle, while another wants to drive a luxury car. The need is fulfilled in both instances but in very different ways.

User’s Journey or Critical Path (45 mins)

Plotting the user’s journey allows everyone to see where the contact points are between customer and product. The facilitator asks the participants to map the steps a customer takes while interacting with a product. Each participant contributes by adding, editing or clarifying activities like “customer searches for lighting solution on shopping site” or “company sends a notification to the user’s smartphone/app.” By the end of the exercise, the finished product will look much like a children’s treasure map. Loosely mapped touchpoints with brief descriptions of what happens at each point is enough fidelity. High fidelity illustrations won’t add any additional value to this exercise. So just keep it simple.

I find this to be one of the most interesting exercises in the design sprint. How a company visually describes the customer journey explains a lot about the team’s understanding of the customer’s needs. The more the team is aligned around how the customer navigates the journey, the more understanding they have of the problem. As a facilitator, if you notice a lot of disagreement about the journey touchpoints, it’s worth going back and discussing the assumptions driving those interactions.

Develop ‘Problem Statement’ (45 mins)

Once the background research has been done and the needs of the customer have been established, it’s important to figure out what the problem is that needs solving. Identifying the problem and writing it in statement format also doubles as a vision of the future. Think of the customer problem and the product vision being two sides of the same coin.

My advice is for each person on the team to write their own version of the problem statement using the format below, and then compare versions with the rest of the team. Having discussed the variations as a group, the facilitator can then write a final version on the whiteboard.

To create a problem statement, replace the words in parentheses with your own vision of a solution:

Clearly identifying the problem is important, so don’t be afraid to rewrite this statement a few times or add a longer explanation if it helps with understanding.

You’ll also notice the last two sentences of the statement project what the outcome of a solution might be. It’s unlikely you’ll have a clear solution in mind, so focus instead on the outcome you’re seeking to create. For example, if we were to use a rideshare transportation example, we might say: “We envision a world where owning a car may no longer be a liability. We’re bringing this world about through smartphone access to a new kind of shared transportation solutions.”

As important as it is to determine if there is a problem, it is just as important to understand if that problem is solvable and whether it needs to be solved. The problem statement is the first step to answering the question: What is this product, and is it useful?

Retrospective (15-20 mins)

Before phase 1 is completed, it’s important for the team to circle up and discuss the day’s work, and plan ahead for the next day. I like to ask the team questions and look for alignment on the answers. The questions are a summary of the day’s work: Who is the ultimate user of the product or feature? Under what conditions would a user engage with this product or feature? What pain point do they have that will be addressed by this product or feature? What triggers, internal motivations or external pressures are involved in them using the product or feature? What outcome does the user expect from the encounter with the product or feature?

It’s possible that the answers to these questions won’t be crystal clear to begin with, that’s okay. Discussing them and aligning the team around what needs to be done in the phases that follow is more important than concrete answers.

Phase Two: Diverge


The goal of this phase is to generate possibilities. This follows directly from the Understand phase, where our goal was to understand the terrain and identify the problem worth solving. For this phase to be effective I recommend having the same mindset that improv actors embrace: build on the previous person’s idea. Instead of judging ideas, we’ll find the best solutions when we have an open mind and encourage crazy ideas.

Mind Mapping (20 mins)

We start with mind mapping to warm up creativity and prepare the group for the exercises that follow. This is an individual exercise, so each person will do their own mind map. The facilitator reads out the previous day’s Problem Statement and then sets the timer for the group to write down ideas. Using a blank sheet of paper the participants write down ideas that might be solutions to the problem. Just like improv, by asking, “yes, and…”, each idea will generate another idea. Participants add each new idea to the previous idea with a connecting line. The result will look resemble an alien spider, with connected ideas radiating out from a starting point.

Crazy Eights (30-40 mins)

In a design sprint, we approach ideation in layers. The mind mapping gets the creative ideas out of the participants’ heads, and then the Crazy Eights and How Might We exercises allow us to go deeper. The time limit allows participants to explore ideas but deliberately doesn’t give them enough time to over-analyze their solutions. The objective is to generate ideas, not eliminate them because of judgments like, “Oh, that’ll never work.”

To do the Crazy Eight exercise hand out blank paper and have each participant fold the paper in half, then half again. This will create eight panels (front and back) on the sheet of paper. Give each person eight minutes to sketch eight different solutions, about one minute for each. Quick and dirty sketches are perfect. Once everyone is done, repeat the exercise. Repetition reinforces the “yes, and…” mindset and pushes participants to come up with new ideas that they may have never considered in the first round.

How Might We (30 mins)

How Might We is an innovation exercise used by Google, Facebook, Procter & Gamble, and design studio IDEO. The question, “How might we?” is another extension of the improv idea and pushes participants to think about how they could bring their solutions to life. To execute this exercise ask participants to write answers to the question as it relates to each of their solutions. For example, “How might we hail a taxi using a person’s GPS location?” Answers should be a short sentence or a sketched. Tim Brown, CEO of IDEO, says the How Might We technique works best with ideas that are ambitious, yet also achievable. Brown says it doesn’t work as well with problems that are too broad.

Storyboarding (30 mins)

The storyboarding exercise is designed to take the ideas generated by Crazy Eights and expanded by the How Might We questions, and develop them further. Each participant starts with a blank sheet and adds three Post-it notes down the side of the page. They should choose the most promising solutions to storyboard. Each Post-it note is one frame in the storyboard. The top note represents the current state of the customer; the second note is how the customer would experience the new solution; and the bottom note shows the outcome created by the new experience. Think of this as a storyboard for a short film. Each note should be used to draw the action. Use the space on the paper to the side of the Post-it to write a brief explanation. Each frame should be self-explanatory. If a participant needs to explain what’s going on in a frame, ask them to redraw the action. Once everyone is done, hang the storyboards up in the shared space.

Silent Critique (30-40 mins)

Once the ideation exercises are complete, the group will shift gears from non-judgemental creativity to individual critique. The purpose of doing this silently is so all voices get expressed, not just the senior leaders or influencers. Make sure all the storyboards are displayed on the wall, provide each person with several colored stickers (dot stickers) and ask participants to vote for the ideas they like best. Each person can use his or her entire allotment of stickers on one idea or distribute them in whatever way they see fit, even voting for their own ideas. The result will look a little like a series of heatmaps. The higher density dots indicate the most popular ideas.

Group Critique (45 mins)

Don’t do a group critique until the silent critique is complete. The group critique is exactly that, a chance for the entire team to discuss the ideas on the storyboards. The facilitator will gather everyone around each storyboard and ask them what they like about it. It’s essential that everyone gets to share what they like about each idea. The emphasis should be on the positives. In the next phase, participants will have a chance to think about the negatives. Note takers will capture this qualitative feedback.

Retrospective (15-20 mins)

This activity will be essentially the same each day–circle up, discuss the day’s work, and plan ahead for the next day.


Phase Three: Converge


The purpose of the Converge phase is to reduce the potential solutions to a single version that will be tested. To make this convergence possible, the facilitator needs to ensure the assumptions identified in the Understand phase are being considered. Only the idea that addresses the riskiest assumptions and is aligned with the Problem Statement should move to testing. Converging is hard work. The team will be responsible for choosing some ideas over others. This means making tough decisions, so let participants know in advance to be prepared to let go of some favorites.

Identify Conflicts (20-30 mins)

The entire group will be involved in this exercise as they seek to identify storyboards that are so similar that they can be merged. Approaches that conflict shine light on what choices there are in solving the problem. Talk through the different approaches and decide which is the best to continue with.

Review Assumptions (10 mins)

As mentioned, the alignment between a potential solution and the original assumptions is important. During each phase, the facilitator should remind the team of the assumptions. Gather the group around the assumptions board created on day one and discuss how the selected storyboard will address the assumptions. If the assumptions tests need to be adjusted or changed, do that now.

Assumption Test with… Validated if…
Customers want a shorter checkout process Prototype and interview Customers choose the prototype over the current checkout process
Customers understand the value of this feature Interview Customer can clearly articulate the value without prompting

Review Parking Lot or Back Burner Board (10 mins)

If ideas were created in the Diverge stage that should be preserved, add them to the Parking Lot or Back Burner board. Record the best ideas and then move on. Don’t get too distracted by these sideline ideas.

Sketching (30-40 mins)

Once the reviews are complete, the teams will start with three quick rounds of sketching. Once participants have selected a single storyboard/idea to pursue from the Diverge phase, individuals must sketch out what the solution might be and then share it with 1-2 other people for feedback.

These small teams must then make tradeoffs to combine their solutions into one. Small teams repeat the process one more time by sharing solutions across the broader team and creating a single version of the solution. By stepping this out into a multi-pronged approach participants are less likely to be overwhelmed by a single big decision. It also gives them a way to clearly articulate the reasons behind the design decisions they made earlier in the day.

Whiteboard the Final Storyboard (1-2 hours)

The final storyboard exercise is really important because it forms the foundation of the build and tests. The facilitator can lead this exercise by dividing the group into different roles. Some people will sketch while others rewrite the descriptions in detail. Don’t focus on design details, that will be the focus of the next phase.

The storyboard should be created in a way that the entire team can see it. The whiteboard is ideal. I’ve seen some cases where the facilitator does all the sketching at the whiteboard while the other members provide inputs. I don’t recommend this approach because it allows participants to sit back and watch the facilitator do most of the work.

Retrospective (15-20 mins)

Phase Four: Build (Prototype)


In enterprise environments, I prefer calling this phase “Build” rather than “Prototype.” The reason is not all solutions will be prototypes in the traditional sense. Some of the solutions I’ve participated in have been things like sales scripts or service interaction models. “Build” is a more inclusive term that’s less intimidating for non-designers. However, if you’re reading this book, there’s a good chance you’ll be designing digital solutions, and in that case, “Prototype” should work just fine.

During this phase, the primary activity is going to be designing and creating something that can be tested. If the group includes designers then use these skilled people to create the screens, pages or features you’ll be testing. If you have developers on the team you can also create HTML/CSS prototypes that will live on the web. The additional fidelity and interaction of a coded prototype means you’ll have a smoother user experience, but it’s not required.

If you don’t have developers on your design-sprint team, don’t panic. Paper prototypes are generally enough fidelity for testing your assumptions. The advantage of paper prototypes is they can be created quickly, inexpensively, and changes are often as simple as redrawing a screen.

Invision is made for prototyping and is my go-to tool for this exercise. Using the templates in InVision, even non-designers can create workflows using design outputs from applications like Sketch, Keynote or Photoshop. Even images from a smartphone camera can serve as the screens or pages of the app or website you’re designing.

Phase Five: Test


The final phase of the design sprint is to test the original assumptions, validate or invalidate the problem statement, and extract knowledge about customer’s preferences. The output will be the insights collected from customer or prospective-customer interviews.

While design sprints are structured to generate more qualitative than quantitative insights, both are still considered important. In the Understand phase, when we are formulating our problem statement we’re reviewing or collecting insights by discovering the problems customers are thinking about. In the Test phase, we want to validate (or invalidate) the problem statement. We do this by conducting just enough interviews that we can gather whether that problem is real or just someone’s perception.

The collective facts obtained from these interviews will enable you to make decisions based on objective observations. To do this you’ll need to recruit 7-12 potential users and give them access to the prototype. Specifics of recruiting and testing are discussed in the sections below.

Recruiting for Interviews

Bringing the users into the picture is often the most exciting part of the design sprint. Users are the fairy dust that you get to sprinkle on the design sprint because their feedback brings your prototypes to life. Once users start interacting with your prototypes you’ll get the answers you were seeking. The fundamental research questions or problem statements you need to answer will tell you who you need to engage in the interviews. Douglas Ferguson suggests asking the following questions: Are you looking for a new or existing user? Are they people who fit your sprint target? Whom should we exclude?

On the other hand, the design sprint’s short time schedule means you will need to start recruit candidates before you even start the sprint. Recruiting interview candidates will be different for each design sprint so I encourage you to plan ahead. Recruiting several users in just a few days can also be challenging and stressful. Without preparation, a team might find they have scheduled interviews with the wrong people. In a recent design sprint that was conducted to find solutions for LendingTree customers with low credit scores, the sprint team discovered that all the recruits had very high credit scores. As Ferguson cautions, “Be super careful that you are talking to the right people; take the time to prepare a proper screener.”

I’m not a fan of recruiting potential customers using Craig’s List and the promise of $100 for their time. This approach attracts candidates who are more interested in earning $100 than they are in giving you feedback on a problem they care about.

Interviews (a few hours to an entire day)

The Interview

Each team will have specific roles during the interview process. You’ll need at a minimum, one person to conduct the interview and one person to take notes, or be the observer.

Don’t expect good results if the interviewer is also expected to take notes. It’s difficult for an interviewer to be truly present if they are also trying to be a good notetaker. An interviewer should be focused on the interviewee and asking the right questions, while the notetaker will be taking objective notes about what they hear and see.

If you have a larger team you can create multiple interviewer and observer teams. Assign roles the day before during the Build phase so team members can prepare for what they need to do. The interviewer will prepare questions. Author and researcher, Steve Krug has created an extremely thorough list of scripts and suggested questions for interviewers.

The Remote Interview

I recommend you do all user interviews in real-time and, wherever possible, in person. However, when a remote interview is necessary, a video conference with screen-share functionality is best. This will allow the interviewer and notetaker to see the facial expressions and body language of the user.

Video conference tech also allows the interview team to record the conversation and review it again with the broader team. If an extended team or stakeholders will be joining via video conference, it’s necessary that they remain quiet and objective, and not interrupt the interviewer. Keep all feedback until the end when the user has left the room or video conference.

Don’t Coach Your Candidates

As excited as you might be about your potential solutions, be careful not to sell your ideas to the interview candidates. It’s more important to get a neutral candidate than someone that is going to support your idea. You are not selling or pitching them anything.

It’s also important that you don’t coach them towards an answer you’re hoping to hear. If a user is struggling, don’t jump to their rescue and tell them what to do. Rather say something like, “It looks like you’re still thinking about the step, can you tell me what’s on your mind?”

This Isn’t An Exam

Take your time to make the interview candidates feel comfortable. Interviewees can often feel like they’re being tested or graded so explain to them that their honest feedback is the best feedback. There are no right or wrong answers, only their unfiltered responses are needed.

This works in reverse too. Interviewers may believe an answer is wrong because of their own personal perspectives or biases. If you’re the facilitator, remind interviewers that they must be mindful of their tone of voice, facial expressions, and responses to feedback. Turning up your nose at a user’s response, because you don’t agree, sends a strong message that you don’t approve.

Negative Feedback is Often The Best Feedback

Rejecting feedback, because it wasn’t what you expected or desired, isn’t going to help uncover answers. Remember, a design sprint is a process for generating understanding. If a user is struggling through a flow or says negative things about the solution, that’s new information you can use to improve your work.

Instead of defending your solution to the user or redirecting them along a path you’re interested in, ask questions like, “Tell me more about that?” or “I’d love to know what you’re feeling?” Steve Krug has once again provided an excellent list of questions that an interviewer can ask.

Reviewing the Interview Sessions

Your recollections will be freshest immediately after an interview. However, it’s also common for memories—even fresh ones—to be filtered or obscured in some fashion. That’s why it’s so important to review notes, video, audio and observers comments to fill in the perceptual blanks to which we’re all prone and gain a broader perspective on the interview.

Consider, too, that the more interviews you do, the more likely your brain will filter the memories in order of last-to-first. The most recent interviews will be clearer than the interviews conducted earlier in the day. This is called the availability bias and happens when we overestimate the likelihood of something happening because a similar event has either happened recently or because we feel very emotional about a previous similar event. This can easily be overcome by reviewing interview notes and video.

Final Retrospective (15-30 mins)

Setting the Mind to the Phase

Jenny Gove, Kai Haley, and Marta Rey Babarro from Google talk about the evolution of sprints and how they have impacted teams across Google.

Each phase’s name describes what the team will be doing, but it doesn’t describe how participants should think. Below is a list of character roles that will help you and your team bring the right mindset to each phase of the design sprint.

  • Understand – think like a scientist
  • Diverge – think like an artist
  • Converge – think like a detective
  • Build (or prototype) – think like an architect
  • Test – think like a journalist

Thinking like a detective

Think of your team as a group of forensic experts sifting through the clues looking for evidence. The question you need to answer in the Understand phase is: “What’s going on here?” Seen through the lens of the customer, this might sound like: “Here’s a problem I would love to have a solution for.” In this phase, it’s important to stay away from questions and conversations about how a solution might be delivered or what form it might take. We’re not concerned with that at this stage. It’s first important to know whether there is a case that needs solving.

Thinking like an artist

Your customers probably don’t know what the solution should be, or that they even need it. All they know is they have a problem or a pain that they are currently putting up with. As a result, the customer is a great resource for understanding the problem, but not for trying to find the solution.

When you move to the Diverge stage, you’ll switch from an analytical mindset to a creative mindset. Your goal will be to create as many possible solutions as time allows. Embracing a sense of openness and a lack of judgment will help you get into the right frame of mind.

Thinking like a scientist

Converging on the best idea, or ideas, requires the puzzle-solving mentality of a scientist. During the previous phase, the team will have developed lots of possible solutions. The team will be piecing together the elements that work while discarding the ideas that don’t support our problem space. Don’t be afraid to put ideas aside if they don’t fit the best profile. Your Parking Lot or Burner Board is for capturing these ideas that may be worth exploring in a future design sprint or discovery activity.

Thinking like an architect

Having done the necessary detective work, your best idea will now have made it to the Build phase. As is often the case with building projects, we start by influencing its design, but then its mere existence has the effect of influencing how we behave. This is exactly what happens when we start architecting our prototypes. Our initial ideas become refined and improved when we see the product, service or ideas in action. This is sometimes described as “thinking by doing.”

Thinking like a journalist

If “thinking by doing” describes the architect’s mindset, then the journalist mindset might be described as “thinking by questioning.” Approach the problem as if you will be expected to provide sources, evidence, and a clear storyline. Think through the who, what, when, where, why and how the mantra of journalism. Consider questions like: How did we get to this point? Who is this about and who does it appeal to? Why were those people the target of this story? What makes them and this subject so interesting?



Planning Your Design Sprint


by Richard Banfield

Starting Before You Start

In the first two chapters, we emphasized the need to prepare appropriately to ensure success. This preparation sometimes referred to as “phase zero,” can be easily overlooked in the rush to get started. I strongly suggest giving phase zero the attention it deserves beginning several weeks before a design sprint. Even more time will be necessary for projects that involve senior team members and/or hard-to-tie-down customers.

Getting prepared involves inviting the right people, finding a good place to work uninterrupted, having the right supplies and, most importantly, setting up customer interviews. These are all related but independent tasks, so it might be necessary to delegate to your team. We’ll detail each of these tasks, and more, in this chapter.

Marta Rey Babarro, Kai Haley, and Jenny Gove from Google discuss some of the planning and preparation that go into running a good Sprint, including Sprint Briefs and Lightning Talks.

Setting a Goal

One of the first things to establish in phase zero is the purpose of the design sprint. The previous chapter outlined what sprints are and aren’t good for, so I won’t go back over that but know that phase zero is the time to make those determinations. Founder & President of Voltage Control, Douglas Ferguson suggests having the end in mind as you plan your sprint, “While I don’t advocate that teams lock their goal in stone prior to the sprint, it is helpful to explore the goal and have a thoughtful perspective on where you’re generally pointed.” A goal also aligns the group and helps them see the meaning in their participation.

Naming your design sprint

One of the frustrations design sprint organizers experience is convincing their colleagues to participate in something with the name “design sprint.” To the uninitiated, it sounds like something only designers should be attending.

If you encounter this bias, consider renaming the session something that will resonate positively with participants. Innovation Bootcamp, Spark Sessions, Discovery Sprint and Deep Dives are just some of the names you could use. Neeta Goplani, who I introduced in chapter 2, says renaming design sprints to Spark Sessions immediately changed the attitude of her senior managers at Manulife / John Hancock and gave her the buy-in she needed.

Goplani isn’t the only one who’s used this tactic. “As a veteran ed tech development director and product manager, I have worked through the development process using many different approaches and techniques, some worked well and others did not,” says Christine Sandvik, product manager at Imagine Learning in Provo, Utah. “While working as a consultant, I started using design sprints, which I called ‘concept sprints,’ to help clients understand why they needed to build a product or feature. The word ‘concept’ better described where I needed to concentrate most of our time—at the very beginning.”

Establishing if you’re sprint-ready

In enterprises with siloed functions, it’s important to confirm that the group knows why they are about to embark on the design-sprint journey. Even if you have an enthusiastic group of people, a facilitator, and you believe you have a good problem to solve, you might still not have the ingredients for a successful session.

Jay Melone poses two questions to help ensure you’re “sprint-ready”:

  1. Does everyone involved in, and impacted by this problem, understand why this is a problem that needs attention?
  2. Is this a problem worth solving?

Melone cautions, “If the answer to either of these is no, you cannot begin a design sprint. Well, you can, but don’t expect it to go well.” It’s better to postpone than attempt to muddle through. The most common misunderstanding is that understanding the problem translates to having a goal to achieve. Goals are not problems.

If you’re in any doubt, Melone suggests conducting a framing session before deciding to do a design sprint. The purpose of the framing session is to avoid “asking 7-10 people to spend five days (not including travel) running a full design sprint”. The framing session normally only requires a few hours and aims to separate the organization’s goals from the real pain points experienced by the customer. For example, “Launch new single sign-on feature” is an organizational goal, but without evidence that the customer needs this feature, it’s unclear if it’s a problem worth solving. Participants of a framing session each make a list of all their goals (individual and organizational), they then work as a group to discuss which of these goals are motivated by customer problems or by internal desires. Eliminate duplicates, merge similar challenges or create themes. Finally, discuss and prioritize the issue that will have the most impact, based on the resources (time, people, budget) at your disposal.

If you’re struggling to include the right people, even at this early stage, or if you can’t decide if this is a problem worth solving, take a step back. Rushing into a design sprint can backfire if you don’t have support, so rather take it a bit slower. In my experience, getting buy-in in larger organizations is the hard part, but it has to be done.

But Do You FEEL Ready?

Knowing when you’re ready is closely linked to preparation.

Preparing needs to be a balance between understanding what’s ahead and not getting stuck doing too much up front. For a facilitator an investment in how to run a successful design sprint (like reading this book) is necessary, but how much preparation will depend on the experience and cultural support of design thinking practices. Even for design veterans this sense of readiness can feel like more art than science.

“We chose the design sprint because we needed to do discovery for a brand new feature, but didn’t have time to do proper directed discovery as usually done here,” says Tanya Golubeva, Product Manager at Pluralsight, an online learning platform that recently completed a successful IPO. “The goal was to understand the feature we wanted to build, design it, and test it with a few internal customers. My UX designer organized how the days would be run. We both read the [design sprint] book, but I wish we would’ve had the entire team read the book first. Also, there were a couple of days when we were doing an exercise (like crazy eights), where preparation ahead of that day would’ve been extremely useful.”

In spite of this Golubeva felt the sprint was a success. “The team was initially really worried about spending an entire week not working on quarter’s priorities but by the end everyone was very supportive of us doing this work,” she says.

If you’re still uncertain if a design sprint is right for your team, consider doing a discovery needs assessment (DNA). This is an informal session of questions that can illuminate any major concerns and identify knowledge gaps. You can find all the DNA questions in the Appendix.

My advice is to approach the first design sprint as a learning exercise. Allow yourself permission to stumble a little and learn through experience. This mindset will allow you to get your feet wet while remaining mindful that obstacles will need to be overcome through experience.

Who Needs To Be at Your Design Sprint?

Have you heard the business fable about the chicken and the pig? It goes like this: When producing a dish made of ham and eggs, the pig provided the ham, which required a significant sacrifice. The chicken provided the eggs, which was an easy contribution. Both were needed, but only the pig was deeply committed.

When it comes to including people for the full five phases of your design sprint, try to choose only the pigs. But there are other considerations at play, too.

Group Size

Four to eight participants is an ideal size for momentum and efficiency. For larger groups, you’ll need to invest more time in preparation and logistics, and an experienced facilitator will be critical to keeping the cats herded.

Douglas Ferguson suggests pre-filtering exercise content with larger groups. “While it is possible to facilitate a larger group, it is important to consider the amount of content they will generate.” Ferguson suggests consolidating the teams inputs by splitting them into smaller groups during the sprint and asking them to narrow down their exercise answers before they share them with the entire group. “When working with larger groups, I recommend having them pre-filter their content. Instead of sharing all their sprint questions, they will just pick two or three. Instead of posting all their ‘How Might We’s’ on the wall, have them pick their top five, four, or three. Depending on the number of participants, you can decide how much content is best.”

Insight Owners

The guiding principle here is to have the right people in the room to find the answers you seek. It’s more important than having every department represented. With that said, you’ll want the following domains represented regardless of the group size:

  • Product ownership
  • Design
  • Development and/or engineering
  • Marketing
  • Senior leadership that represents the company level goals


You want a diverse group of people in the room. A diversity of backgrounds, functional knowledge and experiences helps avoid biases that come from groups that have common domain, demographic and cultural backgrounds. Diversity is also proven to be good for business, so I recommend building teams that reflect the widest possible diversity across your organization or pool of stakeholders.

At Northwestern Mutual, Scott Yim and his team work hard at getting participation from people outside of the design team in sprints.

Northwestern Mutual’s Scott Yim remains attracted to the design sprint because the process supports collaborative culture. “I just found it results in a better end-product for the user.” says Yim, “The diversity of opinion, experience, and thought around the table, where everyone is bought in and feels that sense of ownership. That’s something we can cultivate and make fabric of our culture. It just results in a better product at the end of the day.”

You Still Need the Chickens

You want to include the pigs whose jobs depend on the outcome of your design sprint. But you still need the contributions of some chickens, too. Trying to include everyone in a design sprint is difficult, but fortunately, there’s another option.

Ferguson suggests conducting “daily office hours” as a way to involve more members of your company without making the core sprint team too large. “Simply invite [the contributors] to attend daily office hours after the sprint team is done for the day. Walk them through all of the assets and activities of the day. Answer any questions they may have. This typically takes only 30 minutes and will allow you to include more people in your process. They will feel more included and understand the process and typically go on to be advocates for the solution.”

Facilitator Jay Melone also sees the value of preparing many but inviting a few. “Sometimes I’ve got a much smaller group in the framing and most of those people join the sprint. In other cases, a company might have a lot more people in the framing and only a subset of those people come to the design sprint.” Melone, who teaches design sprints to companies like Nike, Verizon, Audible, and Boeing, understands that not everyone will be available for the five-day sprint, but there’s no reason you can’t educate all the influencers and contributors. “Doing a problem-framing session beforehand is a good introduction to the mindset and the thinking.”

When you’ve got teams that aren’t familiar with design sprints, that could mean they’re not fluent with the broader UX and product-design world. So a design sprint is a good opportunity to bring a large group of people up to speed while making sure your smaller group of participants is prepared to work with the right attitudes and fluency.


Setting Expectations and Roles

Design sprints require a lot of work and focused attention from participants. In order to complete a successful sprint, it’s important to manage expectations in advance. This includes making sure everyone knows the goal of the sprint and what he or she needs to do to be valuable to the process. Here are some other important things participants should know:

  • A design sprint can’t solve every problem.
  • The process likely will uncover additional problems that need attention.
  • You probably won’t learn everything you set out to learn.
  • Solutions and hypotheses may be partially or completely invalidated.
  • Some things you test won’t work.
  • Shared understanding is the desired outcome, not a prototype.

Reading through this list you may worry that no one will want to participate. I find it’s helpful to discuss what will happen after the design sprint. Explain that If the original problem is solved, you might move on to refining your prototype and start planning how to integrate it into your product cycle. Discuss the possibility that if none of the solutions you build and test work, you’ve discovered what won’t be a good solution. This is a good thing. You just saved time and money.

When you don’t find a working solution, it might be necessary to go back to phase one and focus on understanding the problem. Did you solve for a problem that was meaningful for your company? Was the problem worth solving for your customers? You’ll have a ton of knowledge from the design sprint that will make a follow-on effort more efficient. If you ended up with more questions than answers, you’re doing a good job. This normally means you’re getting closer to a viable solution. But it’s important for participants to know this.

However your design sprint turns out, you’ll want to set expectations and do some light planning for what comes next. Participants get pretty invested in their ideas and want to know what the next relay of the course looks like after the sprint is over. (We’ll come back to this in Chapter 6.)

The Roles of a Sprint Team

Part of the magic of a design sprint is the separation of work between team members. Unlike traditional brainstorming sessions where all the members simultaneously generate ideas, the design sprint recognizes that a specialization of efforts creates a better result. By giving members roles that create, instigate, organize or collect, the design sprint provides focus where it’s most valuable, and flexibility when it’s required.

The Facilitator: This person will lead the design sprint. Their responsibilities are to ensure the right people are there, the background research has been gathered and the test subjects (customers and stakeholders) are available for interviews. They also are responsible for keeping the team focused on the tasks.

If you’re considering this role, but you don’t feel comfortable directing other people, you might need to hire a professional design-sprint facilitator. You’ll learn a lot just by watching a pro at work. Also, don’t try to facilitate and be an active participant. Facilitation is a full-time job and trying to do more will reduce the value of your participation and of the entire design sprint. Focus on doing one thing well.

Product Owner: This is the person at the company with the initial product vision or the person with ultimate responsibility for the product or project. New product ideas tend to be overseen by the person who is leading the innovation effort. Existing products will generally have a product manager or product lead who currently has responsibility for the product or service. Their title is less important than their final decision-making power over the project. If they can shut down your design sprint, then you’ll want them in the room.

Note Taker: This person’s job is to document the work. That means collecting all the notes, sketches, Post-its, and taking photos of anything that goes up on the whiteboard. Make sure the note taker has a system for ordering and labeling everything. There’s nothing more frustrating than looking for an important insight only to discover it wasn’t labeled or captured correctly. I highly recommend putting all these documented notes into a shared folder and creating a simple PDF of each of the phases. There’s no right or wrong way to capture notes, but clarity and access is important.

Team members: The rest of the team will be made up of the people you need to get the work done. As discussed previously, who gets invited will depend on what insights you will need (inputs) and who can help you get the answers you need (outputs).

Pre-Sprint Research

Pre-sprint research is critical not just for setting expectations, but also to enable the overall success of a design sprint. To make the most of the five days of the sprint, you’ll want to have a general idea of the customer’s real pain points. In a recent design sprint with the multinational software services group, CA Technologies, the facilitator Jill Starett showed a few short video clips of someone unsuccessfully trying to use their product for the first time. Jill says the video created tremendous empathy between the design sprint participants and the user, and this empathy was the necessary foundation for a true understanding of the pain point.

Customer interviews are another tremendously valuable tool. I recommend conducting between six and twelve interviews with current or prospective users before the design sprint to try to get clear on the problem you aim to solve. These interviews can be arranged and conducted by the facilitator or delegated to other team members. My preference is to have as many participants as possible engaged with customers or prospects before the design sprint starts to increase their sense of belonging and purpose in the sprint.

Along with interviews you’ll want to collect and review any qualitative and quantitative data that will provide valuable insights to the sprint. This could be surveys and studies, or data analysis from current product usage. I’ve found that spending the time to draft user journeys and experience maps before the design sprint also provides a solid foundation for conversations on day one. These user journeys and experience maps needn’t be comprehensive, as you’ll explore them in detail as part of the Understand phase.

Less Is More

It’s the organizer’s responsibility to ensure all participants are informed. However, too much research can easily overwhelm a design-sprint team. If you create a research brief to distribute before a sprint begins, keep it to no more than two pages (one piece of paper front and back) with relevant data points for research review.

When it comes to pre-sprint research, quality is more important than quantity. For example, when we embarked on a design sprint for Netapp, a Fortune 500 cloud-storage enterprise, we discovered the persona research they were referencing was four years old. The research predated several of their products and clearly needed updating. This made us aware that research hadn’t been a priority for a while and that we’d need to dig a little deeper to get the useful information we wanted. A bit of secondary research can also be helpful to set the stage for participants without overloading them with too much primary data.

Preparatory background research also includes some basic competitive analysis. Are there already solutions out there? Who has already succeeded or failed with this problem? My favorite research trick is to call competitors pretending to be a potential customer to hear how they pitch and price their solutions. How a company positions their value is a window into how well they understand their customers.

Nuts, Bolts, and Logistics

Image searches for the word “collaborate” invariably return stock photos of fashionably dressed hipsters standing at a Post-it note-covered whiteboard. The hipsters usually look fake, but the Post-it notes and whiteboard are totally legit. They’re part of the nuts and bolts that allow ideas to get out of our heads and into the collaboration space.

Working closely with a group of people you may have just met can be a big cognitive strain. Having the right environment, tools and mood can mean the difference between healthy collaboration and frustrating interaction. The little things go a long way towards making a group feel comfortable. “I had one participant who asked for salsa music on day two,” remembers Jill Starett. “She danced in place while she sketched.”

Everybody Loves an Agenda

It doesn’t have to be detailed to the minute, but participants like to have an agenda that gives them some sense of what they’ll be up to each day.

I prefer to start early when people are fresh and caffeinated, and then knock off a little early. Ending early gives me time as the facilitator to answer the individual’s questions and prepare for the next day. Whether you start earlier or later, try to keep each day to no more than six hours of actual work. Focused, creative work can be exhausting, so it needs to be paced. Depending on the group size you may want to add a few breaks for coffee and lunch. This gives participants time to catch up on emails, make calls or check in with their teams.

I’ve noticed cultural preferences play a big part in how the day is scheduled. In the U.S. it’s acceptable to have a working lunch where participants grab a sandwich and continue to push through the exercises. In Europe, a longer break for lunch is expected. I personally prefer a longer break, as it allows participants to disconnect for a while and recharge. The key is to balance focused participation with time to rest, reflect a bit, and communicate with the outside world.

As the facilitator or organizer, it’s your job to make participants feel comfortable about the work ahead. Before the sprint, send emails to the team with subject lines like: What to expect next week, or Stay tuned: We’ll be sharing an agenda template soon. Once underway, communicate the plans for each day upfront and at various intervals throughout the day. Add reminders of the schedule to the facilitator’s slide deck and hand out copies of the agenda to everyone on arrival for Phase 1. This will allow participants to plan phone calls, email or check-ins, and to handle any family obligations with less stress. Check the Appendix for templates to use in these helpful communications.

Supplies you’ll need to be effective

The tasks of sketching, creating shared-lists, crafting prototypes, and note-taking will require supplies. Below is a recommended list:

  • Post-it notes (a selection of colors and sizes is helpful)
  • Sharpies
  • Blank sheets of printer paper or heavy-stock printer paper to prevent Sharpie leakage
  • Whiteboard and whiteboard markers (the more colors the better)
  • Circle vote stickers (also called dot stickers)
  • Easel pads or large pads of paper
  • Craft paper or card (for prototypes)
  • Adhesive tape
  • Smartphone (for taking photos) or camera if you prefer

For groups considering larger interactive prototypes, add cardboard boxes and packing tape. Of course, you’re not limited to these suggestions. Feel free to use whatever you find in your workspace. I’ve seen some pretty cool airport security gate mockups made from old moving boxes, tablecloths and conference room chairs.

We’ve made it easy for you and created an Amazon shopping list for the supplies you’ll need. Feel free to customize your choices.

Recruiting customers for interviews

The sooner you start the process of finding customers to interview, the more successful the day-five interviews will be. For B2B enterprise customers, recruiting can take several days, so don’t wait until the last minute. If you already have access to customers then contacting them and communicating your requests for interviews will be as easy as sending out emails or making phone calls.

If you’re testing a new product, you’ll need to recruit prospective customers and this can be a little more complicated. There are several ways to do this. I recommend reading the guidelines provided by Steve Krug and by GV’s research team.

Setting Up, Getting Comfortable and Feeling Safe

I like to say that a design sprint is really just a good excuse to get people talking and bonding in a safe environment. Everything you do leading up to, and during the sessions, will have an influence on how participants think and behave. The room, the preparation, the tone of communications and even the dress code sends strong signals about what is expected of the team.

As Daniel Coyle writes in his book The Culture Code, “Seen through this lens, culture is not about soft stuff, it’s about signaling. In other words, culture is not a set of traits, it’s a signaling contest. Improve your signals, improve your culture.” I encourage organizers of sprints to create strong signals of creativity and psychological safety. Tell your team early and often that this is a safe place to be creative without judgment.

C. Todd Lombardo, Chief Product Officer of Vempathy, makes non-judgment a core part of design sprints by creating “Rules of our Design Sprint” at the start of day one. On a large sheet of paper he writes the rules that will keep people feeling open to sharing while scrutinizing the facts. His #1 rule is inevitably: “Be hard on ideas, and soft on people.”

The Room

Physical space influences how we behave and interact. A big room with plenty of whiteboards and natural light is the ideal physical space for a design sprint. Cramped, windowless environments will stifle creativity and can send the message that the design sprint is low-priority. The room also needs a place to pin or tape up sketches. If possible, try to secure a location off-site and away from daily distractions.

Don’t overlook the environmental impact of too much formality. Invite the team to wear casual clothes for the design sprint and ask them to bring their favorite snacks. “How many times have I heard participants say they should have worn different shoes, because man, the design sprint keeps you on your feet,” says Starett about the time spent at the whiteboard sketching and debating.

For design sprints that fall on a holiday, ask participants to take it a step further. “Our design sprint kicked off on Halloween,” says eClinicalWorks project lead Raj Indupri. “Half of the participants were in costume. Including one who dressed up like a witch.”

Take pictures of the team working together and share them with the group at the end of each day. Let participants take their work home with them once it has been captured. I’ve seen prototypes carefully packed away or carried out of a design sprint by their proud creators. Bonding is inevitable when people work closely together and participants often ask for something to remember those collaborative moments.

“At the end of a design sprint the participants absolutely couldn’t leave without having us all take a group picture as a way to say, ‘Yes, we did it!,’” says Tim Lupo, senior product manager at Fresh Tilled Soil. “That picture felt like the moment when you leave summer camp after having made tons of new friends who challenged you to do things you wouldn’t normally do outside of camp.”

You also can get participants in the groove by incorporating music into your exercises. Music keeps the energy up, gets the creative juices flowing, and is a good mechanism for crowd control. I use music at the start of the day to set the mood, during heads-down design sessions and to combat the inevitable post-lunch drowsiness. It’s certainly not necessary to have music playing all the time. Here are a few of my favorite Spotify playlists: electronic beats, soundtracks, and salsa.

Remote Design Sprints

Increasingly, design sprints are run with teams in several locations, but I highly recommend in-person sessions whenever possible. In fact, it’s often better to postpone a design sprint until you can find a convenient time for everyone to be together. However, if you can’t avoid it, there are some creative options for remote sprints.

Remote sprints don’t mean you have to do every day remotely. You can create a combination of on-site and off-site days that suit the team’s schedules and location. If it’s possible to do at least the first two days on-site, do that. It’s generally better to do the early phase in person to maximize the opportunity for chemistry and sharing ideas.

If you have to run a design sprint remotely, it’s best that all participants be remote. Having half the team in one location and the rest working remotely can create an us-versus-them mindset. You can level the playing field and keep everyone engaged by making the entire team remote.

If you go for a remote sprint, invest in a good multi-person conference system that can support several people continuously. You want to be certain everyone can talk, share, draw, and prototype in ways that keep them engaged. Screen-sharing and high-quality audio features are essential. Research suggests audio quality is often considered more important than video quality. Nevertheless, a good webcam is always appreciated.

The activities of a design sprint form a natural rhythm of (1) set clarity for activity goal and steps, (2) ideate individually, (3) share and diverge at a group, (4) converge as a group. Remote sprints can take advantage of this rhythm by allowing people to disconnect for stage 2 in the cycle. They may not need to do this for every activity, like crazy eights, but for some of the longer activities, like storyboarding, it‘s a necessary and useful reprieve to disconnect. Even if participants just mute and turn off cameras, it helps relieve the fatigue associated with a day-long conference call.

Capture everything from a remote sprint in whatever form makes the most sense for your team. For example, you can take photos of whiteboard sessions and sketches, use Google docs for notes, and video for interviews. My team has used a combination of Zoom (video conferencing), dedicated landlines (audio), Slack (messaging), and Google slides and docs (notes and visual asset capture) to run remote design sprints. We also use for audio transcriptions when necessary.





by Richard Banfield


While you could certainly create your own assets to plan and run your design sprints, these templates will make your work much easier. Modify them to fit your needs.

Discovery Needs Assessment (DNA)

If you are unsure of whether a design sprint is right for you one of my recommendations is to meet with the stakeholders or potential design sprint team or group to discuss the purpose of the design sprint and establish where the knowledge gaps might be. The answers to these questions will provide you with specific areas to address and highlight any concerns.

Here are some questions you can use to guide that discussion:

  • Why are you interested in a design sprint?
  • What is the problem or area you are hoping to address and why?
  • What do you know about the problem and users impacted?
  • Have you completed or created any of the following:
    • Primary user research – interviews, surveys, focus groups, etc.
    • Personas
    • User journey mapping
    • Market analysis
  • Is this for a new or existing product?
  • Do you have a solution in mind?
  • How confident are you that you’ve identified the right solution?
  • What is the impact if your solution fails?
  • What are your desired outcomes and how will these move the needle for you?
  • How does this initiative align with your current business/product strategy?
  • How familiar are you and your team with the design sprint process?
  • If anyone participated in a design sprint, what role did they play?
  • Who will be joining the sprint from your team?
  • Will they be able to dedicate a week to the sprint, or will we need to spread out the time?
  • Will everyone be participating for the full sprint?
  • Is it clear who the facilitator of the design sprint will be?
  • Where would you like to host the design sprint?
  • Can you describe this meeting space?
  • Does the meeting space have whiteboards? Projector? Individual and group breakout spaces?
  • Finally, what question should we have asked but didn’t?

About the Authors

Richard Banfield
CEO, Fresh Tilled Soil
Enterprise Design Sprints
Enterprise Design Sprints