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
01

What design sprints do for enterprises

GET READY TO SPRINT


by Richard Banfield

The design sprint has become a trusted format for problem solving at many large companies, but there’s still concern amongst some enterprise organizations that it’s not appropriate for their needs. The evidence is mounting to the contrary as massive organizations, public enterprises, and government agencies rack up successes using sprints to overcome design and product roadblocks.

This book will explore their stories and address the specific challenges enterprise organizations face in preparing, running, and implementing the findings of design sprints.

I first heard of design sprints in early 2014 during a lunch with Google Ventures (GV) advisor, Rich Minor. During the lunch, Rich told me about a designer, named Jake Knapp, who had been leading exciting work with some of GV’s portfolio companies. As Rich described it, Jake’s design group at GV was achieving meaningful design wins in a week or less. I was skeptical at first. But by the time he had finished describing the five-phase process, my love affair with design sprints had begun.

Over the months that followed we started using the design sprint methodology on internal projects at my design firm, Fresh Tilled Soil, and with some adventurous clients. The more we used design sprints, the more impressed we became with the rapid results and the enthusiastic reception from clients.

We weren’t the only ones diving in. Dozens of startups and design studios around the world also were trying to understand how, when, and why a design sprint should be used. I frequently heard from product and design teams that a design sprint could solve all problems, and admittedly, I shared their optimism.

Throughout those early months, we tried hard to make the design sprint a starting point for every new project, and we learned a lot of valuable (and tough) lessons, including when to do a design sprint and when to do something else. As powerful as the design sprint process can be, it’s not appropriate for every project. (More on this later.)

In 2015, I published Design Sprint: A Practical Guidebook for Building Great Digital Products with C. Todd Lombardo and Trace Wax in an effort to share best practices we discovered with the entire design and product community. Since then, I’ve worked alongside my own team and enterprise teams to apply the design sprint methodology to hundreds of UX, product, and design problems.

The most exciting new discovery is the fact that design sprints are as useful to enterprise organizations as they are to startups. I’ve interviewed hundreds of enterprise product and design leaders on their experiences with design sprints and this guide aims to bring best practices up to date with information specifically relevant to teams and facilitators operating within the complex worlds of large organizations.

How enterprises benefit from design sprints

Design sprints are for small, nimble teams, not large enterprises. This is both fact and myth.

It’s true you cannot run a design sprint with 3,000 participants. Or 100. Or even 50. However, if you conduct it with the right dozen participants, you can bring rapid strategic results to an organization with thousands of employees.

Greg Storey, executive director of design at USAA and previously incubator program lead at IBM, says momentum is perhaps the biggest value that design sprints bring to a large enterprise. Storey emphasized the value of speed, “I think what makes them unique, and why we’re still using them, is we would hear [from senior leadership], ‘I can’t believe you got this much work done in this short amount of time.’”

For many large companies, momentum is difficult to build, making design sprints an attractive approach for high priority projects. Product managers find sprints especially useful in meeting their responsibilities to increase the speed of discovery and delivery.

Even when sprints take longer than average to execute, they get the attention of decision makers, because they produce actionable results and provide answers to momentum-scrubbing problems. Design sprints are an excellent way for groups to get unstuck and find a path of tangible progress for their companies.

Sustaining the momentum after the dust of a sprint has settled is a different challenge altogether. But we’ll talk about how to do that in Chapter 6: Beyond the five phases. For now, let’s look at some of the other enterprise-specific benefits generated by design sprints.

Enterprise-specific benefits of design sprints

Unpacks the complexity of the problem – When approaching innovation or problem solving, bigger companies often have more considerations to contend with than smaller organizations. More technology, more people, and more customers. The design sprint methodology helps to unravel the complexity by unpacking the various components, testing them, and validating or invalidating each one.

Reduces risk by providing deeper insight into the scope of a potential project – Knowing where to place your bets is a challenge all companies face, so bets must be carefully calculated. Too big, and you lose precious capital. Too small, and you lose impact. The exercises underpinning design sprints break apart a project so it can be scoped with clarity. They act like a zoom lens that can be aimed at any part of the project to reveal more detail or determine the level of risk.

Increases collaboration and understanding – The participatory nature of design sprints increase opportunities for communication between team members, and between teams and users. In fact, the human collision points are often the creative tension that drives innovation as the design sprint process innately shifts the mindset from arguing over solutions, towards exploration and discovery.

Demystifies the work of the design and dev teams – Organizational silos often make it harder for functional groups in an enterprise, like designers and developers, to understand each others’ work. Design sprints put these people together in ways that promote understanding and empathy.

Diminishes organizational politics in decision-making – Politics in a large organization typically boil down to competition for resources and influence. It doesn’t have to be maliciously motivated to derail a well-intentioned project. In contrast to these cultural norms, design sprints democratize decision making by emphasizing facts and evidence over assumptions and opinion. Testing ideas and prioritizing customer feedback forms the core of the process.

Highlights what knowledge gaps exist in your team – Design sprints spend a lot of time bringing clarity to the problem. (This is different from many other business processes that focus most of their efforts on the solution.) When discussing assumptions as a group, it becomes undeniably clear what the team knows and what it doesn’t know.

Gets people talking – A design sprint often brings different functional representatives, departments, vendors, and domain experts together. For many of these people, they will be collaborating or meeting each other for the first time. New connections mean new ideas and possibilities. “If these folks have never met before, then we’re really benefiting and learning from them,” says Founder & President of Voltage Control Douglas Ferguson. “They’re definitely going to have experiences we’ve never had.” Simply getting people talking, who are disconnected by an organization’s complex structure, is an undervalued part of the design sprint process.

Provides unbiased language for strategic discussions – A design sprint can give an enterprise the language it needs to share ideas and discuss problems without bias. The individual exercises focus teams on empathetic communication, elevating facts over opinions and breaking big problems into manageable pieces. Pulling problems apart with the right communication tools makes them seem less overwhelming and solutions become emergent, rather than dictated.

Ferguson shares an interesting anecdote about these last two benefits of design sprints. “I was working with a VP of product for a large company. Historically, he was able to just say ‘jump’ and people would jump. He built the roadmap, he defined the requirements, and people would go build.”

During the design sprint, the VP expressed a desire to return some authority to the team, but he kept falling back on old communication habits. Ferguson suggests it was because he lacked a new language to match his intentions. “Through running a design sprint, I saw him adapt and change to the point where you could see he was starting to really see the value in it. The biggest part of it was just learning to work in a new way. He reprogrammed how he thought and behaved.”

Transformations like this are common in design sprints. Participants receive new tools, in the form of language and behaviors, that set them up for more empathetic and collaborative engagements. I saw it first-hand when the CEO and COO of OfferLogic joined their product team during a design sprint I was facilitating.

“We’re not leading our people by selling our ideas to them. We’re actually restricting people’s creativity by doing that,” said OfferLogic co-founder, Doug Mitchell. This awakening happens when teams are provided with new tools to interact and collaborate.

Design sprints 101

The purpose of the design sprint is to get answers to a set of vital questions—not just to produce the prototype for the next version of your solution. A designer should always prioritize answers over prototypes. Put another way: outcomes over outputs.

To understand the true value of outcomes over outputs, it’s useful to see the distinction through the lens of the enterprise customer and end user. Outputs are the features and benefits of a service or product. Outcomes are the meaningful experiences customers receive when those services or products are put to work.

Consider the manufacturing enterprise that builds family cars. Their output is shaped metal and plastic. However, customers see more than just that. The customers see a way to get their families safely from one place to the next. They’re looking for the peace of mind that comes from being good protectors to their families. That’s the outcome. Outcomes convey meaning and relationship value, and they reflect the brand promises.

I’ve come to love design sprints for the simple reason that they focus people on valuing outcomes. Even when a sprint fails to provide a specific solution, the net effect is a team that’s more aligned on the big picture, which increases trust and brings barriers down.

Five phases in five days

The design sprint framework is broken into five stages, typically delivered over five days: Understand, Diverge, Converge, Prototype, and Test.

Design sprints align the team around a real or hypothetical problem, design an experiment to test this hypothesis, and then focus everyone’s efforts on a mutual goal of discovering a solution. This alignment, scrutiny, and validation improves the chance of making something people want.

By adhering to a strict schedule, there’s little or no waste in design sprints. Each phase has been carefully crafted to allow for enough time to do the exercises, but not so much time that teams get lost over-analyzing their ideas. The five phases also are crafted to reduce misunderstandings. First, by walking a team through the process of diagnosing a crucial problem to be solved, then by shifting the team’s attention to identifying as many possible solutions, and finally by zeroing in on the concept that has the most value to users.

Let’s take a look at the questions each phase forces us to answer:

  • Understand: What is the problem we’re trying to solve? Is this a real or imagined problem? Who is this problem relevant to and why do they care to have it solved?
  • Diverge: What hypothetical solutions might exist to solve these problems? What are all the creative ways we could approach this problem? What boundaries are constraining us?
  • Converge: Which of our ideas might work best to test our hypothesis? How can we select good solutions without being biased or presumptive?
  • Prototype: What will we need to build to run an experiment? How will we conduct this experiment to get the answers we need?
  • Test: Who will be the best people to experiment with? How will we find them and include them in our tests without influencing their choices or feedback?

Flexible time-frame

One of the most frequent questions I hear is, “Do we really need to do the design sprint in five days?” In most cases, the answer is simply, yes. However, in some cases, the best answer is, “It depends.”

It’s tough to carve out the time, especially at larger organizations. But doing so allows teams to really focus and go deep in critical areas. Before you completely dismiss the idea of dedicating five straight days, consider this: A client recently told my team it ordinarily would have taken her company a year to achieve as much as they did in a one-week design sprint.

With that said, teams that absolutely can’t dedicate a full work-week should aim to complete all five phases over a period of time that delivers the same value. For some organizations that may mean breaking up the five phases of a sprint and doing them as single days spread across several weeks, or longer.

Alternatively, some organizations choose to complete an entire sprint in less than five days. A small team can often get through the exercises quickly if they stay focused. (I’ve facilitated design sprints in periods ranging from three to four days.) The tradeoff is that as you shorten the duration of a design sprint, the depth of each phase becomes unavoidably more shallow, but that’s not necessarily a bad thing.

At The Home Depot, the team running design sprints, lead by Brooke Creef and Ryan Johnson, discovered they could get the best results by creating different time-boxed sprints for different outcomes. Their team has created three options: a one-day problem framing, a three-day design sprint, and the standard five-day sprint.

Brook Creef, Paul Stonick and Cliff Sexton discuss how design sprints came to The Home Depot and how they are spreading across the organization.

If a problem needs extra research to determine whether or not it’s worth solving, Home Depot begins with the one-day process. “The one-day problem framing is when a product partner comes to us, and they potentially want to do some ideation around an idea or a hypothesis,” explains Creef. “Here there might not be any research, and so we don’t want to necessarily turn those partners away, but we want to make sure that we are protecting the integrity of the problem space.”

During the one-day framing process, Creef and Johnson’s team takes participants through the first three phases of a design sprint. “At the end of the problem framing, we usually come out with anywhere from three to five sketches or wireframes that the team will then bring up in fidelity and test,” Creef says.

Make it work

Johnson and Creef also developed a three-day design sprint that appears to work well for Home Depot’s design-culture needs and fast-paced work environment. The three-day agenda goes through each of the five phases in a condensed timeline.

To ensure success, Creef and Johnson front load the three-day process with a generous amount of user research. “Research inputs for this sprint are three or more of the following: user-testing protocol, survey data, customer insights, data analytics, and a cautious value-proposition canvas,” Creef says. “At the end of the sprint, the team delivers low-fidelity prototypes or wires, value assessment, a level-of-effort assessment, a roadmap prioritization, and debrief deck.” Creef’s team named this upfront research the “Understand phase” and renamed the first phase of participant work (typically called Understand) to the “Investigate phase.”

“We’re really excited about the design-sprint opportunity, and working with our store partners,” says Paul Stonick, director of online user experience for Home Depot. “We have the benefit of 2,200 stores around the country, and Puerto Rico, Canada, and Mexico. So we have an opportunity to take the design sprint in a different direction where we partner with our in-store partners, and we walk out at the end of the week with a digital prototype and a store prototype.” By leveraging what Home Depot is doing across interconnected retail they have become a $7 billion e-commerce site. “We feel there’s an enormous opportunity right there to really change the business, and really make a difference.”

Thinking about shortening your design sprint?

Home Depot has developed a way to make shorter sprint processes work for their needs. But before you decide to condense a design sprint for your organization, ask yourself two questions:

  1. How much work are you going to otherwise accomplish in those five days that’s mission-critical to your business?
  2. Would your business be at risk if you worked on only one thing for five days?

“A Design Sprint is already a compressed design cycle, so when you do it in fewer than five days you’re asking to compress it even further,” says master design sprint facilitator, Jill Starett. “If a 500-meter dash feels too long, and you claim to only have time for a 50-meter dash, you will still run a race, but a very different one. And no matter how you slice it, you will not cover the same distance.”

Lastly, I’d urge facilitators to limit each phase to no more than a single day, because the time constraint acts as a forcing function to produce results. We’ll discuss this topic in more detail in Chapters 4 and 5.

Design sprints and organizational maturity

The challenges of planning a design sprint will vary from organization to organization. We’ll examine different tactical approaches in chapters 3 and 4, but let’s first discuss the strategic considerations of culture and organizational structure in planning a sprint.

The maturity of an organization determines in large part how it will embrace design and its rewards. Using Noel Burch’s four stages of learning as a framework, we can predict how a company may or may not recognize the value of a design sprint. These stages are even more relevant when applied to teams and individuals. Take a minute to consider where your organization or team lives.

If your company is at stage 1 or 2, you’ll be better off bringing in an expert to facilitate the design sprint. By doing this you’ll accelerate the learning process and provide an objective facilitator to manage the team. If you’re at a stage 3 company that’s already experimenting with innovation projects inside the business, you may want a member of your staff to lead the design sprint—but under the mentorship or guidance of a seasoned facilitator. Stage 4 companies should be able to run all design-related exercises internally.

Use the matrix below to further analyze where your team or company is right now. Naturally, there will be shades of gray where your organization may have teams in different stages of learning. Don’t try to match your entire organization to a stage, rather use it as a guide for your specific project and design sprint planning.

Also, don’t be tempted to overestimate where your company or team sits in this continuum. It’s more important to honestly identify your strengths and weaknesses.

If you’re at stage 1…

This stage is characterized by a culture that’s short on vision and strong on sales. In other words, customers call the shots by demanding new features, and the company simply responds without thinking of the long-term impacts.

If you’re at this stage, it will be necessary to do more preparation before starting a design sprint. Preparation will anticipate some of the pushback you’re likely to receive from team members who are unfamiliar with inventive, design-orientated sessions. The language of design sprints, and thus design thinking, will be new to your organization. Providing the team opportunities to discuss their fears, concerns, or assumptions before the design sprint starts is critical to success.

“In more and more of our design sprints with larger companies, we run a framing session beforehand which is a one day opportunity for them to not only discover which problems they want to prioritize and focus on but really get clear on why it’s important,” says Jay Melone co-founder of New Haircut, a New York- and Berlin-based firm specializing in design sprint facilitation. “Ultimately we’re after that really clearly defined problem statement that sets up a really well-articulated sprint.”

Preparing for a design sprint in a company environment that’s new to design lead practices also means being aware of how it’s positioned. Know your audience and prepare accordingly. This may include giving your design sprint a different name that’s a better fit for your culture (more about this in chapter 3). You’re also going to be better off with a seasoned facilitator to help you plan and run the sessions. If you don’t have the budget to hire a facilitator, then we suggest investing in the appropriate training.

If you’re at stage 2…

Organizations at this stage are often aware of the advantages of design lead solutions but haven’t developed the internal skills to run these sessions alone. There also may be pressure from the larger organization to focus on company-level financial metrics when assessing the effectiveness of a design sprint.

While there’s nothing wrong with including high-level financial goals in the conversation, the design sprint outcomes probably won’t have an immediate impact on metrics like share price and quarterly profits. It’s more realistic to focus outcomes on qualitative customer feedback and actionable insights.

Companies at stage 2 often have a strong process culture (e.g. agile, lean, etc.) but they’re still struggling to link these processes to outcomes that move the customer experience forward. This adherence to process can slow improvements and innovations down. The design sprint can be a low-risk bridge between rigid process and flexible collaborative techniques. By running a design sprint you’ll give your team a taste of what it’s like to make quick progress on problems that have become roadblocks to progress. Once your team sees the advantages of a design sprint, it’s less likely to be drowned out by the tide of arbitrary schedules, meetings, and check-ins so common with processes like agile.

“Provide an introduction of what is design, what is user-centered design, why are we here today, how has this been used in other applications that they can relate an emotional story to,” says New Haircut’s Melone. “We try to find stories that anyone can resonate with and feel some kind of connection to and awaken the mindset.”

In companies at early stages of maturity, there’s also a tendency to pigeonhole design sprints as an exclusive design-team activity. But designers are not the only people who need to be involved in the design sprint. As digital transformation expert, Jose Coronado says, “In the design continuum, all decisions that impact the product or service are design decisions, regardless of the roles or responsibilities of people who make them.”

Coronado’s experience at Accenture and McKinsey & Co. gave him access to dozens of enterprise design sprints. His work with McKinsey’s enterprise clients reinforced his perspective that an organization’s bias towards what is or isn’t design can result in only designers being invited to the design sprint.

Avoid excluding non-designers by inviting all the relevant functional teams to an info session on design sprints. At my firm, we call these “DNA sessions.” This stands for Discovery Needs Assessment and includes several people from different, influential parts of the organization. To ensure these sessions are successful in gathering information and aligning people on the goals of the upcoming design sprint, it’s important to include influencers who may not attend the actual design sprint, but have the power or authority to approve it or decide it’s necessary.

If you’re at stage 3…

In most stage 3 organizations, delivery of design and UX services is delivered on a project basis. Design engagements tend to be discrete and focused on improving the unit economics of a product or service. As organizations adopt stage-3 thinking, they begin to see design as a mindset for solving a wide range of problems. I like to say that these organizations have moved from design with a little “d” to Design with a big “D.”

ServiceNow, a cloud-based software company with dozens of locations around the world, is an example of a stage 3 company that has dedicated design and UX resources in the business, but those resources aren’t yet integrated into cross-functional product teams.

“We have a three-legged stool of architecture, design, and development that we’ll bring in on a pre-sales engagement, so we’re not a billable team. We’re not a paid service,” explains AJ Siegel, UX/UI Manager at ServiceNow. “We’re a cost of sale for ServiceNow to help get customers excited about investing in our platform. And so, we’ll engage over a very short period of time. This is perfect for things like design sprints, because we’re going to engage for anywhere from one to six weeks with a customer depending on the depth that we need to go.”

Given the structure of ServiceNow’s organization, this use case makes perfect sense. Their UX/UI capabilities are treated like an internal agency for other departments to use on demand. Design sprints are considered a tool offered by this agency-styled service, and thus makes sense that Siegel’s team would be the facilitators and coaches of a design sprint for their own organization.

Alignment around goals is another characteristic of enterprises becoming stage 3 organizations. For these companies to make a successful transition to this stage, particular attention needs to be given to ensuring all functional teams or departments are working toward the same outcomes. While strategic and product-vision alignment are the cornerstone of this transition, design sprints can serve to align teams in a very practical way, especially during the prototype phase. “It’s a form of requirements alignment,” says Douglas Ferguson, “Not only are they converting their requirements into a potential solution, but they’re also getting their team aligned on these requirements.”

The hands-on dynamics of a design sprint give teams tangible experience with design thinking. Thinking by doing is a powerful way to teach teams and organizations new skills. Ferguson says the prototype serves two functions. Firstly, it’s a “concrete thing” everyone can understand, because it’s right there in front of them. Secondly, when the ambiguity of what they’re building has been removed, the questions about what to test become a lot more specific. More specific questions result in better experiment design.

A general question, like “What do our customers want?” is hard to test, because answers can include a wide variety of preferences and choices. A very specific question, like “Will a new customer prefer to receive account confirmation by email or text?” is significantly easier to test.

If you’re at stage 4…

For the company that’s entered stage 4 thinking, the customer appears at the center of every conversation and metric. Company-centric measurements are replaced with metrics that measure customer satisfaction and happiness. This aligns well with the user-centric nature of design sprints. Validating whether or not the customer values a certain product or feature is the cornerstone of the design sprint process.

When combined with a company-wide appreciation of design’s ability to solve problems, the design sprint can help reinforce a learning culture. “Ideally you want to get your company to the point where it’s always in a hyper-learning phase,” says Nate Walkingshaw, CXO of Pluralsight, one of the world’s largest online-learning companies with hundreds of employees spread across the world. Because a company like this needs ongoing insights from customers to drive innovation, the design sprint is valuable for facilitating discovery. Walkingshaw describes this always-curious state, “Assume you have a lot more to learn. Structuring teams around that assumption gives you the organizational mindset to always be pushing forward.”

Stage 4 companies, like Pluralsight, nurture a culture focused on understanding. This culture turns the gaze of the organization to the customer’s needs and pain-points. Teams spend significant time with customers trying to understand what drives them, and metrics also are focused on customer outcomes, not just internal economics.

For enterprises to transition to stage 4, they need to adopt processes and tools—like design sprints—that force them to validate new ideas with customers. Jay Melone describes how Rosetta Stone, the global language-learning company, used design sprints to help establish this mindset while simultaneously solving problems relating to a recent acquisition.

“They were coming together to solve problems in a new customer segment, and to solve them together [with the newly acquired team] for the first time where Rosetta Stone would be selling as a B2B play.” Melone says they used the design sprint as a way to get the teams talking and to further understand how it might be used in other applications. “They wanted to use this sprint as a way to really learn the process and the tools. They also wanted to figure out who should be in the room and the thinking behind the exercises,” he says.

It benefits an enterprise to identify where they are on the learning continuum and then plan accordingly to take the next step toward greater design and user experience fluency. Assuming the organization will automatically make these steps in growth is a mistake. The identification and learning process needs to be deliberate and meaningful because the velocity of a product organization is highly dependent on the ability of its individuals and teams to learn new skills.

If your teams cannot adopt the most up-to-date design techniques and processes, they will slow down the entire organization. One of the most important techniques is the design sprint. In the following chapter, we’ll discuss the dynamics of the design sprint and when it’s most appropriate to use.

 

04

Planning your design sprint

A TEAM SPORT


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 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,” he said. 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 ready:

  1. Does everyone involved in, and impacted by this problem, understand why this 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,” 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 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 team’s inputs by splitting them into smaller groups during the sprint and asking them to narrow down their exercise answers before they share 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 company-level goals

Diversity

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 the 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 are 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 12 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 be the difference between healthy collaboration and frustrating interaction. The little things go a long way toward 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 US, 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 as 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 Rev.com for audio transcriptions when necessary.

 

About the Authors

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