InVision Presents

Enterprise Design Sprints

by Richard Banfield

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

Go to Chapter
What design sprints do for enterprises

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

Go to Chapter
Go to Chapter
When to sprint

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

Go to Chapter
Go to Chapter
Getting senior buy-in and support

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

Go to Chapter
Go to Chapter
Planning your design sprint

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

Go to Chapter
Go to Chapter
The design sprint

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

Go to Chapter
Go to Chapter
Beyond the five phases

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

Go to Chapter
Go to Chapter

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

Go to Chapter

What design sprints do for enterprises


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.



When to sprint


by Richard Banfield

When design sprints were first introduced, they got significant traction in the digital-products space. However, the framework can be tailored to fit almost any problem-solving effort. Enterprises now use the design sprint to explore solutions for everything from logistics systems to sales scripts.

The design sprint is best used when you need an answer to an important question. Think of a design sprint as a validation machine. You insert questions in one end and you extract answers from the other. Questions can range from the strategic to the tactical.

Whether or not to run a design sprint depends on two important questions:

  1. Is this a problem worth solving?
  2. Do the important decision-makers in your company know this is a problem worth solving?

Answering these questions can be tougher than you might imagine. The world is littered with solutions that didn’t have a problem worth solving because too many companies regularly make the mistake of prioritizing solutions that customers aren’t willing to pay for. Our goal is to discover what customers need so that marketers don’t have to make them want something they don’t need.

For customer-driven questions

Amazon recently entered the same-day shipping market to respond to the needs of their customers. This sent a ripple through the logistics industry, and FedEx Ground contacted my team to explore the question: “How could we support same-day shipping in response to changing customer expectations?” As customers expect faster shipping options, FedEx needs to stay ahead of the curve with new solutions or be out-maneuvered by competitors. Customer-driven questions like these are ideal for the design sprint.

What was most obvious in this particular design sprint was how organizational assumptions can act as biases toward certain solutions. One common assumption with enterprises is the sunk-cost fallacy. As enterprises like FedEx grow, they accumulate significant infrastructure resources. Trucks, airplanes, airports, etc. Typically these are assets, but as we move to a sharing economy where almost any service can be outsourced to a local provider, these assets start to look like liabilities. Because these resources required massive investments of time and money, few leaders want to walk away from them even when they should. This is called the sunk-cost fallacy.

Questions in situations like these abound. What assets do we have that can be reused in a new paradigm? How will we balance our current operational needs with those of the future? Who will deliver these new services? How will we interact with the customer? What new infrastructure do we need to support these new systems?

For risks and assumptions

Our design sprint work at FedEx Ground was aimed to validate potential solutions. They already had some solutions in mind and were seeking to understand which of these options would work best and what the customer would consider valuable. In cases like these, the first round of design-sprint work is focused on separating assumptions from facts. By nature, facts are lower risk than assumptions, because they have evidence to back them up. Assumptions might only be supported by opinion, anecdotes, and out-of-date experiences.

Assumptions can send an enterprise off a cliff. Kodak discovered this when the company assumed digital cameras would take decades to catch on. This assumption ignored evidence, and the company paid the ultimate price. For this reason big, scary problems deserve design sprints. By comparison, low-risk ideas with high confidence don’t need the attention and structure that a design sprint provides.

The purpose of a repeatable process is to add efficiency and velocity to behaviors that might otherwise be unpredictable and unreliable. Without something like a design sprint, the vacuum left by a question might be filled with opinions. Or, out of a desire to maintain velocity, teams might substitute company mythology or widely held assumptions for real answers.

Answers are the fuel for decisions, and since answers are the primary output of a design sprint, it’s necessary to first unpack and test the assumptions. Any assumptions that are high risk and low confidence need to be addressed. This can be politically difficult, because some assumptions may be upheld by senior opinions. We’ve all heard the phrases, “We’ve always done it like that,” or “I wouldn’t do that.”

In the next section, we’ll explore how assumptions, opinions, and capabilities can act as biased roadmaps for projects, and how design sprints can reduce the impact of internal politics, identify risks, and provide clearer direction.

What design sprints are good for

Understanding why you might employ a design sprint to solve a problem or validate an idea is both important for the participating team, and for the people that will provide support and resources. Practitioners with design-sprint experience know how the process works to create business value, but for those who are new to the approach, there are always reasonable doubts.

One of the questions I’m asked frequently is, “How can a design sprint achieve in five days something that we haven’t been able to do in months or years?” To validate the high speed of a design sprint relative to the expectation that it takes a long time to create enterprise value, we need to explain how a design sprint delivers value.

The design sprint looks forward and thus can serve as a portal into the future. “We wanted to go blue sky and revamp an entire product,” Scott Yim, Senior Product Manager at Northwestern Mutual, says of how they applied the design sprint in response to feedback from the field. “We used the design sprint at the beginning of the project to define what the future could look like, and amongst the team, create a shared vision.”

It bears repeating that a design sprint is an ideal mechanism for uncovering customers’ needs. If you’re seeking answers about customer needs and potential solutions, a design sprint can do the job. Beyond identifying customers’ pain points, design sprints also are good for reducing risk, clearing up ambiguity, and unpacking complex problems.

Reducing risk

In effect, the design sprint is a lens. It focuses attention on the highest risks and simultaneously aims to reduce the number of unknowns within a problem area. This extends to political obstacles, too. Knowing who is standing in the way of progress and what their motivations are will provide a path to resolution that allows everyone to score a win.

Clearing up ambiguity

Design sprints are ideal for clearing up the ambiguity that may be holding back decisions and progress. Use a design sprint when you have an unanswered question (or even several questions) that will increase risk if left unanswered. Because the design sprint approach is very similar to the scientific method, which prioritizes objective facts over opinions, it can be leveraged to separate fact from assumption. This makes it attractive to smart business leaders who seek evidence-based answers to drive innovation or improvement.

Discovering user needs

In the Understand phase, the first of the five phases, design sprints are about building a case around what your user’s pain might be. It’s important to note that traditional research alone won’t always give decision makers the insights they need. In traditional research approaches, there’s a risk that organizations will value data that supports an existing solution over contradictory data. Design sprints are very useful in aligning potential solutions to user pains. However, it’s important to note that feasibility and usability (two other important product characteristics) are not the domain of the design sprint.

Unpacking complexity

Design sprints are also great for unpacking complexity. Enterprises are often complex by nature. This complexity is necessary for the business to deliver value and remain competitive, but it also means there are lots of dependencies and connections to each area of the business. A design sprint focuses on the human or customer experience making it easier to pinpoint the real pain point that needs to be solved.

Satisfying multiple stakeholders

The more stakeholders a solution is trying to solve for, or the more complex stakeholder needs are, the more suited a problem is for the rigor of a design sprint. Design sprint exercises allow participants to peel back the complexities with discrete thought experiments. This gives stakeholders more visibility into the nuances of the problem and the workings of the potential solution. The more visibility, the more likely a proposed solution will get support from all involved.

Although a design sprint can examine the needs of many stakeholders, it’s worth noting that it’s still a good idea to prioritize your outcome for a primary stakeholder to ensure your efforts aren’t too diluted.

Gathering proof for decision makers

Big companies often mean more gateways, influencers, and decision points. A single successful design sprint will not get you through all the decision maker tolls on your journey to shipping a new product or feature. It will, however, provide proof points and evidence that you can use to gather the approvals you need at each decision point.

Neeta Goplani, a Senior Director of Experience Design at Manulife / John Hancock, the financial services giant with thousands of employees, conducted several design sprints, which she renamed Spark Sessions, to establish proof points for future product discovery conversations.

Given the highly regulated nature of financial services, Goplani was incentivized to reduce risk and seek validation for all UX projects. By seeking customer validated answers before she met with senior leaders she was prepared for the inevitable questions. Following Goplani’s efforts, design sprints have become a popular way to fill the gaps in enterprise knowledge.

Home Depot’s UX team takes a similar approach. They consider the outcomes of each design sprint opportunities to gather further leadership support. “We go out a week and a half after the design sprint and we meet with our core team,” says Brooke Creef, UX Manager, design sprints at Home Depot. “Then additionally we present out to our stakeholders and leadership. We have something called office hours, where we meet with our VP. He was our first executive supporter of the program.”

Ryan Johnson and Jay Dicenso discuss some of the challenges and opportunities in getting non-designers to participate in sprints, and some of the tactics they use to engage them.

Creef points out that by closing the loop and showing senior leaders what has been achieved, the leaders see the value more easily and become excited about the work. As a result, Home Depot’s leadership has embraced design sprints and given them a “top-down push.”

Focusing on tough questions

The ultimate goal of using the design sprint is to switch the mindset of the team from just shipping deliverables to getting into the habit of answering tough questions. This switch in behavior won’t come at the same speed for each participant. Expect some pushback and even some misunderstanding. It’s better to be prepared for the naysayers than be caught off guard by their questions or frustrations.

While surprisingly useful as a driver of business value, a design sprint can’t be expected to solve every problem the enterprise will face. In the next section, we’ll discuss the scenarios when a design sprint is not a good choice.


What a design sprint can’t do

The original design-sprint format popularized by the Google Ventures team has been interpreted by some as a one-size-fits-all model. This was never the intention, and it’s definitely not the case for enterprise-level projects. Although UX, design and product teams have adapted sprints to find new applications for its prototyping value, it can’t be used in every situation.

Below are some situations in which a design sprint is not useful for enterprises. (It’s worth noting that this list is specific to enterprises. In some startups or small innovation groups, a design sprint might be the appropriate tool in these situations.)

For small iterative changes to an existing feature(s)

If you have an established product and you’re making small iterative updates, a design sprint is going to be too much tool. Rather, use one of the many exercises in the design sprint repertoire to answer a specific question. A quick prototype of a new improvement doesn’t need five days to prepare. Mock up a rough version and get it under the noses of customers that same day.

To update a prototype that’s already generating feedback

Once you have a prototype out in the wild and you’re receiving feedback from customers, it’s not necessary to do an entire design sprint before making refinements. Simply determine the questions you’re seeking to answer, identify the relevant feedback you’ve received, and make adjustments. If you want a more formal process, consider doing the just the last three phases of the design sprint (Converge, Build and Test).

Whenever there is no research

When planning a new project initiative or innovation, it’s best to already have research about what problems are worth solving (see chapter 1). Although the exercises in a design sprint help reveal a customer pain point and potential solution, they’re not ideal for establishing whether a market exists for that, or any, solution. Fundamental research is necessary for enterprises to discover opportunities that can then be validated with a design sprint. Don’t skip the research. Solutions without markets are destined to fail.

When seeking a high fidelity design output

A design sprint intentionally doesn’t provide high fidelity designs that you can immediately use in final product design. Remember, the purpose of a design sprint is to provide answers and direct your team’s attention to potentially viable solutions. The final design of your product or feature probably won’t look anything like the prototype you made to test your hypothesis. Keep your expectations real and you’ll be fine.

As a replacement for iterative workflow

Workflow considerations are slightly different from the iterative feature changes listed above. A feature change is often a discrete update, while iterative workflow is a choice of methodology (e.g. lean). While a design sprint can be valuable to test feature changes, it won’t be a substitute for the daily design and dev backlog. In enterprises where waterfall is still the preferred methodology for processing this daily work, the cadence of a design sprint is going to feel much faster. But that’s not a problem as long as you run the design sprint in parallel to your backlog of design and dev work. Stopping regularly scheduled work to do a design sprint, however, can be more disruptive than helpful in waterfall environments.

When looking for evidence of product-market fit

Finally, there is little evidence that evidence from a design sprint also confirms a product-market fit. Unless you are also testing pricing and benchmarking competitive offers, you’ll find it very difficult to know if your validated prototype is something people will pay for or switch over to from a competitive option. You’ll need to do further testing and possibly even ship an MVP to establish whether your market even wants your lovely new solution.

Like personas, JTBD (jobs to be done) and experience maps, the design sprint is just one of the many tools available to the designer and the broader product team. So it’s important to make sure you’re applying a design sprint to a design-sprint job. It’s also wise to remember a design sprint can invalidate an idea as easily as validate it. This sometimes means you’ll get an answer you don’t expect.

In a recent enterprise-client engagement, we were faced with a situation where a senior manager was convinced his product needed a significant redesign. It likely would have cost several hundred thousand dollars considering the complexity of the product. However, the team learned on the first day (Understand phase) that a redesign wasn’t a problem in need of solving. We pivoted to focus on the real issue affecting sales: the lack of a clear value proposition with accompanying language and sales collateral.

Here’s an unfortunate truth

Even if you do a design sprint correctly, you’re still likely to have lots of unanswered questions.

The very nature of this type of inquiry is that it reveals potential problems that need solving. Expecting your design sprint to be the endpoint for research is a recipe for disappointment. Instead, look for the doors that open through the process, and use your new insight to define additional research and data-gathering efforts. Establish this expectation with participants throughout the design sprint so you’re not asked to answer awkward questions at the end of the process.

A design sprint is a powerful tool with wide appeal and application. But it’s not going to solve every problem. Whenever you’re considering a design sprint, come back to these last few sections and confirm you’re setting yourself up for success. It’s also useful to know the exercises inside the design sprint, as each has the ability to be used discreetly. Understanding the value of each exercise will help you decide if you need to run an entire design sprint or just a few of the phases.

I like to think of a design sprint like a superhero’s utility belt. Sometimes you need all the tools in the belt, and sometimes just one or two will do. Chapter 5 will examine the tools in the design sprint belt. The guidelines follow directly from your decision to move ahead and will provide you with a detailed plan for your design sprint.

About the Authors

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