Enterprise Design Sprints

Beyond the five phases


by Richard Banfield

The design sprint process works because it’s flexible. My advice is to treat it as a framework and don’t get bogged down in the exact processes outlined in this or other books. Every situation and organization is different enough that some customization will be necessary. Let’s talk about how to customize a design sprint for your specific needs.

There’s really no limit to how you can use the elements of the design sprint. Each exercise in each phase can be used in isolation or scaled to meet the needs of the problem. After all, the process is the scientific method applied in a highly efficient and time-boxed manner.

Time constraints

As important as the timebox is, it’s more important that you choose a time frame that suits your needs and fits the team’s availability. You don’t have to stick to five days if that means your team can’t be there. Doing something is better than not doing anything at all.

Jenny Gove, Kai Haley, and Marta Rey Babarro from Google discuss tactics for getting participation from people across the organization, including stakeholders and executives.

Conversely, trying to tackle too wide a scope or running too many back-to-back design sprints can result in the team running out of bandwidth or suffering from fatigue brought on by the intensive thinking and creative work required.

Instead of being too optimistic, tackle one problem at a time. Solving one juicy problem per design sprint is good enough. Focusing on one problem also helps avoid participant burnout. Asking people to step away from their desks for a whole week to participate in a design sprint is always a significant ask. It’s a worthwhile endeavor, but if you recruit participants for multiple design sprints, you’ll run into resistance pretty quickly and find it hard to recruit participants for future sprints.

Switching exercises

Swapping out a few activities in the course of a design sprint is common practice. Depending on your goals and what research you already have, this is perfectly acceptable.

When it comes time to create an agenda you can also prioritize certain exercises. For example, you may choose to spend more time exploring the user versus exploring the problem. You wouldn’t want to completely ignore the problem statement, but allotted less time for it if understanding your customers is the priority.

In short, consider that each exercise in a design sprint is also a standalone tool that produces clarity on an issue. These independent building blocks give you flexibility over the scope of the process. Adding more exercises gives you more confidence in your answers, but requires more time. Ultimately, what you add or subtract will depend on the level of risk you’re willing to accept.

Planning for your specific organizational needs

Because almost all the exercises have the ability to function independently, you could conceivably use many of them for different purposes. For example, having your team do eight-ups at the start of a design session can open up new creative pathways and get them thinking differently about a solution. Practicing interview sessions with teammates at the end of the Understand phase can fine tune the way you think about both the problem and the solution.

Once you’re familiar with the five phases, you can start experimenting with when and how you might fine tune them for your organization. For example, we mentioned in chapter 1 how Home Depot’s design leads formalized a preliminary research process. “We decided to partner with our user-research team to really get an understanding of the necessary research inputs that we need for each of the design’s frontiers,” said Brooke Creef.

Laine Henry, senior UX Designer at Northwestern Mutual sees customization of the design sprint structure as critical to their success, too. Her teams build presentation time into design sprints to share the ongoing work with the larger organization. “We will structure our [stakeholder] presentations either post-launch or during the process. We structure in-depth presentations along with the design sprint process, so you can see the iterative approach, you can see that fidelity, you can see the key decision points, the problem statements, the design principles,” she explains.

Laine Henry and Scott Yim from Northwestern Mutual talk about how sprints help teams build alignment on vision.

Henry believes the in-line presentation structure gives them the momentum they need in their large organization. “We are effectively reinforcing the design sprint value and also getting buy-in at the same time, so everyone becomes super familiar with that process, and they almost expect it.”

The structure and timing of a design sprint might also change to match how a company plans its product delivery or roadmap. “We map our design sprints to what we call inline innovation. So we’re tying the design sprints to the current roadmap items and ideating around those,” says Creef. “But then additionally, as the program is gaining traction, we are getting ahead of the roadmap, and we’re pushing some roadmap items as well. So it’s been kind of like a dichotomy of the two, of being roadmap driven, and then also driving the roadmap.”

Industry-specific applications of design sprints

Over the years, I’ve seen how design sprints can be applied to many enterprise scenarios. I’ve run design sprints for marketing teams, executive groups, and to tackle internal operational problems. I’ve heard of design sprints used to develop fundraising solutions for large nonprofits and even to plan individual careers.

To demonstrate the variety of scenarios in which a design sprint can be used, I’ve asked some of my colleagues and facilitators to share stories about their favorite enterprise sprints:

Industry: Pharmaceutical data

Problem: How will our customer access the data we collect?

How the design sprint helped: This particular organization had a very strong engineering culture and would lean toward software solutions for every problem they encountered. The design sprint was used to clarify how the customer, in this case, physicians, preferred to be engaged and what solution would be most attractive to them. Testing a prototype revealed that the customer preferred a non-digital and face-to-face approach to interacting with the data. This saved the company a year or more of effort.

Industry: Education

Problem: Should we develop a national scholarship program that will also increase awareness of our brand?

How the design sprint helped: The design sprint addressed this question, establishing that the scholarship would be welcomed by the market, but may not have the brand impact the company was seeking. The new insight allowed this education business to separate one initiative—the scholarship—from another, the need for better brand awareness. The design sprint work also acted as a workshop to educate the product team on how to facilitate design sprints.

Industry: Software development solutions

Problem: How do we take a difficult-to-use solution and make it easier for new customers to use in a way that makes them more successful?

How the design sprint helped: The participant team initially thought they had to design for a very sophisticated and meticulous user. During day one of the design sprint, user personas were separated from functional roles to ensure that buyers of the product weren’t being conflated with users of the product. The new personas mapped directly to different levels of sophistication. The result showed that small changes could be made to the product to serve less sophisticated customers and prospects without sacrificing functionality for the more sophisticated user base.

Industry: Biopharmaceutical

Problem: Do we need to modernize the UX and UI of an existing application to ensure customer loyalty?

How the design sprint helped: The problem assumed that external customers would need an improved UX/UI experience to secure their commitment to the product. The design sprint revealed that updating the UX/UI was not a problem the customer cared about but that internal customers, the employees of the company, were frustrated with the product UX/UI. By creating a prototype with an improved user flow to support the most common and critical employee tasks, the employee’s satisfaction was measurably higher.


Maintaining momentum after the sprint

After the heavy lifting is over, what should you do with the findings of your design sprint? The nature of seeking answers means every design sprint will have a different outcome.

The mantra for post-sprint action is: capture, iterate, and continue.

Although the team will have been capturing individual notes, insights, and test results throughout the design sprint, it’s also important to document the overall impact of the sprint. I like to remind my teams that we’re creating understanding, not just prototypes. The artifacts created will be the most visible part of the sprint, but those don’t tell the whole story. At the close of the design sprint, facilitators and note takers need to write up a summary of the week’s work. My recommendation is to try to do this in one page or less.

The path forward will be determined by your validation test results and the clarity of the answers. If a test invalidated your assumptions, that is as much a path forward as a result that validated your assumption. A clear answer means you’ll have strong signals as to what comes next. Weak, or unconvincing answers, usually means you’re going to have to narrow your focus.

Reporting out to the organization

Without exception, in the enterprise organization, it’s important to close the loop and provide feedback to stakeholders. Planning a formal what-we-discovered session on the last day of the sprint for senior stakeholders is a highly effective way to get the support needed for ongoing efforts.

Senior stakeholders are not the only people that need to be kept in the loop. Momentum is far easier to maintain when frequent follow-up with participants is scheduled.

“What we have implemented is a two-week check-in,” says Pluralsight’s Bhavika Shah. “Every two weeks after the sprint, we check in and everyone reports back on progress either on individual work that relates to our overarching outcome or the experiment that we want to do. We start vetting the feasibility of that experiment and chipping away at that, assess where we’re at, and figure out what we want to do next.”

It’s often worth booking a room for an extra week so team members have plenty of opportunities to walk non-participants through the artifacts and outcomes. But remember that the design sprint is less about creating pretty artifacts and more about finding answers. To ensure that these answers reach the influencers or senior decision makers, it’ll also be important to define what needs to be done next and who is responsible for doing the follow-up work.

“I was really nervous about setting this up because I had never really done anything like this before,” says Shah, “And I thought I had to have it figured out before it would be worth everyone’s time to come together. I guess my lesson learned is that there’s always value in collaborating. You don’t need to have a perfect session figured out in order for it to be worth everyone’s time. Just spending a couple of days together can bring a lot of ideas to the surface that have been kind of in the back of people’s minds. And just the power of having so many different perspectives in the room can make it really easy to flesh out ideas or problems that you’ve been thinking about but you haven’t necessarily had the space to resolve on your own.”

A powerful tool in your belt

As Shah suggests, the advantages of the design sprint are immediate and go well beyond the outcomes of the sprint itself. “We want to take over the world with this,” says Home Depot’s Paul Stonick, talking about the power of the design sprint. “You probably read the article by Lego. If you read it, line-for-line, and compare that with what we’re doing line-for-line in Brooke’s articles, and how we’re operating, we’re doing exactly the same thing.”

Stonick is referring to Lego’s use of design sprints to teach an entire organization the value of design thinking. “We’ve been doing it from a grassroots level in terms of scaling, and now making partnerships with different parts of the organization. It’s something we can bring to other parts of the organization.”

The momentum that companies like Home Depot, Lego, and Pluralsight are building is fundamental to their competitive advantage. These enterprises are benefitting directly from the transformational work of the design sprint. “There is a cultural shift in how we work,” says Stonick. “Even our CMO has been exposed to what design sprints can do, and the benefits of it. Basically, he’s said, ‘We should be working like this all the time.’ So there’s a lot of business transformation going on through design sprints.”

Stonick and Shah’s insights are not unique. The opportunity to connect people from different backgrounds and experiences seems to be a foundation for positive collaboration and the basis for digital transformation. Many of the people I’ve worked with and interviewed consider the design sprint a clever tool to get people talking to each other. I hope you discover that same thing.


Enterprise Design Sprints

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

Richard recently published Enterprise Design Sprints, a collaboration with InVision. Before that he published Product Leadership: How Top Product Managers Launch Awesome Products and Build Successful Teams, which he co-authored with Nate Walkingshaw and Martin Eriksson. He also authored Design Leadership and Design Sprint: A Practical Guidebook for Building Great Digital Products, which he c-oauthored with CTodd Lombardo and Trace Wax.

Richard is the CEO and co-founder of Fresh Tilled Soil, and under his leadership, Fresh Tilled Soil has delivered UX and product design to 700+ clients across the world. Clients include American Express, FedEx, Keurig, Intel, Harvard University, GE, Walgreens, BBVA, Shopify, Titleist, Citrix, and Genetech. His colorful life experience includes being an officer in the army and a dive master on the remote Islamic Republic of the Comoros.

Currently listening to: Loving J.S. Ondara’s Tales of America. This young, Kenyan born musician has a healthy dose of Dylan with the soul of Rodriguez.
Currently inspired by: Paul Klee inspires me every day. Transformed himself a dozen times through diligent introspection and a willingness to abandon old habits for new learning.
Cultural thing I’m lovin’: Loving all the Yuval Noah Harari books, and inspired by the work of Japanese architect Tetsuya Nakazono.