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.

---

Design sprints are very helpful. It’s nice to have focused attention on a problem. It’s a gift to everybody working on the project.

Laurel Stanley

Herman Miller

Design sprints are very helpful. It’s nice to have focused attention on a problem. It’s a gift to everybody working on the project.

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.

James Bull, a senior leader of R&D programs at Shopify, set up a design sprint workshop to spotlight different exercises. He invited his senior leadership to participate. Following the workshop he sent this email:

“The team is so hyped on the design sprint. The fact that our chief design officer and co-founder were there was even better. They’re thinking, ‘Hey, if the senior folks are there then it must be worthwhile.’ Huge win for us this week.”

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

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

Sprint before sprinting

If you have a particularly difficult political environment or a complicated organizational structure, consider running a small internally focused sprint before your actual design sprint. In this exercise, your organization’s decision makers and influencers are your customers. Using their personal motivations and pains as your problem statements, you can work to find potential answers to their arguments before you even engage them. This way you’ll have evidence-based answers to their push-back or opinions well before you need them. And you’ll definitely need them.

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

Frequently these outcomes need to be balanced by the risk of doing the additional work required by a design sprint. Anytime a team is engaged on a design sprint they will not be working on other work. In cases like these, asking for a little space to experiment with design sprints goes a long way.

Justin Sachtleben, Design Director of USAA, explains how this worked for his team. “We approached the senior leadership and said, ‘Look we’ll do whatever you want after a couple of weeks, but just let us do a design sprint and show you the results first.’”

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

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

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

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

More tips for greasing the wheels

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

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

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

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

---

Sometimes designers see themselves as the owners of the design truth. However, designers cannot work in isolation, as they need their business partners to succeed. Designers need to learn how to communicate effectively with other people and areas of the organization.

Jose Coronado

McKinsey & Company

Sometimes designers see themselves as the owners of the design truth. However, designers cannot work in isolation, as they need their business partners to succeed. Designers need to learn how to communicate effectively with other people and areas of the organization.

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

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

Working with and around research departments

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

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

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

Merging design sprints with agile, lean, and design thinking

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

Agile and lean

Agile and lean coaches or consultants might give enterprises the impression that these development methodologies are an elixir for all problems. That is definitely not the case. The guiding principles behind these processes are extremely useful, but because every company is different, generic solutions should be approached with caution.

Agile

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

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

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

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

More reading on this topic.

Lean UX For enterprise

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

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

Ian Armstrong, principal UX designer at Dell EMC, describes the relationship between the design sprint and the lean UX approach like this, “Lean UX follows a build > test > iterate loop. The idea is to get a product in front of real people, learn from them, then improve it. The problem with lean UX is that users aren’t very forgiving and they aren’t big on second chances if we piss them off.”

“Design Sprints are part of a dual-track agile methodology. They follow an unpack > ideate > evaluate > test > refine pattern that results in a user-validated (but rough) draft in a short span of time. It’s a non-standard sprint, executed with the express purpose of defining a robust agile backlog for design and development.”

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

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

Design thinking

In essence, Design thinking is the umbrella under which the methodologies of lean UX and design sprints reside. Therefore, fitting a design sprint into a culture of design thinking is generally easy as there will be a deep understanding of the principles that guide the process.

In spite of that understanding, there might still be resistance to the specific exercises or rigid five-day schedule of a design sprint. In these cases, I recommend showing how the flow of the design sprint matches the double-diamond flow of the traditional design thinking methodologies.

Common questions and answers for leaders

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

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

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

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

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

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

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

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

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

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

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

Q: Do I need to prepare for this?

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

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