“We wanted to make the best for the most for the least”
– Charles Eames

When was the last time you choose the harder, more expensive approach to solve a problem? 

That’s the reason behind why the adoption of the Design Sprint practice has been skyrocketing worldwide. But before backing up that claim, let me set the stage with some foundation for the reader that is unfamiliar with the term Design Sprint.

What is a Design Sprint?

Think of a challenge the business you are in may be facing. If you can’t think of a real one, just play along and pretend you have one. Now, what if you could work together with customers, employees, and partners to fix, improve, or even completely transform that situation?

What if I told you all of this—from discovery to solution—could be accomplished very cheaply in a timeline as short as one week? Sound too good to be true? 

Well, that’s the power of a Design Sprint.

A Design Sprint allows a product development team to use Design Thinking to map users and stakeholders’ needs and work along with them to create and test solutions with real users in only a couple of days. Now I’m sounding a lot like those “as seen on TV” ads, but wait, there’s more: everything can be done with an extremely low, near zero budget.

All of this make Design Sprints a low cost / high added value “gig” no product developer can afford to be unfamiliar with.

How it Works

There are many approaches to Design Sprints, but the overall flow of a Design Sprint follows this structure:

Kick-off

This is where Sprint Masters gather the team, analyze previous known materials, work on user recruitment, and scope the challenge definition.

User Research

Some approaches rely more heavily on human-centered research than others and may differ on what types of users the sprinting team is more interested in having conversations with. This is a crucial stage to inform the team on how to create relevant offers that solve real problems and address real needs.

Idea Generation

This is where the Sprint master and the sprinting team get together with end users, specialists, and other important stakeholders to generate ideas and refine concepts.

Prototyping

Prototypes are a lot of fun. This stage is where the sprinting team tests the newly created concepts with end-users and gathers valuable feedback.

Adjust & Iterate

Sometimes during a sprint the sprinting team may have the opportunity to make adjustments to their prototypes and run a second prototyping session.

Like I said before, there are many approaches you can learn from when it comes to Design Sprints. In this article, I will talk about two: The Google Ventures model and the MVS model.

The Google Ventures Model

The Google Ventures model was published by Jake Knapp in his book “SPRINT – How to Solve Big Problems and Test New Ideas in Just Five Days” (2016). The GV model, as we will be calling it from now on, inherits most of its techniques from Design Thinking. Although the book was launched in 2016, the GV model’s most known sprint “The Blue Bottle Case” took place around 2013. Since then, the Google Ventures team has been sprinting with numerous startups and companies. You can read many of those case stories here. 

Day 1

The team defines the challenge, makes a map, defines target customers, and talks to experts from inside and outside the team.

Day 2

Starts with a benchmark research on great solutions for the team to get inspired on, use it, remix, and improve. The team then defines a “How Might We” question (don’t worry about this right now, we’ll cover it extensively later). Finally, the team moves into idea generation mode.

Day 3

The team decides on the best solutions and moves on to create a storyboard.

Day 4

Using the storyboard as a foundation, the team will build a realistic prototype and do a trial run.

Day 5

Test the prototype with users, watch and learn from them.

Pros: Inherits tools from Design Thinking. Easier to recruit users since user sessions take place only on the last day. Great if you have high-quality raw input coming into the sprint and are able to put together a very diverse and creative team.

Cons: Very little exploratory research. No co-creation with users, which may silence serendipity by turning off the gathering of user insights and user generated ideas at early stages. The team builds first and learns from users later.

The Minimum Valuable Service – MVS Model

The MVS, Minimum Valuable Service, model is an open source framework based on Service Design. 

I kick-started the MVS in 2014 with the release of my book, “The Service Startup :: Design Thinking gets Lean”. Since then, the model has been evolving in collaboration with the global sprintmaster.co community, universities, and people using the model worldwide. You can read many of those case stories here.

Day 1

This is where the team maps the ecosystem of the challenge and refines their understandings about who the interesting stakeholders might be.

Day 2

A day of fast paced ethnographic dives and deep interviews to uncover how people learn, use, and remember their relationship with the challenge.

Day Off

This is for the team to process the user interviews and recruit targeted users.

Day 3

This is where the team gathers with users to co-create concepts with end-users and all relevant stakeholders.

Day 4

This is where the team tests the concepts with users.

Pros: Inherits from Service Design which makes it more tailored for service offers. Intense exploratory rounds including co-creation and user research help create variation and produce a diverse pool of raw insights even when you don’t have a diverse team.

Cons: Because of the amount of exploratory research involved, it may be a challenge to recruit users so quickly. You may end up with less than ideal users.

Deciding which Approach to Use

It’s less related to the “super-powers” each methodology may carry (like people used to think) and more related to the resources you may have at hand before the sprint starts. Recently we’ve answered the same question during a practice feedback session we held at the Design Sprint School. 

Here is the thread:

When to Run a Design Sprint

Usually, a Design Sprint works better in situations where the challenge can generate a real outcome:

– Co-develop with a new partner.

– Improve the checkout process of our website.

– Create a new product.

– Improve our product to beat the competition.

– Test a solution we have for relevance and adjust if needed.

Warning: Sprints are Messy WYSIWYG Animals

It is imperative that the sprint master and the sprinting team set up the mood and expectations with the client correctly. 

Design Sprints are intense and messy, and there is no cover layer to shield the sprinting team from the client’s view. There is no shelter to retreat to and surprise the client with “a-ha” moments. What you see is what you get in a Design Sprint.
People will get happy, sad, frustrated, irritated, happy, and sad again all in one day, all in the same room. The work is collaborative, and the client is designing as well. 

Many sprints flop because people leading them fail to communicate, clarify, and align these characteristics and end up in a room with stakeholders that want to be impressed and served by the design sprint team.

It’s been a while since we got into the battle of proving Design Thinking as a relevant asset to businesses anywhere. In it, Core77 has been instrumental in helping educate the world on the value of the Design practice and how it can really create a monster positive impact to the business bottom line. 

But what I see happening with Design Sprint is different. 

First, It takes a millisecond for any product developer to realize the value of it. The value of a fast-paced design-infused hackathon with customers and employees. It’s really a no-brainer—no further explanation needed.

Second, it’s fast and cheap. So people jump on it with a more open “what do I have to lose” mindset. This ultimately means they carry less pressure on their shoulders, which helps innovation thrive. A one-hour brainstorming in the right cultural environment, with the right creative mood, has the potential to generate ideas that dozens of meetings in the wrong cultural environment will never be able to. 

It’s been great to see Design Thinking and Service Design helping companies and initiatives that before would never sign up for it. From high-tech industries and their machine learning new adventures to NGOs fighting Dengue mosquitos, HIV or helping Syrian Refugees.

Design Sprints are the future of Design Thinking and Service Design. Why? Because of its “why not?” nature: 

– Low risk, low resources? let’s give it a try.

During its mere four years of existence, design sprint adoption levels have been growing exponentially fast. This becomes even more evident when we compare it to the adoption levels of Design Thinking and Service Design during the same period. It also helps the fact that Google has been spreading the word about the approach, and applying it to every startup they are backing. 

Good news: This may be the mass adoption of Design Thinking designers always wanted to see. 

Bad news:  To the despair of many, including design firms and the Academy, Design Sprints are also teachable. They can be easily learned by anyone and are more about street smart than academic training. Because of that, in very the end, they may contribute to disintegrate once and for all the idea of Design Thinking and Service Design as siloed disciplines and specialized practices, freeing its skills, methods, and practices to emerge as an ingenious yet ubiquitous new design practice.

About time. 

Source: core77