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
GET READY TO SPRINT

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
IS IT TIME?

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
ON YOUR MARK...

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
A TEAM SPORT

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
LET’S GO

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
HOW’D YOU PLACE?

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
Appendix
THE COOL DOWN

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
03

Getting Senior Buy-in And Support

ON YOUR MARK...


by Richard Banfield

James Bull, a senior leader of R&D programs at Shopify, set up a design sprint workshop to spotlight different exercises, and he invited his senior leadership to participate. Following the workshop he sent this by email: “The team is so hyped on the design sprint. The fact that our chief design officer and co-founder were there was even better. They’re thinking, ‘Hey, if the senior folks are there then it must be worthwhile’. Huge win for us this week.”

Including senior leaders in a handful of exercises could be all that’s required to get their buy-in and enthusiasm, which is hugely important. If your leadership can’t see the value in what you’re doing, the project likely won’t get far. It’s been my experience that organizers who spend time rallying their leaders’ support for a design sprint are more successful than those who leave the preparation and communication to chance.

Leaders are often tasked to make decisions regarding resource allocation, planning choices, and talent acquisition. To get a leader’s support for the resources and access your design sprint requires, you need to put yourself in their shoes and imagine what they require to feel excited about the sprint. The more relevant information you can provide them, the more likely you’ll get their blessing.

When communicating with leaders, or anyone who has an interest in your design sprint, consider their motivations and priorities. Being empathetic and thoughtful about their needs gives you the perspective to help make your work relevant to their goals. In some cases you might be able to connect the outcomes of the design sprint to a person’s Key Performance Indicators (KPIs) or Objectives and Key Results (OKRs).

Frequently these outcomes need to be balanced by the risk of doing the additional work required by a design sprint. Anytime a team is engaged on a design sprint they will not be working on other work. In cases like these, asking for a little space to experiment with design sprints goes a long way. Justin Sachtleben, Design Director of USAA, explains how this worked for his team. “We approached the senior leadership and said, ‘look we’ll do whatever you want after a couple of weeks, but just like let us do a design sprint and show you the results first.’”

USAA is a massive financial services organization with 30,000 employees and 30,000 external partners. Those two weeks of experimentation gave the design team the wins they needed to create trust with the leaders. “It was wildly successful and we all had some great ideas, now our leaders want us to go work on those things for the next year or so,” says Sachtleben.

Related to this is that most leaders hate surprises. Their jobs require them to be informed, so the more you can prepare them with knowledge and understanding, the better their chances of looking good. If they look good, then that smooths the path for your design sprint. The best receptions for design sprints are fostered when both top-down and bottom-up approaches are run simultaneously. Having a senior leader champion design-thinking techniques will grease the wheels, while actively involving your colleagues in workshops and design sprints will convert them to believers.

While the “ask forgiveness, not permission” strategy might appear to be the way to go for some of you, the benefits to getting senior buy-in are far greater. “The biggest piece of all this is the transformational way we work, and the cultural shift in how we work,” says Home Depot’s Creef, about getting buy-in from the top. “Even our CMO has been exposed to what design sprints can do, and the benefits of it. Basically, he’s like, ‘We should be working like this all the time.’”

Kai Haley, Marta Rey Babarro, and Jenny Gove from Google speak about the history of design sprints at Google and how the process spread into teams like Corporate Engineering.

More Tips for Greasing the Wheels

“Most of our ideas are wrongheaded,” says Lean Enterprise author and facilitator, Barry O’Reilly. “In fact, 60–90 percent of ideas do not improve the metric they were intended to improve. You can invest in convincing people why your idea is the best, or you can invest that time in testing it to find out.”

Chances are your organization has lots of ideas or potential solutions for the problems it faces. Ideas tend to be a dime a dozen. The challenge is creating a reliable way to test ideas to determine if they’re worth following through on. That’s what design sprints do well.

Here are several suggestions for helping your team and leadership buy into the design-sprint process and not get bogged down in assumptions and opinions.

  1. Start to prepare long before the sessions are scheduled. Share info and insights about design thinking with influencers for several weeks. That way they aren’t surprised by your request for a workshop when the time comes.
  2. Make any design thinking workshop about them—your leaders. Do your research and find out what they’re working on and what’s a priority for them. Then you can include those insights into the outcomes/goals when you request their time for a workshop or session.
  3. Educate each participant about the session before they arrive. Nobody likes to look stupid, so invest time making them feel comfortable. You can do this with one-on-one’s or by sharing materials on what to expect.
  4. Focus the team on outcomes that are aligned with their goals. Give them something meaningful to work towards and don’t get too distracted by the “how.”
  5. Start each session with some ‘openers’ instead of icebreakers. Get them to open up and share some recent embarrassing or vulnerable moments with each other. Research shows this type of sharing helps people trust others more and increases brainstorming creativity by up to 26 percent. This also sets the tone for the rest of the session by making everyone more receptive to difficult conversations.
  6. If senior leaders are reluctant to support something that sounds like it’s only relevant to designers, then consider changing the name of the design sprint to something that aligns with your organization’s culture and goals. (More on this in the next chapter.)

Greasing the wheels is not a one-and-done effort. Sharing the value of a design sprint is an ongoing effort and can be done informally and formally.

Paul Stonick says there’s an opportunity to further establish design thinking at Home Depot by sharing the value of design sprint work. “We’ve done a considerable amount of socialization outside with the articles we’re writing, and how we’re going to be partnering with conferences,” he says. “We’re also going to be working closely with our internal groups, like our HR team, in terms of internal learning, continuing education. So we’ve launched a new program called Degreed, which is a learning platform, which allows people to pick specific tracks that they might be interested in.”

Working With and Around Research Departments

Enterprise research departments are often stretched thin, a situation that can compromise a future design sprint through a lack of relevant data.

Renda Morton, VP of design for The New York Times, explains how the organization deals with the situation. “The qualitative team on its insights is struggling to keep up with the demand across the whole product and design team, so we really have to prioritize what type of work they can take on,” she says.

To get around this obstacle, Morton suggests a DIY approach to qualitative research. Her team simply goes downstairs to 42nd street and talks to people on the street. Or they ask random people in the building’s cafeteria. However, Morton understands this type of research is limited. “You can’t really get to the larger why questions or uncover emotional needs, but it’s a good start.”

Merging Design Sprints With Agile, Lean and Design Thinking

For enterprises, knowing how a design sprint fits with waterfall, Agile or Lean process is important. Although Agile, Lean and design sprints are complementary, interrupting the daily schedule to host a five-day session can be challenging. So let’s discuss the ways these processes can blend together to deliver value to the teams that use them.

Agile

The primary advantage of using an Agile framework is the confidence it gives a team in knowing what to build next. Agile provides a way to deal with ambiguity by reducing the need to scope and define an entire product upfront and instead deal with the highest priorities first. Working in short bursts, or Agile sprints gives the team an opportunity to course-correct before it’s too late.

Design sprints work well to add another layer of confidence to the prioritization by answering tough questions quickly and turning assumptions into facts. Both types of sprints are valuable, timebox elements that provide guardrails and discipline to the work of product, design and dev teams. The design sprint suggests what to build, while the Agile sprint suggests how you’ll build it.

The traditional Agile sprint was the inspiration for the design sprint, and thus the timebox of a design sprint nests into Agile methodology with relative ease. Done at the beginning of a project, a design sprint can provide the answers that a delivery-centric Agile process needs to be effective.

There is no clear answer to the question, “Should I run my design sprint in parallel or interrupt my Agile sprints?” Design sprints that are run in parallel to an existing Agile sprint schedule tend to be effective when the answer you’re seeking is discrete enough that it doesn’t need the entire team’s attention. However, if you’re trying to solve a big problem that’s holding up further progress on your project, then interrupt the schedule and get the answers that are blocking your team’s progress. This interruption will pay dividends throughout the rest of the delivery cycle.

More reading on this topic.

Lean UX For Enterprise

Fundamentally, the Lean UX framework is similar to the design sprint. Both follow the scientific method of establishing a hypothesis and then testing that hypothesis in an effort to reduce risk and maximize understanding. This is good news for Lean organizations because your design sprint participants will feel at home with the process.

What will be even more familiar to Lean practitioners is the emphasis on testing ideas and “getting out of the building” to talk to customers. In no way is a design sprint a replacement for the Lean methodology, a process which incorporates several aspects of discovery, development and delivery.

Ian Armstrong, principal UX designer at Dell EMC, describes the relationship between the Design Sprint and the Lean UX approach like this, “Lean UX follows a build > test > iterate loop. The idea is to get a product in front of real people, learn from them, then improve it. The problem with lean UX is that users aren’t very forgiving and they aren’t big on second chances if we piss them off. Design Sprints are part of a dual-track agile methodology. They follow an unpack > ideate > evaluate > test > refine pattern that results in a user-validated (but rough) draft in a short span of time. It’s a non-standard sprint, executed with the express purpose of defining a robust agile backlog for design and development.”

The opportunity for Lean teams is that the design sprint will formalize the interview and qualitative data gathering a little further by providing a very specific hypothesis to test against. If you are using Lean as your primary delivery process my recommendation is to use the design sprint as a way to reduce initial risk on new initiatives or as a way to get answers to big questions.

Ultimately talking to customers is a priority in any investigation of what works and what doesn’t. Agile, Lean and design sprints all put an emphasis on testing assumptions with real users. If you’re already doing this as part of your design and development work, then you’ll find it very easy to get support from your team for the testing that’s part of a design sprint.

Design Thinking

In essence, Design Thinking is the umbrella under which the methodologies of Lean UX and design sprints reside. Therefore, fitting a design sprint into a culture of Design Thinking is generally easy as there will be a deep understanding of the principles that guide the process. In spite of that understanding, there might still be resistance to the specific exercises or rigid five-day schedule of a design sprint. In these cases, I recommend showing how the flow of the design sprint matches the double-diamond flow of the traditional Design Thinking methodologies.

Common Questions and Answers for Leaders

Here are some common questions or push-backs senior managers have when asked to give up time for a design sprint:

Q: What is a design sprint and why do I need to be part of it?

A: The design sprint is a customer-focused method used to unpack problems, get answers, and validate potential solutions. It’s become a popular way to efficiently and collaboratively jumpstart a project or initiative. Your involvement will increase the chance of us discovering answers to some of the tough questions we’re dealing with. Without your involvement, our progress won’t be as significant or we may miss something important.

Q: That’s nice but I’m not a “designer.” Is this workshop still right for me?

A: Design sprints aren’t just for designers. They’re actually most successful when cross-functional teams work together to uncover and test a problem or set of problems. The focus is on understanding problems and developing solutions, not on design. Design sprints are frequently applied to challenges within all facets of business including product design, marketing and operations.

Q: My team is already represented at this workshop. Why do I need to be there too?

A: If your representative has the authority to make decisions on your behalf, then you won’t need to be there. However, if you’re concerned they might lack important insights or perspectives that will impact the outcomes, I’d recommend you personally participate.

Q: What can I expect to get out of this?

A: We will actively solve problems that are holding your team back. Common outcomes include getting answers to tough questions, validating solutions, removing obstacles in understanding, and increasing team motivation and momentum.

Q: I can’t be there for the full 5 days.

A: Ideally, we’d like you there for each day, but we can make some adjustments. If we can’t have you for all five days please join us for the first two phases and the final phase. This is when we’ll agree on the problem area that needs the most attention, and when we’ll test the solutions with actual customers. On the days in between, we’ll make decisions on the solutions and how to test. If you want to be part of that, you could call in for certain exercises.

Q: Do I need to prepare for this?

A: No prep work is required for participants except to consider that this is a proven approach to answering tough questions. All you need to do on the days of the design sprint is show up ready to collaborate, participate and have fun. If there’s any research we feel you should read before the start, we’ll send you a summary to review.

Ultimately talking to customers is a priority in any investigation of what works and what doesn’t. Agile, Lean and design sprints all put an emphasis on testing assumptions with real users. If you’re already doing this as part of your design and development work, then you’ll find it very easy to get support from your team for the testing that’s part of a design sprint.

 

05

The Design Sprint

LET’S GO


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

Overview

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

Overview

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

Overview

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)

Overview

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

Overview

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?

 

About the Authors

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