Enterprise

Design
Sprints
By Richard Banfield
Discover. Learn. Elevate.
Introducing the best practices, stories, and insights from

the world’s top design leaders. Loaded with in-depth books,

podcasts, and more, DesignBetter.Co is your essential guide to

building remarkable products and teams.

Check out the rest of the DesignBetter.co library

Design Systems Handbook

Design Leadership Handbook

Design Thinking Handbook

Principles of Product Design

Enterprise Design Sprints

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).
Contents
What Design Sprints Do for Enterprises
Get ready to sprint

When to Sprint
Is it time?

Getting Senior Buy-in And Support

On your mark...

Planning Your Design Sprint

A team sport

The Design Sprint

Let’s Go

Beyond the Five-Phases

How’d you place?

Appendix
The cool down
Chapter—01

What Design
Sprints Do for
Enterprises
Get ready to sprint
By Richard Banfield
The design sprint has become a trusted format for problem-

solving at many large companies, but there’s still concern

amongst some enterprise organizations that it’s not

appropriate for their needs. The evidence is mounting to

the contrary as massive organizations, public enterprises

and government agencies rack up successes using sprints

to overcome design and product roadblocks. This book will

explore their stories and address the specific challenges

enterprise organizations face in preparing, running and

implementing the findings of design sprints.

I first heard of design sprints in early 2014 during a lunch

with Google Ventures (GV) advisor, Rich Minor. During the

lunch, Rich told me about a designer, named Jake Knapp, who

had been leading exciting work with some of GV’s portfolio

companies. As Rich described it, Jake’s design group at GV

was achieving meaningful design wins in a week or less. I was

skeptical at first. But by the time he had finished describing

the five-phase process, my love affair with design sprints had

begun.

Over the months that followed we started using the design-

sprint methodology on internal projects at my design firm,

Fresh Tilled Soil, and with some adventurous clients. The more

we used design sprints, the more impressed we became with

the rapid results and the enthusiastic reception from clients.

We weren’t the only ones diving in. Dozens of startups

and design studios around the world also were trying to

understand how, when and why a design sprint should be used.

I frequently heard from product and design teams that a design

sprint could solve all problems, and admittedly, I shared their

optimism.

Throughout those early months, we tried hard to make the

design sprint a starting point for every new project, and we

learned a lot of valuable (and tough) lessons, including when to

do a design sprint and when to do something else. As powerful

as the design sprint process can be, it’s not appropriate for

every project. (More on this later.)

In 2015, I published Design Sprint: A Practical Guidebook for

Building Great Digital Products with C. Todd Lombardo and

Trace Wax in an effort to share best practices we discovered

with the entire design and product community. Since then, I’ve

worked alongside my own team and enterprise teams to apply

the design sprint methodology to hundreds of UX, product and

design problems. The most exciting new discovery is the fact

that design sprints are as useful to enterprise organizations as

they are to startups. I’ve interviewed hundreds of enterprise

product and design leaders on their experiences with design

sprints and this guide aims to bring best practices up to date

with information specifically relevant to teams and facilitators

operating within the complex worlds of large organizations.

How Enterprises Benefit

from Design Sprints
Design sprints are for small, nimble teams, not large

enterprises. This is both fact and myth.

It’s true you cannot run a design sprint with 3,000 participants.

Or 100. Or even 50. However, if you conduct it with the right

dozen participants, you can bring rapid strategic results to an

organization with thousands of employees.

Greg Storey, executive director of design at USAA and

previously incubator program lead at IBM, says momentum is

perhaps the biggest value that design sprints bring to a large

enterprise. Storey emphasized the value of speed, “I think what

makes them unique, and why we’re still using them, is we would

hear [from senior leadership], ‘I can’t believe you got this much
work done in this short amount of time.’”

For many large companies, momentum is difficult to build,

making design sprints an attractive approach for high priority

projects. Product managers find sprints especially useful

in meeting their responsibilities to increase the speed of

discovery and delivery.

Even when sprints take longer than average to execute, they

get the attention of decision makers, because they produce

actionable results and provide answers to momentum-

scrubbing problems. Design sprints are an excellent way for

groups to get unstuck and find a path of tangible progress for

their companies.

Sustaining the momentum after the dust of a sprint has settled

is a different challenge all together. 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.

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 other’s 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.

When these senior leaders saw their ideas

objectively scrutinized without personal bias,
they realized just how opinion-based their
viewpoints were. We all watched in surprise as
they expressed delight in having their minds
changed.

Richard Banfield — FRESH TILLED SOIL

“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.

The 5 Day Design Sprint

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

toward a mutual goal of discovering a solution. This alignment,

scrutiny and validation improves the chances 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 can get lost in 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 are the boundaries that are

either constraining us or helping us find a solution?

• 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.

“We were thinking, how can we take this across

the organization…into enterprise, into HR, into
finance…”

Paul Stonick — THE HOME DEPOT

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 wire frames that

the team will then bring up in fidelity and test after the design

sprint,” 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 [wireframes], value

assessment and 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.”

The Home Depot’s 3-Day Design Sprint

“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

and 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.”

We have the benefit of 2,200 stores around

the country, and Puerto Rico and 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.”
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.

Paul Stonick — HOME DEPOT

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:

01. How much work are you going to otherwise accomplish in

those five days that’s mission-critical to your business?

02. 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 are 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.

A Design Sprint is already a compressed

design cycle, so when you do it in fewer than
five days you are asking to compress it even
further. 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.

Jill Starett — FRESH TILLED SOIL

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.

Organizational stages of maturity

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 grey

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 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.

A design maturity model

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 push-back 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 its 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 it 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 towards 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 also to do it 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 towards 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 assimilate 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.
Further reading
Visual explanation of a design sprint

What happens before a design sprint

How design sprints are used for requirements alignment

List of hacks to further improve your design sprint

Design Sprint: A Practical Guidebook for Building Great Digital

Products

Sprint: How To Solve Big Problems and Test New Ideas in Just

Five Days
Chapter—02

When to Sprint
Is it time?

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:

01. Is this a problem worth solving?

02. 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 towards

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.

If you know in advance that it is going to work, it

is not an experiment.

Jeff Bezos — AMAZON

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.

Low risk, high risk

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.

Many unknowns, high familiarity

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.
Desirability, feasibility, usability

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.

Low complexity, high complexity

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.

Few stakeholders, many stakeholders

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.”

“Once we started to get the grassroots

support, we were able to make a lot of progress
really quickly.”

Ryan Johnson — HOME DEPOT

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 adapt 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 (i.e. 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.

The 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.

Further reading
United Nations: Increasing food donations with design sprints

The Value of Balancing Desirability, Feasibility, and Viability

Chapter—03

Getting Senior
Buy-in And
Support
On your mark...

by Richard Banfield
James Bull, a senior leader of R&D programs at Shopify, set up

a design sprint workshop to spotlight different exercises, and

he invited his senior leadership to participate. Following the

workshop he sent this by email: “The team is so hyped on the

design sprint. The fact that our chief design officer and co-

founder were there was even better. They’re thinking, ‘Hey, if

the senior folks are there then it must be worthwhile’. Huge win

for us this week.”

Including senior leaders in a handful of exercises could be

all that’s required to get their buy-in and enthusiasm, which

is hugely important. If your leadership can’t see the value in

what you’re doing, the project likely won’t get far. It’s been

my experience that organizers who spend time rallying their

leaders’ support for a design sprint are more successful

than those who leave the preparation and communication to

chance.

Leaders are often tasked to make decisions regarding

resource allocation, planning choices, and talent acquisition.

To get a leader’s support for the resources and access your

design sprint requires, you need to put yourself in their shoes

and imagine what they require to feel excited about the sprint.

The more relevant information you can provide them, the more

likely you’ll get their blessing.

PRO TIP — 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 like let us do a design sprint and show you the

results first.’”

USAA is a massive financial services organization with 30,000

employees and 30,000 external partners. Those two weeks of

experimentation gave the design team the wins they needed to

create trust with the leaders. “It was wildly successful and we

all had some great ideas, now our leaders want us to go work

on those things for the next year or so,” says Sachtleben.

Related to this is that most leaders hate surprises. Their jobs

require them to be informed, so the more you can prepare

them with knowledge and understanding, the better their

chances of looking good. If they look good, then that smooths

the path for your design sprint. The best receptions for design

sprints are fostered when both top-down and bottom-up

approaches are run simultaneously. Having a senior leader

champion design-thinking techniques will grease the wheels,

while actively involving your colleagues in workshops and

design sprints will convert them to believers.

While the “ask forgiveness, not permission” strategy might

appear to be the way to go for some of you, the benefits to

getting senior buy-in are far greater. “The biggest piece of

all this is the transformational way we work, and the cultural

shift in how we work,” says Home Depot’s Creef, about getting

buy-in from the top. “Even our CMO has been exposed to what

design sprints can do, and the benefits of it. Basically, he’s like,

‘We should be working like this all the time.’”

“When we bring people together who are

working on different products, it’s a really great
opportunity for people to…cross pollinate.”

Kai Haley — GOOGLE

Kai Haley, Marta Rey Babarro, and Jenny Gove from Google speak

about the history of design sprints at Google and how the process

spread into teams like Corporate Engineering.

More Tips for Greasing

the Wheels
“Most of our ideas are wrongheaded,” says Lean Enterprise

author and facilitator, Barry O’Reilly. “In fact, 60–90 percent

of ideas do not improve the metric they were intended to

improve. You can invest in convincing people why your idea is

the best, or you can invest that time in testing it to find out.”

Chances are your organization has lots of ideas or potential

solutions for the problems it faces. Ideas tend to be a dime a

dozen. The challenge is creating a reliable way to test ideas to

determine if they’re worth following through on. That’s what

design sprints do well.

Here are several suggestions for helping your team and

leadership buy into the design-sprint process and not get

bogged down in assumptions and opinions.

01. Start to prepare long before the sessions are scheduled.

Share info and insights about design thinking with

influencers for several weeks. That way they aren’t

surprised by your request for a workshop when the time

comes.

02. 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.

03. 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.

04. 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.”

05. Start each session with some ‘openers’ instead of

icebreakers. Get them to open up and share some recent

embarrassing or vulnerable moments with each other.

Research shows this type of sharing helps people trust

others more and increases brainstorming creativity by up

to 26 percent. This also sets the tone for the rest of the

session by making everyone more receptive to difficult

conversations.

06. 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

Greasing the wheels is not a one-and-done effort. Sharing the

value of a design sprint is an ongoing effort and can be done

informally and formally.

Paul Stonick says there’s an opportunity to further establish

design thinking at Home Depot by sharing the value of

design sprint work. “We’ve done a considerable amount of

socialization outside with the articles we’re writing, and how

we’re going to be partnering with conferences,” he says. “We’re

also going to be working closely with our internal groups,

like our HR team, in terms of internal learning, continuing

education. So we’ve launched a new program called Degreed,

which is a learning platform, which allows people to pick

specific tracks that they might be interested in.”

Working With and Around Research Departments

Enterprise research departments are often stretched thin, a

situation that can compromise a future design sprint through a

lack of relevant data.

Renda Morton, VP of design for The New York Times, explains

how the organization deals with the situation. “The qualitative

team on its insights is struggling to keep up with the demand

across the whole product and design team, so we really have

to prioritize what type of work they can take on,” she says.

To get around this obstacle, Morton suggests a DIY approach

to qualitative research. Her team simply goes downstairs to

42nd street and talks to people on the street. Or they ask

random people in the building’s cafeteria. However, Morton

understands this type of research is limited. “You can’t really

get to the larger why questions or uncover emotional needs,

but it’s a good start.”

Merging Design Sprints
With Agile, Lean and
Design Thinking
For enterprises, knowing how a design sprint fits with waterfall,

Agile or Lean process is important. Although Agile, Lean and

design sprints are complementary, interrupting the daily

schedule to host a five-day session can be challenging. So

let’s discuss the ways these processes can blend together to

deliver value to the teams that use them.

PRO TIP — 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.

Design sprints in an Agile process

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.
A decision tree on when to talk to customers. Source Joe Pour.

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.

The double diamond approach to design

Common Questions and

Answers for Leaders
Here are some common questions or push-backs senior

managers have when asked to give up time for a design sprint:

Q: What is a design sprint and why do I need to be

part of it?

A: The design sprint is a customer-focused method used

to unpack problems, get answers, and validate potential

solutions. It’s become a popular way to efficiently and

collaboratively jumpstart a project or initiative. Your

involvement will increase the chance of us discovering

answers to some of the tough questions we’re dealing with.

Without your involvement, our progress won’t be as significant

or we may miss something important.

Q: That’s nice but I’m not a “designer.” Is this

workshop still right for me?

A: Design sprints aren’t just for designers. They’re actually

most successful when cross-functional teams work together

to uncover and test a problem or set of problems. The focus

is on understanding problems and developing solutions, not

on design. Design sprints are frequently applied to challenges

within all facets of business including product design,

marketing and operations.

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

A: If your representative has the authority to make decisions

on your behalf, then you won’t need to be there. However,

if you’re concerned they might lack important insights or

perspectives that will impact the outcomes, I’d recommend

you personally participate.

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

A: We will actively solve problems that are holding your

team back. Common outcomes include getting answers to

tough questions, validating solutions, removing obstacles

in understanding, and increasing team motivation and

momentum.

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

A: Ideally, we’d like you there for each day, but we can make

some adjustments. If we can’t have you for all five days please

join us for the first two phases and the final phase. This is when
we’ll agree on the problem area that needs the most attention,

and when we’ll test the solutions with actual customers. On

the days in between, we’ll make decisions on the solutions and

how to test. If you want to be part of that, you could call in for

certain exercises.

Q: Do I need to prepare for this?

A: No prep work is required for participants except to consider

that this is a proven approach to answering tough questions.

All you need to do on the days of the design sprint is show up

ready to collaborate, participate and have fun. If there’s any

research we feel you should read before the start, we’ll send

you a summary to review.

Ultimately talking to customers is a priority in any investigation

of what works and what doesn’t. Agile, Lean and design

sprints all put an emphasis on testing assumptions with real

users. If you’re already doing this as part of your design and

development work, then you’ll find it very easy to get support

from your team for the testing that’s part of a design sprint.
Further reading
Fostering a Culture of Innovation

Lean Enterprise: How High Performance Organizations

Innovate at Scale
Chapter—04

Planning Your
Design Sprint
A team sport

by Richard Banfield
Starting Before You Start
In the first two chapters, we emphasized the need to prepare

appropriately to ensure success. This preparation sometimes

referred to as “phase zero,” can be easily overlooked in the

rush to get started. I strongly suggest giving phase zero

the attention it deserves beginning several weeks before a

design sprint. Even more time will be necessary for projects

that involve senior team members and/or hard-to-tie-down

customers.

Getting prepared involves inviting the right people, finding a

good place to work uninterrupted, having the right supplies

and, most importantly, setting up customer interviews. These

are all related but independent tasks, so it might be necessary

to delegate to your team. We’ll detail each of these tasks, and

more, in this chapter.

“For me as a researcher, the planning phase is

extremely important…what is the information
the team has around the user?”

Marta Rey Babarro — GOOGLE

Marta Rey Babarro, Kai Haley, and Jenny Gove from Google discuss

some of the planning and preparation that go into running a good

Sprint, including Sprint Briefs and Lightning Talks.

Setting a Goal

One of the first things to establish in phase zero is the

purpose of the design sprint. The previous chapter outlined

what sprints are and aren’t good for, so I won’t go back over

that but know that phase zero is the time to make those

determinations. Founder & President of Voltage Control,

Douglas Ferguson suggests having the end in mind as you

plan your sprint, “While I don’t advocate that teams lock their

goal in stone prior to the sprint, it is helpful to explore the goal

and have a thoughtful perspective on where you’re generally

pointed.” A goal also aligns the group and helps them see the

meaning in their participation.

Naming your design sprint

One of the frustrations design sprint organizers experience

is convincing their colleagues to participate in something

with the name “design sprint.” To the uninitiated, it sounds like

something only designers should be attending.

If you encounter this bias, consider renaming the session

something that will resonate positively with participants.

Innovation Bootcamp, Spark Sessions, Discovery Sprint and

Deep Dives are just some of the names you could use. Neeta

Goplani, who I introduced in chapter 2, says renaming design

sprints to Spark Sessions immediately changed the attitude of

her senior managers at Manulife / John Hancock and gave her

the buy-in she needed.

Goplani isn’t the only one who’s used this tactic. “As a veteran

ed tech development director and product manager, I have

worked through the development process using many different

approaches and techniques, some worked well and others

did not,” says Christine Sandvik, product manager at Imagine

Learning in Provo, Utah. “While working as a consultant, I

started using design sprints, which I called ‘concept sprints,’ to

help clients understand why they needed to build a product or

feature. The word ‘concept’ better described where I needed

to concentrate most of our time—at the very beginning.”

Establishing if you’re sprint-ready

In enterprises with siloed functions, it’s important to confirm

that the group knows why they are about to embark on the

design-sprint journey. Even if you have an enthusiastic group

of people, a facilitator, and you believe you have a good

problem to solve, you might still not have the ingredients for a

successful session.

Jay Melone poses two questions to help ensure you’re “sprint-

ready”:

01. Does everyone involved in, and impacted by this problem,

understand why this is a problem that needs attention?

02. Is this a problem worth solving?

Melone cautions, “If the answer to either of these is no,

you cannot begin a design sprint. Well, you can, but don’t

expect it to go well.” It’s better to postpone than attempt to

muddle through. The most common misunderstanding is that

understanding the problem translates to having a goal to

achieve. Goals are not problems.

If you’re in any doubt, Melone suggests conducting a framing

session before deciding to do a design sprint. The purpose of

the framing session is to avoid “asking 7-10 people to spend

five days (not including travel) running a full design sprint”.

The framing session normally only requires a few hours and

aims to separate the organization’s goals from the real pain

points experienced by the customer. For example, “Launch

new single sign-on feature” is an organizational goal, but

without evidence that the customer needs this feature, it’s

unclear if it’s a problem worth solving. Participants of a framing

session each make a list of all their goals (individual and

organizational), they then work as a group to discuss which of

these goals are motivated by customer problems or by internal

desires. Eliminate duplicates, merge similar challenges or

create themes. Finally, discuss and prioritize the issue that will

have the most impact, based on the resources (time, people,

budget) at your disposal.

If you’re struggling to include the right people, even at this

early stage, or if you can’t decide if this is a problem worth

solving, take a step back. Rushing into a design sprint can

backfire if you don’t have support, so rather take it a bit slower.

In my experience, getting buy-in in larger organizations is the

hard part, but it has to be done.

But Do You FEEL Ready?

Knowing when you’re ready is closely linked to preparation.

Preparing needs to be a balance between understanding

what’s ahead and not getting stuck doing too much up front.

For a facilitator an investment in how to run a successful

design sprint (like reading this book) is necessary, but how

much preparation will depend on the experience and cultural

support of design thinking practices. Even for design veterans

this sense of readiness can feel like more art than science.

“We chose the design sprint because we needed to do

discovery for a brand new feature, but didn’t have time to do

proper directed discovery as usually done here,” says Tanya

Golubeva, Product Manager at Pluralsight, an online learning

platform that recently completed a successful IPO. “The goal

was to understand the feature we wanted to build, design

it, and test it with a few internal customers. My UX designer

organized how the days would be run. We both read the [design

sprint] book, but I wish we would’ve had the entire team read

the book first. Also, there were a couple of days when we were

doing an exercise (like crazy eights), where preparation ahead

of that day would’ve been extremely useful.”

In spite of this Golubeva felt the sprint was a success. “The

team was initially really worried about spending an entire week

not working on quarter’s priorities but by the end everyone

was very supportive of us doing this work,” she says.

If you’re still uncertain if a design sprint is right for your team,

consider doing a discovery needs assessment (DNA). This is

an informal session of questions that can illuminate any major

concerns and identify knowledge gaps. You can find all the

DNA questions in the Appendix.

My advice is to approach the first design sprint as a learning

exercise. Allow yourself permission to stumble a little and learn

through experience. This mindset will allow you to get your

feet wet while remaining mindful that obstacles will need to be

overcome through experience.

Who Needs To Be at
Your Design Sprint?
Have you heard the business fable about the chicken and the

pig? It goes like this: When producing a dish made of ham and
eggs, the pig provided the ham, which required a significant

sacrifice. The chicken provided the eggs, which was an easy

contribution. Both were needed, but only the pig was deeply

committed.

When it comes to including people for the full five phases of

your design sprint, try to choose only the pigs. But there are

other considerations at play, too.

Group Size

Four to eight participants is an ideal size for momentum and

efficiency. For larger groups, you’ll need to invest more time in

preparation and logistics, and an experienced facilitator will be

critical to keeping the cats herded.

Douglas Ferguson suggests pre-filtering exercise content

with larger groups. “While it is possible to facilitate a larger

group, it is important to consider the amount of content they

will generate.” Ferguson suggests consolidating the teams

inputs by splitting them into smaller groups during the sprint

and asking them to narrow down their exercise answers

before they share them with the entire group. “When working

with larger groups, I recommend having them pre-filter their

content. Instead of sharing all their sprint questions, they will

just pick two or three. Instead of posting all their ‘How Might

We’s’ on the wall, have them pick their top five, four, or three.

Depending on the number of participants, you can decide how

much content is best.”

Insight Owners

The guiding principle here is to have the right people in the

room to find the answers you seek. It’s more important than

having every department represented. With that said, you’ll

want the following domains represented regardless of the

group size:

• Product ownership

• Design

• Development and/or engineering

• Marketing
• Senior leadership that represents the company level goals

PRO TIP — Hiding in plain sight

Employees from support and sales teams that talk with

customers and prospects every day often have the best

context and insights to share.

Diversity

You want a diverse group of people in the room. A diversity

of backgrounds, functional knowledge and experiences

helps avoid biases that come from groups that have common

domain, demographic and cultural backgrounds. Diversity is

also proven to be good for business, so I recommend building

teams that reflect the widest possible diversity across your

organization or pool of stakeholders.

“We worked really hard at dispelling the myth

that you had to be a designer to contribute
something valuable.”
Scott Yim — NORTHWESTERN MUTUAL

At Northwestern Mutual, Scott Yim and his team work hard at getting

participation from people outside of the design team in sprints.

Northwestern Mutual’s Scott Yim remains attracted to the

design sprint because the process supports collaborative

culture. “I just found it results in a better end-product for

the user.” says Yim, “The diversity of opinion, experience,

and thought around the table, where everyone is bought in

and feels that sense of ownership. That’s something we can

cultivate and make fabric of our culture. It just results in a

better product at the end of the day.”

You Still Need the Chickens

You want to include the pigs whose jobs depend on the

outcome of your design sprint. But you still need the

contributions of some chickens, too. Trying to include

everyone in a design sprint is difficult, but fortunately, there’s

another option.

Ferguson suggests conducting “daily office hours” as a way to

involve more members of your company without making the

core sprint team too large. “Simply invite [the contributors] to

attend daily office hours after the sprint team is done for the

day. Walk them through all of the assets and activities of the

day. Answer any questions they may have. This typically takes

only 30 minutes and will allow you to include more people in

your process. They will feel more included and understand the

process and typically go on to be advocates for the solution.”

Facilitator Jay Melone also sees the value of preparing many

but inviting a few. “Sometimes I’ve got a much smaller group in

the framing and most of those people join the sprint. In other

cases, a company might have a lot more people in the framing

and only a subset of those people come to the design sprint.”

Melone, who teaches design sprints to companies like Nike,

Verizon, Audible, and Boeing, understands that not everyone

will be available for the five-day sprint, but there’s no reason

you can’t educate all the influencers and contributors. “Doing a

problem-framing session beforehand is a good introduction to

the mindset and the thinking.”

When you’ve got teams that aren’t familiar with design sprints,

that could mean they’re not fluent with the broader UX and

product-design world. So a design sprint is a good opportunity

to bring a large group of people up to speed while making sure

your smaller group of participants is prepared to work with the

right attitudes and fluency.

Setting Expectations
and Roles
Design sprints require a lot of work and focused attention

from participants. In order to complete a successful sprint, it’s

important to manage expectations in advance. This includes

making sure everyone knows the goal of the sprint and what

he or she needs to do to be valuable to the process. Here are

some other important things participants should know:

• A design sprint can’t solve every problem.

• The process likely will uncover additional problems that

need attention.

• You probably won’t learn everything you set out to learn.

• Solutions and hypotheses may be partially or completely

invalidated.

• Some things you test won’t work.

• Shared understanding is the desired outcome, not a

prototype.

Reading through this list you may worry that no one will want

to participate. I find it’s helpful to discuss what will happen

after the design sprint. Explain that If the original problem is

solved, you might move on to refining your prototype and start

planning how to integrate it into your product cycle. Discuss

the possibility that if none of the solutions you build and test

work, you’ve discovered what won’t be a good solution. This is

a good thing. You just saved time and money.

When you don’t find a working solution, it might be necessary

to go back to phase one and focus on understanding the

problem. Did you solve for a problem that was meaningful

for your company? Was the problem worth solving for your

customers? You’ll have a ton of knowledge from the design

sprint that will make a follow-on effort more efficient. If you

ended up with more questions than answers, you’re doing a

good job. This normally means you’re getting closer to a viable

solution. But it’s important for participants to know this.

However your design sprint turns out, you’ll want to set

expectations and do some light planning for what comes next.

Participants get pretty invested in their ideas and want to know

what the next relay of the course looks like after the sprint is

over. (We’ll come back to this in Chapter 6.)

The Roles of a Sprint Team

Part of the magic of a design sprint is the separation of work

between team members. Unlike traditional brainstorming

sessions where all the members simultaneously generate

ideas, the design sprint recognizes that a specialization

of efforts creates a better result. By giving members roles

that create, instigate, organize or collect, the design sprint

provides focus where it’s most valuable, and flexibility when it’s

required.

The Facilitator: This person will lead the design sprint. Their

responsibilities are to ensure the right people are there, the

background research has been gathered and the test subjects

(customers and stakeholders) are available for interviews.

They also are responsible for keeping the team focused on the

tasks.

If you’re considering this role, but you don’t feel comfortable

directing other people, you might need to hire a professional

design-sprint facilitator. You’ll learn a lot just by watching a pro

at work. Also, don’t try to facilitate and be an active participant.

Facilitation is a full-time job and trying to do more will reduce

the value of your participation and of the entire design sprint.

Focus on doing one thing well.

Product Owner: This is the person at the company with the

initial product vision or the person with ultimate responsibility

for the product or project. New product ideas tend to be

overseen by the person who is leading the innovation effort.

Existing products will generally have a product manager or

product lead who currently has responsibility for the product

or service. Their title is less important than their final decision-

making power over the project. If they can shut down your

design sprint, then you’ll want them in the room.

Note Taker: This person’s job is to document the work. That

means collecting all the notes, sketches, Post-its, and taking

photos of anything that goes up on the whiteboard. Make

sure the note taker has a system for ordering and labeling

everything. There’s nothing more frustrating than looking

for an important insight only to discover it wasn’t labeled

or captured correctly. I highly recommend putting all these

documented notes into a shared folder and creating a simple

PDF of each of the phases. There’s no right or wrong way to

capture notes, but clarity and access is important.

Team members: The rest of the team will be made up of

the people you need to get the work done. As discussed

previously, who gets invited will depend on what insights you

will need (inputs) and who can help you get the answers you

need (outputs).

Pre-Sprint Research

Pre-sprint research is critical not just for setting expectations,

but also to enable the overall success of a design sprint. To

make the most of the five days of the sprint, you’ll want to

have a general idea of the customer’s real pain points. In a

recent design sprint with the multinational software services

group, CA Technologies, the facilitator Jill Starett showed a

few short video clips of someone unsuccessfully trying to

use their product for the first time. Jill says the video created

tremendous empathy between the design sprint participants

and the user, and this empathy was the necessary foundation

for a true understanding of the pain point.

Customer interviews are another tremendously valuable tool.

I recommend conducting between six and twelve interviews

with current or prospective users before the design sprint

to try to get clear on the problem you aim to solve. These

interviews can be arranged and conducted by the facilitator or

delegated to other team members. My preference is to have

as many participants as possible engaged with customers or

prospects before the design sprint starts to increase their

sense of belonging and purpose in the sprint.

Along with interviews you’ll want to collect and review any

qualitative and quantitative data that will provide valuable

insights to the sprint. This could be surveys and studies, or

data analysis from current product usage. I’ve found that

spending the time to draft user journeys and experience maps

before the design sprint also provides a solid foundation

for conversations on day one. These user journeys and

experience maps needn’t be comprehensive, as you’ll explore

them in detail as part of the Understand phase.

Less Is More

It’s the organizer’s responsibility to ensure all participants are

informed. However, too much research can easily overwhelm a

design-sprint team. If you create a research brief to distribute

before a sprint begins, keep it to no more than two pages (one

piece of paper front and back) with relevant data points for

research review.

When it comes to pre-sprint research, quality is more

important than quantity. For example, when we embarked

on a design sprint for Netapp, a Fortune 500 cloud-storage

enterprise, we discovered the persona research they were

referencing was four years old. The research predated several

of their products and clearly needed updating. This made us

aware that research hadn’t been a priority for a while and that

we’d need to dig a little deeper to get the useful information we

wanted. A bit of secondary research can also be helpful to set

the stage for participants without overloading them with too

much primary data.

Preparatory background research also includes some basic

competitive analysis. Are there already solutions out there?

Who has already succeeded or failed with this problem? My

favorite research trick is to call competitors pretending to be

a potential customer to hear how they pitch and price their

solutions. How a company positions their value is a window

into how well they understand their customers.

Nuts, Bolts, and Logistics
Image searches for the word “collaborate” invariably return

stock photos of fashionably dressed hipsters standing at a

Post-it note-covered whiteboard. The hipsters usually look

fake, but the Post-it notes and whiteboard are totally legit.

They’re part of the nuts and bolts that allow ideas to get out of

our heads and into the collaboration space.

Working closely with a group of people you may have just met

can be a big cognitive strain. Having the right environment,

tools and mood can mean the difference between healthy

collaboration and frustrating interaction. The little things go a

long way towards making a group feel comfortable. “I had one

participant who asked for salsa music on day two,” remembers

Jill Starett. “She danced in place while she sketched.”

Everybody Loves an Agenda

It doesn’t have to be detailed to the minute, but participants

like to have an agenda that gives them some sense of what

they’ll be up to each day.

I prefer to start early when people are fresh and caffeinated,

and then knock off a little early. Ending early gives me time as

the facilitator to answer the individual’s questions and prepare

for the next day. Whether you start earlier or later, try to keep

each day to no more than six hours of actual work. Focused,

creative work can be exhausting, so it needs to be paced.

Depending on the group size you may want to add a few breaks

for coffee and lunch. This gives participants time to catch up

on emails, make calls or check in with their teams.

I’ve noticed cultural preferences play a big part in how the

day is scheduled. In the U.S. it’s acceptable to have a working

lunch where participants grab a sandwich and continue to

push through the exercises. In Europe, a longer break for lunch

is expected. I personally prefer a longer break, as it allows

participants to disconnect for a while and recharge. The key is

to balance focused participation with time to rest, reflect a bit,

and communicate with the outside world.

As the facilitator or organizer, it’s your job to make participants

feel comfortable about the work ahead. Before the sprint, send

emails to the team with subject lines like: What to expect next

week, or Stay tuned: We’ll be sharing an agenda template soon.

Once underway, communicate the plans for each day upfront

and at various intervals throughout the day. Add reminders

of the schedule to the facilitator’s slide deck and hand out

copies of the agenda to everyone on arrival for Phase 1. This

will allow participants to plan phone calls, email or check-

ins, and to handle any family obligations with less stress.

Check the Appendix for templates to use in these helpful

communications.

Supplies you’ll need to be effective

The tasks of sketching, creating shared-lists, crafting

prototypes, and note-taking will require supplies. Below is a

recommended list:

• Post-it notes (a selection of colors and sizes is helpful)

• Sharpies

• Blank sheets of printer paper or heavy-stock printer paper

to prevent Sharpie leakage

• Whiteboard and whiteboard markers (the more colors the

better)
• Circle vote stickers (also called dot stickers)

• Easel pads or large pads of paper

• Craft paper or card (for prototypes)

• Adhesive tape

• Smartphone (for taking photos) or camera if you prefer

For groups considering larger interactive prototypes, add

cardboard boxes and packing tape. Of course, you’re not

limited to these suggestions. Feel free to use whatever you find

in your workspace. I’ve seen some pretty cool airport security

gate mockups made from old moving boxes, tablecloths and

conference room chairs.

We’ve made it easy for you and created an Amazon shopping

list for the supplies you’ll need. Feel free to customize your

choices.
Recruiting customers for interviews

The sooner you start the process of finding customers

to interview, the more successful the day-five interviews

will be. For B2B enterprise customers, recruiting can take

several days, so don’t wait until the last minute. If you

already have access to customers then contacting them and

communicating your requests for interviews will be as easy as

sending out emails or making phone calls.

If you’re testing a new product, you’ll need to recruit

prospective customers and this can be a little more

complicated. There are several ways to do this. I recommend

reading the guidelines provided by Steve Krug and by GV’s

research team.

Setting Up, Getting Comfortable and Feeling Safe

I like to say that a design sprint is really just a good excuse

to get people talking and bonding in a safe environment.

Everything you do leading up to, and during the sessions, will

have an influence on how participants think and behave. The

room, the preparation, the tone of communications and even

the dress code sends strong signals about what is expected of

the team.

As Daniel Coyle writes in his book The Culture Code, “Seen

through this lens, culture is not about soft stuff, it’s about

signaling. In other words, culture is not a set of traits, it’s a

signaling contest. Improve your signals, improve your culture.”

I encourage organizers of sprints to create strong signals of

creativity and psychological safety. Tell your team early and

often that this is a safe place to be creative without judgment.

Be hard on ideas, and soft on people.

C. Todd Lombardo

C. Todd Lombardo, Chief Product Officer of Vempathy, makes

non-judgment a core part of design sprints by creating “Rules

of our Design Sprint” at the start of day one. On a large sheet

of paper he writes the rules that will keep people feeling open

to sharing while scrutinizing the facts. His #1 rule is inevitably:

“Be hard on ideas, and soft on people.”

The Room
Physical space influences how we behave and interact. A big

room with plenty of whiteboards and natural light is the ideal

physical space for a design sprint. Cramped, windowless

environments will stifle creativity and can send the message

that the design sprint is low-priority. The room also needs a

place to pin or tape up sketches. If possible, try to secure a

location off-site and away from daily distractions.

Don’t overlook the environmental impact of too much

formality. Invite the team to wear casual clothes for the design

sprint and ask them to bring their favorite snacks. “How many

times have I heard participants say they should have worn

different shoes, because man, the design sprint keeps you on

your feet,” says Starett about the time spent at the whiteboard

sketching and debating.

For design sprints that fall on a holiday, ask participants to take

it a step further. “Our design sprint kicked off on Halloween,”

says eClinicalWorks project lead Raj Indupri. “Half of the

participants were in costume. Including one who dressed up

like a witch.”

Take pictures of the team working together and share them

with the group at the end of each day. Let participants take

their work home with them once it has been captured. I’ve seen
prototypes carefully packed away or carried out of a design

sprint by their proud creators. Bonding is inevitable when

people work closely together and participants often ask for

something to remember those collaborative moments.

“At the end of a design sprint the participants absolutely

couldn’t leave without having us all take a group picture as

a way to say, ‘Yes, we did it!,’” says Tim Lupo, senior product

manager at Fresh Tilled Soil. “That picture felt like the moment

when you leave summer camp after having made tons of new

friends who challenged you to do things you wouldn’t normally

do outside of camp.”

You also can get participants in the groove by incorporating

music into your exercises. Music keeps the energy up, gets

the creative juices flowing, and is a good mechanism for

crowd control. I use music at the start of the day to set the

mood, during heads-down design sessions and to combat the

inevitable post-lunch drowsiness. It’s certainly not necessary

to have music playing all the time. Here are a few of my favorite

Spotify playlists: electronic beats, soundtracks, and salsa.

Remote Design Sprints

Increasingly, design sprints are run with teams in several

locations, but I highly recommend in-person sessions

whenever possible. In fact, it’s often better to postpone a

design sprint until you can find a convenient time for everyone

to be together. However, if you can’t avoid it, there are some

creative options for remote sprints.

Remote sprints don’t mean you have to do every day remotely.

You can create a combination of on-site and off-site days that

suit the team’s schedules and location. If it’s possible to do at

least the first two days on-site, do that. It’s generally better to

do the early phase in person to maximize the opportunity for

chemistry and sharing ideas.

If you have to run a design sprint remotely, it’s best that all

participants be remote. Having half the team in one location

and the rest working remotely can create an us-versus-them

mindset. You can level the playing field and keep everyone

engaged by making the entire team remote.

If you go for a remote sprint, invest in a good multi-person

conference system that can support several people

continuously. You want to be certain everyone can talk, share,

draw, and prototype in ways that keep them engaged. Screen-

sharing and high-quality audio features are essential. Research

suggests audio quality is often considered more important

than video quality. Nevertheless, a good webcam is always

appreciated.

The activities of a design sprint form a natural rhythm of (1)

set clarity for activity goal and steps, (2) ideate individually, (3)

share and diverge at a group, (4) converge as a group. Remote

sprints can take advantage of this rhythm by allowing people

to disconnect for stage 2 in the cycle. They may not need to

do this for every activity, like crazy eights, but for some of the

longer activities, like storyboarding, it‘s a necessary and useful

reprieve to disconnect. Even if participants just mute and turn

off cameras, it helps relieve the fatigue associated with a day-

long conference call.

Capture everything from a remote sprint in whatever form

makes the most sense for your team. For example, you can

take photos of whiteboard sessions and sketches, use Google

docs for notes, and video for interviews. My team has used a

combination of Zoom (video conferencing), dedicated landlines

(audio), Slack (messaging), and Google slides and docs (notes

and visual asset capture) to run remote design sprints. We also

use Rev.com for audio transcriptions when necessary.

Further reading
Just Enough Research

How to run a remote design sprint without going crazy

The Culture Code by Daniel Coyle

Chapter—05

The Design
Sprint
Let’s Go

by Richard Banfield
With a few minor exceptions, there are five phases to every

design sprint. As mentioned in chapters 1 and 2, completing

all five phases in five days is the best approach to delivering

design-sprint value. In this chapter, I’ll explain the logic behind

each phase and why the exercises work best in this order:

01. Understand

02. Diverge

03. Converge

04. Build

05. Test
The 5 day design sprint process: Understand, Diverge, Converge,

Build, Test.

Phase One: Understand

PRO TIP — Recommended Schedule

Introductions, agenda creation, and roles – 20 mins

List assumptions and facts – 30 mins

Review background research and findings – 1-2 hours

Needs, Wants and Desires or Real Pain Points – 1 hour

User’s journey or Critical Path – 45 mins

Develop ‘Problem Statement’ – 45 mins

Retrospective – 15 mins

Overview
The first day of the design sprint is about reducing the noise of

assumptions and establishing a clear signal for why we should

be addressing this particular problem. The team will review the

background research, identify gaps in knowledge and expose

the riskiest assumptions.

Introductions, agenda review, and roles (20 mins)

My recommendation is for the facilitator to introduce team

members to one another well before the sprint starts. A video

conference works well for this, allowing everyone involved to

see who will be there and start getting comfortable together.

For larger organizations with distributed teams, it’s likely

people will be meeting each other face-to-face for the first

time on day one. So plan for a little extra time for socialization

and a round of quick introductions. Use name tags if

necessary.

It’s also a good idea to get everyone to share their concerns

from the start. Use the Hopes vs. Fears exercise to provide

an opportunity to get personal expectations out in the open.

Once this is done, the facilitator should assign roles and walk

everyone through the agenda.

List assumptions and facts (30 mins)

The first exercise of the day is to list the assumptions on a

whiteboard, or equivalent space that everyone can see. The

facilitator asks questions like: What do we assume about the

customer? What about the current buying experience do we

assume is working for the user? Are we sure that the customer

can articulate our product’s value? Have we asked customers

what they want?

The facilitator uses these questions as prompts for

conversation between team members, ensuring that everyone

has a chance to provide suggestions or questions of their own.

The assumption board will be referenced and updated

throughout the design sprint, so place it somewhere visible.

Next to each assumption write down how the assumption

can be tested, and what a validated or invalidated test result

would be. Although this process is done primarily during

the Understand phase, continue adding assumptions and

associated tests as the team discovers them over the course

of the sprint.

Assumption Test with… Validated if…

Customers want a Prototype and TBD

shorter checkout interview

process

Customers Interview TBD

understand the

value of this

feature
Enterprises can harbor institutional-level assumptions

that are based on years of habits and even successes. But

these assumptions can be extremely dangerous in today’s

rapidly changing business environments, especially if they’re

incorrect or founded on outdated information.

Review background research and findings (1-2

hours)

It’s important to collect, organize and distribute background

research several days before a design sprint starts. But it’s

difficult to ensure the team will review it before arriving. So

it’s best to go through the research on day one. For complex

problems, reviewing the research will take up a good part of

the day. But it must be done. Without background knowledge,

the team will be poorly equipped to work on the exercises that

follow.

PRO TIP — Park It

During the discussions on assumptions and research, the

teams will also generate ideas that may serve as future

solutions. At this stage, it’s important to stay focused on the

definition of the problem and not get distracted by potential

solutions. Instead of squashing any ideas for solutions, simply

add them to a Parking Lot or Back Burner board where ideas

can be recorded. These ideas often prove useful in the Diverge

and Converge phases.

The aim of the research review is to make sure the team has

a firm grasp on the business challenges, the customer’s

current expectations and the value proposition offered

by the business or product. This understanding will make

comparisons to competitive options more fact-based and less

likely to be influenced by opinion or presumption. (If there is no

product yet, and this design sprint is being used to discover

a new product opportunity, you might not have a clear value

proposition yet.)

Needs, Wants, and Desires or Real Pain Points (1

hour)

Identifying the needs of your customer is probably the most

important exercise of the day. Sorting between what the

user needs, versus what they want, will help the team better
understand the problem. For example, users may need to get

from location A to location B but, how they choose to do that

might be different from one another. One user may want to ride

a bicycle, while another wants to drive a luxury car. The need is

fulfilled in both instances but in very different ways.

User’s Journey or Critical Path (45 mins)

Plotting the user’s journey allows everyone to see where

the contact points are between customer and product. The

facilitator asks the participants to map the steps a customer

takes while interacting with a product. Each participant

contributes by adding, editing or clarifying activities like

“customer searches for lighting solution on shopping site”

or “company sends a notification to the user’s smartphone/

app.” By the end of the exercise, the finished product will

look much like a children’s treasure map. Loosely mapped

touchpoints with brief descriptions of what happens at each

point is enough fidelity. High fidelity illustrations won’t add any

additional value to this exercise. So just keep it simple.

I find this to be one of the most interesting exercises in the

design sprint. How a company visually describes the customer

journey explains a lot about the team’s understanding of the

customer’s needs. The more the team is aligned around how

the customer navigates the journey, the more understanding

they have of the problem. As a facilitator, if you notice a lot

of disagreement about the journey touchpoints, it’s worth

going back and discussing the assumptions driving those

interactions.

Develop ‘Problem Statement’ (45 mins)

Once the background research has been done and the needs

of the customer have been established, it’s important to figure

out what the problem is that needs solving. Identifying the

problem and writing it in statement format also doubles as a

vision of the future. Think of the customer problem and the

product vision being two sides of the same coin.

My advice is for each person on the team to write their own

version of the problem statement using the format below,

and then compare versions with the rest of the team. Having

discussed the variations as a group, the facilitator can then

write a final version on the whiteboard.

To create a problem statement, replace the words in

parentheses with your own vision of a solution:

PRO TIP — Create a Problem Statement

Today, when [customer segment] want to [desirable

activity/ outcome], they have to [current solution] . This is

unacceptable, because [shortcomings of current solutions].

We envision a world where [shortcomings resolved]. We are

bringing this world about through [high-level approach].

Clearly identifying the problem is important, so don’t be

afraid to rewrite this statement a few times or add a longer

explanation if it helps with understanding.

You’ll also notice the last two sentences of the statement

project what the outcome of a solution might be. It’s unlikely

you’ll have a clear solution in mind, so focus instead on the

outcome you’re seeking to create. For example, if we were

to use a rideshare transportation example, we might say:

“We envision a world where owning a car may no longer be a

liability. We’re bringing this world about through smartphone

access to a new kind of shared transportation solutions.”

As important as it is to determine if there is a problem, it is

just as important to understand if that problem is solvable and

whether it needs to be solved. The problem statement is the

first step to answering the question: What is this product, and

is it useful?

Retrospective (15-20 mins)

Before phase 1 is completed, it’s important for the team to

circle up and discuss the day’s work, and plan ahead for the

next day. I like to ask the team questions and look for alignment

on the answers. The questions are a summary of the day’s

work: Who is the ultimate user of the product or feature? Under

what conditions would a user engage with this product or

feature? What pain point do they have that will be addressed

by this product or feature? What triggers, internal motivations

or external pressures are involved in them using the product

or feature? What outcome does the user expect from the

encounter with the product or feature?

It’s possible that the answers to these questions won’t be

crystal clear to begin with, that’s okay. Discussing them and

aligning the team around what needs to be done in the phases

that follow is more important than concrete answers.

Phase Two: Diverge

PRO TIP — Recommended Schedule

Mind Mapping – 20 mins

Crazy Eights – 30-40 mins

How Might We – 30 mins

Storyboarding – 1 hours

Silent Critique – 1 hour

Group Critique – 45 mins

Retrospective – 15 mins

Overview

The goal of this phase is to generate possibilities. This follows

directly from the Understand phase, where our goal was to

understand the terrain and identify the problem worth solving.

For this phase to be effective I recommend having the same

mindset that improv actors embrace: build on the previous

person’s idea. Instead of judging ideas, we’ll find the best

solutions when we have an open mind and encourage crazy

ideas.
Mind Mapping (20 mins)

We start with mind mapping to warm up creativity and prepare

the group for the exercises that follow. This is an individual

exercise, so each person will do their own mind map. The

facilitator reads out the previous day’s Problem Statement and

then sets the timer for the group to write down ideas. Using

a blank sheet of paper the participants write down ideas that

might be solutions to the problem. Just like improv, by asking,

“yes, and…”, each idea will generate another idea. Participants

add each new idea to the previous idea with a connecting line.

The result will look resemble an alien spider, with connected

ideas radiating out from a starting point.

Crazy Eights (30-40 mins)

In a design sprint, we approach ideation in layers. The mind

mapping gets the creative ideas out of the participants’ heads,

and then the Crazy Eights and How Might We exercises allow

us to go deeper. The time limit allows participants to explore

ideas but deliberately doesn’t give them enough time to over-

analyze their solutions. The objective is to generate ideas, not

eliminate them because of judgments like, “Oh, that’ll never

work.”

To do the Crazy Eight exercise hand out blank paper and have

each participant fold the paper in half, then half again. This

will create eight panels (front and back) on the sheet of paper.

Give each person eight minutes to sketch eight different

solutions, about one minute for each. Quick and dirty sketches

are perfect. Once everyone is done, repeat the exercise.

Repetition reinforces the “yes, and…” mindset and pushes

participants to come up with new ideas that they may have

never considered in the first round.

How Might We (30 mins)

How Might We is an innovation exercise used by Google,

Facebook, Procter & Gamble, and design studio IDEO. The

question, “How might we?” is another extension of the improv

idea and pushes participants to think about how they could

bring their solutions to life. To execute this exercise ask

participants to write answers to the question as it relates to

each of their solutions. For example, “How might we hail a taxi

using a person’s GPS location?” Answers should be a short

sentence or a sketched. Tim Brown, CEO of IDEO, says the How

Might We technique works best with ideas that are ambitious,

yet also achievable. Brown says it doesn’t work as well with

problems that are too broad.

Storyboarding (30 mins)

The storyboarding exercise is designed to take the ideas

generated by Crazy Eights and expanded by the How Might

We questions, and develop them further. Each participant

starts with a blank sheet and adds three Post-it notes down

the side of the page. They should choose the most promising

solutions to storyboard. Each Post-it note is one frame in

the storyboard. The top note represents the current state of

the customer; the second note is how the customer would

experience the new solution; and the bottom note shows

the outcome created by the new experience. Think of this

as a storyboard for a short film. Each note should be used to

draw the action. Use the space on the paper to the side of the

Post-it to write a brief explanation. Each frame should be self-

explanatory. If a participant needs to explain what’s going on in

a frame, ask them to redraw the action. Once everyone is done,

hang the storyboards up in the shared space.

Silent Critique (30-40 mins)

Once the ideation exercises are complete, the group will

shift gears from non-judgemental creativity to individual

critique. The purpose of doing this silently is so all voices get

expressed, not just the senior leaders or influencers. Make

sure all the storyboards are displayed on the wall, provide each

person with several colored stickers (dot stickers) and ask

participants to vote for the ideas they like best. Each person

can use his or her entire allotment of stickers on one idea

or distribute them in whatever way they see fit, even voting

for their own ideas. The result will look a little like a series of

heatmaps. The higher density dots indicate the most popular

ideas.

Group Critique (45 mins)

Don’t do a group critique until the silent critique is complete.

The group critique is exactly that, a chance for the entire team

to discuss the ideas on the storyboards. The facilitator will

gather everyone around each storyboard and ask them what

they like about it. It’s essential that everyone gets to share

what they like about each idea. The emphasis should be on the
positives. In the next phase, participants will have a chance

to think about the negatives. Note takers will capture this

qualitative feedback.

Retrospective (15-20 mins)

This activity will be essentially the same each day–circle up,

discuss the day’s work, and plan ahead for the next day.

Phase Three: Converge

PRO TIP — Recommended Schedule

Identify Conflicts (20-30 mins)

Review Assumptions (10 mins)

Review Back Burner Board (10 mins)

Whiteboard the Final Storyboard (1-2 hours)

Retrospective (15-20 mins)

Overview

The purpose of the Converge phase is to reduce the potential

solutions to a single version that will be tested. To make

this convergence possible, the facilitator needs to ensure

the assumptions identified in the Understand phase are

being considered. Only the idea that addresses the riskiest

assumptions and is aligned with the Problem Statement should

move to testing. Converging is hard work. The team will be

responsible for choosing some ideas over others. This means

making tough decisions, so let participants know in advance to

be prepared to let go of some favorites.

Identify Conflicts (20-30 mins)

The entire group will be involved in this exercise as they seek

to identify storyboards that are so similar that they can be

merged. Approaches that conflict shine light on what choices

there are in solving the problem. Talk through the different

approaches and decide which is the best to continue with.

Review Assumptions (10 mins)

As mentioned, the alignment between a potential solution and

the original assumptions is important. During each phase, the

facilitator should remind the team of the assumptions. Gather

the group around the assumptions board created on day one

and discuss how the selected storyboard will address the

assumptions. If the assumptions tests need to be adjusted or

changed, do that now.

Assumption Test with… Validated if…

Customers want a Prototype and Customers

shorter checkout interview choose the

process prototype over the

current checkout

process

Customers Interview Customer can

understand the clearly articulate

value of this the value without

feature prompting
Review Parking Lot or Back Burner Board (10 mins)

If ideas were created in the Diverge stage that should be

preserved, add them to the Parking Lot or Back Burner

board. Record the best ideas and then move on. Don’t get too

distracted by these sideline ideas.

Sketching (30-40 mins)

Once the reviews are complete, the teams will start with three

quick rounds of sketching. Once participants have selected

a single storyboard/idea to pursue from the Diverge phase,

individuals must sketch out what the solution might be and

then share it with 1-2 other people for feedback.

These small teams must then make tradeoffs to combine

their solutions into one. Small teams repeat the process one

more time by sharing solutions across the broader team and

creating a single version of the solution. By stepping this out

into a multi-pronged approach participants are less likely to be

overwhelmed by a single big decision. It also gives them a way

to clearly articulate the reasons behind the design decisions

they made earlier in the day.

Sketches from design sprint credit: Addi Hou.

Whiteboard the Final Storyboard (1-2 hours)

The final storyboard exercise is really important because it

forms the foundation of the build and tests. The facilitator can

lead this exercise by dividing the group into different roles.

Some people will sketch while others rewrite the descriptions

in detail. Don’t focus on design details, that will be the focus of

the next phase.

The storyboard should be created in a way that the entire team

can see it. The whiteboard is ideal. I’ve seen some cases where
the facilitator does all the sketching at the whiteboard while

the other members provide inputs. I don’t recommend this

approach because it allows participants to sit back and watch

the facilitator do most of the work.

Storyboarding with sticky notes. Credit Tim Höfer.

Retrospective (15-20 mins)

Phase Four: Build (Prototype)

PRO TIP — Recommended Schedule

Create prototypes (as long as it takes)

Overview

In enterprise environments, I prefer calling this phase “Build”

rather than “Prototype.” The reason is not all solutions will be

prototypes in the traditional sense. Some of the solutions I’ve

participated in have been things like sales scripts or service

interaction models. “Build” is a more inclusive term that’s less

intimidating for non-designers. However, if you’re reading

this book, there’s a good chance you’ll be designing digital

solutions, and in that case, “Prototype” should work just fine.

During this phase, the primary activity is going to be designing

and creating something that can be tested. If the group

includes designers then use these skilled people to create

the screens, pages or features you’ll be testing. If you have

developers on the team you can also create HTML/CSS

prototypes that will live on the web. The additional fidelity and

interaction of a coded prototype means you’ll have a smoother

user experience, but it’s not required.

If you don’t have developers on your design-sprint team, don’t

panic. Paper prototypes are generally enough fidelity for

testing your assumptions. The advantage of paper prototypes

is they can be created quickly, inexpensively, and changes are

often as simple as redrawing a screen.

Invision is made for prototyping and is my go-to tool for this

exercise. Using the templates in InVision, even non-designers

can create workflows using design outputs from applications

like Sketch, Keynote or Photoshop. Even images from a

smartphone camera can serve as the screens or pages of the

app or website you’re designing.

Phase Five: Test

PRO TIP — Recommended Schedule

Interviews

Final Retrospective
Overview

The final phase of the design sprint is to test the original

assumptions, validate or invalidate the problem statement, and

extract knowledge about customer’s preferences. The output

will be the insights collected from customer or prospective-

customer interviews.

While design sprints are structured to generate more

qualitative than quantitative insights, both are still considered

important. In the Understand phase, when we are formulating

our problem statement we’re reviewing or collecting insights

by discovering the problems customers are thinking about. In

the Test phase, we want to validate (or invalidate) the problem

statement. We do this by conducting just enough interviews

that we can gather whether that problem is real or just

someone’s perception.

The collective facts obtained from these interviews will enable

you to make decisions based on objective observations. To do

this you’ll need to recruit 7-12 potential users and give them

access to the prototype. Specifics of recruiting and testing are

discussed in the sections below.

Recruiting for Interviews

Bringing the users into the picture is often the most exciting

part of the design sprint. Users are the fairy dust that you

get to sprinkle on the design sprint because their feedback

brings your prototypes to life. Once users start interacting

with your prototypes you’ll get the answers you were seeking.

The fundamental research questions or problem statements

you need to answer will tell you who you need to engage in the

interviews. Douglas Ferguson suggests asking the following

questions: Are you looking for a new or existing user? Are they

people who fit your sprint target? Whom should we exclude?

On the other hand, the design sprint’s short time schedule

means you will need to start recruit candidates before you

even start the sprint. Recruiting interview candidates will be

different for each design sprint so I encourage you to plan

ahead. Recruiting several users in just a few days can also be

challenging and stressful. Without preparation, a team might

find they have scheduled interviews with the wrong people. In

a recent design sprint that was conducted to find solutions for

LendingTree customers with low credit scores, the sprint team

discovered that all the recruits had very high credit scores. As

Ferguson cautions, “Be super careful that you are talking to the

right people; take the time to prepare a proper screener.”

I’m not a fan of recruiting potential customers using Craig’s

List and the promise of $100 for their time. This approach

attracts candidates who are more interested in earning $100

than they are in giving you feedback on a problem they care

about.

Interviews (a few hours to an entire day)

The Interview

Each team will have specific roles during the interview process.

You’ll need at a minimum, one person to conduct the interview

and one person to take notes, or be the observer.

Don’t expect good results if the interviewer is also expected

to take notes. It’s difficult for an interviewer to be truly present

if they are also trying to be a good notetaker. An interviewer

should be focused on the interviewee and asking the right

questions, while the notetaker will be taking objective notes

about what they hear and see.

If you have a larger team you can create multiple interviewer

and observer teams. Assign roles the day before during the

Build phase so team members can prepare for what they need

to do. The interviewer will prepare questions. Author and

researcher, Steve Krug has created an extremely thorough list

of scripts and suggested questions for interviewers.

The Remote Interview

I recommend you do all user interviews in real-time and,

wherever possible, in person. However, when a remote

interview is necessary, a video conference with screen-

share functionality is best. This will allow the interviewer and

notetaker to see the facial expressions and body language of

the user.

Video conference tech also allows the interview team to

record the conversation and review it again with the broader

team. If an extended team or stakeholders will be joining

via video conference, it’s necessary that they remain quiet

and objective, and not interrupt the interviewer. Keep all

feedback until the end when the user has left the room or video

conference.
Don’t Coach Your Candidates

As excited as you might be about your potential solutions, be

careful not to sell your ideas to the interview candidates. It’s

more important to get a neutral candidate than someone that

is going to support your idea. You are not selling or pitching

them anything.

It’s also important that you don’t coach them towards an

answer you’re hoping to hear. If a user is struggling, don’t jump

to their rescue and tell them what to do. Rather say something

like, “It looks like you’re still thinking about the step, can you

tell me what’s on your mind?”

This Isn’t An Exam

Take your time to make the interview candidates feel

comfortable. Interviewees can often feel like they’re being

tested or graded so explain to them that their honest feedback

is the best feedback. There are no right or wrong answers, only

their unfiltered responses are needed.

This works in reverse too. Interviewers may believe an answer

is wrong because of their own personal perspectives or

biases. If you’re the facilitator, remind interviewers that they

must be mindful of their tone of voice, facial expressions,

and responses to feedback. Turning up your nose at a user’s

response, because you don’t agree, sends a strong message

that you don’t approve.

Negative Feedback is Often The Best Feedback

Rejecting feedback, because it wasn’t what you expected or

desired, isn’t going to help uncover answers. Remember, a

design sprint is a process for generating understanding. If a

user is struggling through a flow or says negative things about

the solution, that’s new information you can use to improve

your work.

Instead of defending your solution to the user or redirecting

them along a path you’re interested in, ask questions like,

“Tell me more about that?” or “I’d love to know what you’re

feeling?” Steve Krug has once again provided an excellent list

of questions that an interviewer can ask.

Reviewing the Interview Sessions

Your recollections will be freshest immediately after an

interview. However, it’s also common for memories—even

fresh ones—to be filtered or obscured in some fashion.

That’s why it’s so important to review notes, video, audio and

observers comments to fill in the perceptual blanks to which

we’re all prone and gain a broader perspective on the interview.

Consider, too, that the more interviews you do, the more likely

your brain will filter the memories in order of last-to-first. The

most recent interviews will be clearer than the interviews

conducted earlier in the day. This is called the and happens

when we overestimate the likelihood of something happening

because a similar event has either happened recently or

because we feel very emotional about a previous similar event.

This can easily be overcome by reviewing interview notes and

video.

Final Retrospective (15-30 mins)

PRO TIP — Find the Problem Before the Solution

Customers rarely describe the solution to problems, but they

are the best source for finding out what the problem is, and

how important it is to them.

Setting the Mind to the Phase

“As I saw the evolution of sprints, and then I

started hearing the stories of what sprints had
done for those teams…I started realizing this is
way bigger than what happens in the sprint.”

Marta Rey Babarro — GOOGLE

Jenny Gove, Kai Haley, and Marta Rey Babarro from Google talk about

the evolution of sprints and how they have impacted teams across

Google.

Each phase’s name describes what the team will be doing, but

it doesn’t describe how participants should think. Below is a

list of character roles that will help you and your team bring the

right mindset to each phase of the design sprint.

• Understand – think like a scientist

• Diverge – think like an artist

• Converge – think like a detective

• Build (or prototype) – think like an architect

• Test – think like a journalist

Thinking like a detective

Think of your team as a group of forensic experts sifting

through the clues looking for evidence. The question you

need to answer in the Understand phase is: “What’s going on

here?” Seen through the lens of the customer, this might sound

like: “Here’s a problem I would love to have a solution for.” In

this phase, it’s important to stay away from questions and

conversations about how a solution might be delivered or what

form it might take. We’re not concerned with that at this stage.

It’s first important to know whether there is a case that needs

solving.

Thinking like an artist

Your customers probably don’t know what the solution should

be, or that they even need it. All they know is they have a

problem or a pain that they are currently putting up with. As a

result, the customer is a great resource for understanding the

problem, but not for trying to find the solution.

When you move to the Diverge stage, you’ll switch from an

analytical mindset to a creative mindset. Your goal will be to

create as many possible solutions as time allows. Embracing a

sense of openness and a lack of judgment will help you get into

the right frame of mind.

Thinking like a scientist

Converging on the best idea, or ideas, requires the puzzle-

solving mentality of a scientist. During the previous phase,

the team will have developed lots of possible solutions. The

team will be piecing together the elements that work while

discarding the ideas that don’t support our problem space.

Don’t be afraid to put ideas aside if they don’t fit the best

profile. Your Parking Lot or Burner Board is for capturing these

ideas that may be worth exploring in a future design sprint or

discovery activity.

Thinking like an architect

Having done the necessary detective work, your best idea will

now have made it to the Build phase. As is often the case with

building projects, we start by influencing its design, but then its

mere existence has the effect of influencing how we behave.

This is exactly what happens when we start architecting our

prototypes. Our initial ideas become refined and improved

when we see the product, service or ideas in action. This is

sometimes described as “thinking by doing.”

Thinking like a journalist

If “thinking by doing” describes the architect’s mindset, then

the journalist mindset might be described as “thinking by

questioning.” Approach the problem as if you will be expected

to provide sources, evidence, and a clear storyline. Think

through the who, what, when, where, why and how the mantra

of journalism. Consider questions like: How did we get to this

point? Who is this about and who does it appeal to? Why were

those people the target of this story? What makes them and

this subject so interesting?

Further reading
Creating a Discovery Platform for Continuous Change

Everybody Lies: Big Data, New Data, and What the Internet Can

Tell Us About Who We Really Are

Chapter—06

Beyond the Five-

Phases
How’d you place?

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 and 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’s going to

mean your team can’t be there. Doing something is better than

not doing anything at all.

“One of the ways I’ve found to enable people

to really participate in sprints is to…explain how
sprints accelerate development time.”
Jenny Gove — GOOGLE

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 the 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 f 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

Switching Exercises

Swapping out a few of the activities in the course of a design

sprint is common practice. Depending on your goals and what

research you already have, switching out exercises 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 completely ignore the problem statement,

but it might get less time allotted to 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 better 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 what are the necessary

research inputs that we need for each of the design’s frontiers,

says 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.

“As a part of the preparation for the sprint, we

want to make sure that all the [participants]
have the right context and understanding for
the problem.”

Laine Henry — NORTHWESTERN MUTUAL

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 towards

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 was that small changes could

be made to the product that would serve less sophisticated

customers and prospects without sacrificing functionality for

the more sophisticated user base.

Industry: Bio-Pharmaceutical

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 a few months

ago. If you read the Lego article, 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 as them.”

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.
Further reading
How The Home Depot is Scaling Design Sprints to Drive

Design Transformation (Slideshare)

How The Home Depot is Scaling Design Sprints to Drive

Design Transformation (Medium)

How Lego Run’s Design Sprint’s at Scale

Chapter—07

Appendix
The cool down

by Richard Banfield
Templates
While you could certainly create your own assets to plan and

run your design sprints, these templates will make your work

much easier. Modify them to fit your needs.

• This Trello template will help facilitators and note takers

get organized

• Gemma Petrie of Mozilla has created a series of very useful

Keynote decks that act almost as a script for each day of

your design sprint.

• The Home Depot design sprint training manual

Discovery Needs Assessment (DNA)

If you are unsure of whether a design sprint is right for you one

of my recommendations is to meet with the stakeholders or

potential design sprint team or group to discuss the purpose

of the design sprint and establish where the knowledge gaps

might be. The answers to these questions will provide you with
specific areas to address and highlight any concerns.

Here are some questions you can use to guide that discussion:

• Why are you interested in a design sprint?

• What is the problem or area you are hoping to address and

why?

• What do you know about the problem and users impacted?

• Have you completed or created any of the following:

• Primary user research – interviews, surveys, focus groups,

etc.

• Personas

• User journey mapping

• Market analysis

• Is this for a new or existing product?

• Do you have a solution in mind?

• How confident are you that you’ve identified the right

solution?

• What is the impact if your solution fails?

• What are your desired outcomes and how will these move

the needle for you?

• How does this initiative align with your current business/

product strategy?

• How familiar are you and your team with the design sprint

process?
• If anyone participated in a design sprint, what role did they

play?

• Who will be joining the sprint from your team?

• Will they be able to dedicate a week to the sprint, or will we

need to spread out the time?

• Will everyone be participating for the full sprint?

• Is it clear who the facilitator of the design sprint will be?

• Where would you like to host the design sprint?

• Can you describe this meeting space?

• Does the meeting space have whiteboards? Projector?

Individual and group breakout spaces?

• Finally, what question should we have asked but didn’t?