Design Sprint 3.0

Introduction

You have probably read about, heard of, been in or even run a Design Sprint. Since the Google Ventures Sprint book came out in 2016, Design Sprints have become widely adopted globally by companies as a tool for innovation and problem-solving and one of the most hyped processes around.

Our journey with Design Sprints started even before the book, the Design Sprint Academy has run sprints all over the world with every kind of company, from startups to large organisations. This includes training Google in San Francisco as well as partnering with InVision to teach Design Sprints as part of their Design Better Workshops series, alongside the likes of Jake Knapp (formally of Google Ventures) and Richard Banfield (Fresh Tilled Soil).

Our extensive experience has enabled us to re-engineer the program to create the first and one of the most comprehensive Design Sprint training programs out there. We call this improved version the Design Sprint 3.0.

Design Sprint 3.0 vs The Original Design Sprint

The original Design Sprint program is a 5-stage process that runs over the course of 5-days to solve big problems and answer critical business questions, through design, prototyping and testing with customers or users.

The original process

With a small team and a clear schedule for the week, you will rapidly progress from a problem to a tested solution.

• Monday the team creates a map of the problem.
• Tuesday, the team individually sketches potential solutions.
• Wednesday, the team decides which of these solutions are the strongest.
• Thursday the team builds a realistic prototype to test.
• Friday, the team tests the prototype to validate assumptions with 5 target customers.

The updated Design Sprint 3.0 process

The Design Sprint Academy has re-engineered the Design Sprint program to effectively establish the problem before the sprint, reduce the duration of the program from 5 to 4 days, as well as refining a number of the core activities to help the team successfully progress through the program.

1. Problem Framing before running the sprint

This is a preliminary step that we have created to ensure effective outcomes from a Design Sprint. We designed this as a response to being in Sprints where we realised our clients did not know what the problem was, or if it even existed. Or alternatively, the problems we were tackling were too broad to allow a practical solution or too narrow to be worth the investment.

We find that this is a common issue amongst practitioners. Due to the hype and the promise companies are jumping on the Design Sprint ‘train’ before clarifying the problem or establishing what they intend on achieving. Trusting the process will only get you so far! As Erika Hall author of Just Enough Research says “Testing a prototype can help you refine an idea that is already good, not tell you whether you’re solving the right problem”.

Although 5 days seem like a short time, it requires a significant investment for most organisations as 7 to 10 key people are blocked during this period, doing nothing else. That is why it becomes critical to pick the right problem to solve to make this investment worthwhile.

Problem Framing is a half to a full-day workshop that involves the main stakeholders, typically exec. level (including the eventual nominated Design Sprint ‘Decider’). The outcomes of this workshop include:

• A defined Design Sprint challenge by looking at the entire context of the business/product/ service strategy and linking it to overarching business goals/metrics and actual customer problems
• Establishing the Sprint Team. Once the problem has been defined, you know what experts to bring onboard when it is time to Sprint.
• Get stakeholder buy-in and alignment. Since the challenge is connected to business objectives the stakeholders are directly accountable for, their support to run the Sprint is assured and, more, they will be interested in seeing the results implemented post-sprint.

Learn more about Problem Framing by reading our series on Medium or by watching this video and this video.

2. Duration. 4 days instead of 5 days.

One of the pushbacks to Design Sprints by management and teams is the time commitment. By reducing the program by even one day proved very valuable to our clients. We did this without removing any exercises or compromising on the quality of the program.

So how did we do it?

Day 1 — Monday

The Problem Framing session before the Sprint allows us to start with a well-defined problem and with the best possible team excited about solving it, rather than being anxious about what they will have to face. However, there is still plenty of uncertainty around what the solution might be or the best approach. That is why it is essential that the Sprint Team (which most of the time is different than the one in the Framing) takes the time to understand the problem, context and all available information and insights.

While we kept all of the exercises in the book, there are a few changes we have made.

We structured the morning discussions leading to the Sprint Goal into an activity called Lightning Talks, where the team shares their points of view on the problem at hand and reviews the Design Sprint Brief.

However, by far, one of the most important additions we have made was building empathy with the user and embedding pre-sprint research insights during the mapping session.

Lastly, we also made HMW a standalone activity (in the book it is part of Ask the Experts).

By the end of the first day, the team will have a clear focus and identified the area of the challenge where a solution would make the most impact.

Time hack: at the end of the day give the team as homework the research for the Lightning Demos.

Day 2 — Tuesday

In the original process, half of Tuesday is reserved for Lightning Demos. By assigning Lightning Demos research as homework on Monday we can jump straight to the presentations, thus, cutting the required time from 3 hours to 30–45 minutes.

We will use the rest of the morning, until lunch, approx. 2 hours for the Solution Sketch. Besides time savings, another (quite significant) gain is that people get to sketch with a fresh mind (it’s still morning) and because they just got inspired after the demos the solutions tend to be more creative.

After lunch, we spend about 1.5 hours to review the solutions — Art Museum (30 minutes), discuss them — Speed Critique ( 45 minutes) and decide which we prototype — Vote (15 minutes).

The rest of Tuesday afternoon, a solid 1.5 hours, will be dedicated to storyboarding. You might argue this is too little time, especially considering storyboarding is one of the most challenging parts of the Sprint, but in reality, we have consistently experienced the same outcomes as when we followed the process as instructed by the book. Most likely because of the time constraint forces people to argue less.

This is how we have gained one day! As we have already mentioned, time can be very precious, especially for senior management. Most of the critical decision making in the Sprint is conducted during these 2 days, so that’s how long you need most senior folk in the Sprint. However, our advice is to keep the team together for the entire duration of the Sprint.

Day 3 — Wednesday

The heated discussions from Tuesday’s storyboarding session are now a thing of the past, and with a clear head, the team reviews and refines the storyboard (if needed) while at the same time assigning roles and planning prototyping work (1 hour tops). We encourage everyone in the group to assume a role and get their hands dirty (yes, that includes any senior executives in the room). Besides team bonding, the team will develop a shared sense of ownership which will help to carry over the results (as opposed to a prototype a designer or agency built).

Day 4 — Thursday

Moment of truth. Thursday is about user testing, asking the most effective questions. Make sure that after each interview, the team takes the time to review and make sense of the feedback, and then at the end of the day plans next steps.

3. Exercise & process improvements

Sprint Goal and Questions

Think of these as North Star of the sprint. They drive all solutions and decisions during the week, so needless to say they can make or break the sprint. That’s why the team tends to engage in endless discussions trying to figure out what would make a good Sprint Goal and Sprint Questions. This is not an ideal scenario for a facilitator.

Initially, we looked at the Note and Vote as a solution to cut down time and discussions to select the Sprint Goal and Sprint Questions. However, there are a few drawbacks to this. People whose sticky notes have fewer votes tend to become disengaged. This could jeopardise the dynamic of the team. Also cutting discussions to zero will result in a loss of substance and depth to the Sprint Goal and Sprint Questions, but also to a lack of ownership from the team.

In Design Sprint 3.0 we start both exercises with a Note & Vote, however, we do not stop there and follow each activity with a “debate” where the team combines the best parts of each individual idea. This approach ensures that all nuances are captured, that the best possible questions are asked (for example during the debate a new question might come up that one individual would not have thought of herself). When used in this way, the Note and Vote is not a decision-making tool, but rather guidance for discussions. That allows everyone to contribute, feel included and aligned with each other as a team.

Map

This is an area where we have made quite a drastic change. To us, a Map is a tool for empathy, a tool for helping the team align on the current reality of the user/customer. So it needs to be grounded in reality, not solely the team’s assumptions. That’s why we are aiming to prepare as much as possible of the map up front using research data or any significant information that can be provided after the Problem Framing workshop. We have moved from a simple diagram (although occasionally we might still do that) to a more complex representation including, research insights, touchpoints, business data etc. We call this exercise “Map to Map”.

“Mapping Experiences” by Jim Kalbach provided great inspiration (while Jim also contributed to our Design Sprint Facilitation Guide, explaining how to build a sprint map).

In the sprint, you will be working with stakeholders (not just designers, or researchers) who have no idea about how to build a customer journey map. Getting them to create a map may cause a lot of issues due to gaps in knowledge. Your goal as a facilitator is to get the team to understand the context, identify pain points and opportunities and make decisions. That’s where their strength is and why they are part of the Sprint team.

How Might We (HMW)

We dedicated an activity to creating HMW statements. We made this decision for a number of reasons. People are not used to taking ‘live notes’ as HMWs. In most cases we’d end up with automatic translations from a statement to an HMW question eg. your sales expert says “We do not have enough sales”, the team typically transcribes this as “How might we increase sales?” This would not be helpful for the team later on during the solution stage.

The team also typically ends up with way too many HMWs; anywhere from 50 to 200 sticky notes with minimal variation. Realistically, a lot of them will be glossed over if not ignored, when a tired team will struggle to cluster them at the end of the first day.

In the Design Sprint 3.0, the team has a dedicated time period to generate HMWs, using not only the notes from the Expert Interviews but also the notes taken throughout the day (during the lighting talks, mapping and research insights) as inspiration. By incorporating more reference points and allowing the time to reflect the team is able to generate a great variety of creative, unique and insightful HMWs. This will ultimately have a better chance of inspiring more innovative solutions.

Wrapping Up

From the onset, the Design Sprint has been a great fit for startups. While this still holds true for Design Sprint 3.0, now the process is an equally good fit for enterprise organisations and corporates.

Why? The Design Sprint 3.0 is further connected to business goals & stakeholders through a defined Problem Framing process, it allows for the optimal use of the resources (when to run a sprint, with what team) and it has the user at core since the first day, not just during the last day of testing.

Furthermore, for all organisations comparing Design Sprints to Design Thinking, Design Sprints 3.0 could be the answer as it takes the best from both worlds: looking at the entire context, clear problem definition and user empathy (from Design Thinking), speed, focus and a well-defined step by step process (from Design Sprints). At the same time, it removes the disadvantages of both processes: the complexity of Design Thinking and undetermined project duration and lack of problem definition and user empathy/research in Design Sprints.

All of these make Design Sprint 3.0 an ideal candidate for all organisations which want to implement a human-centred approach to problem-solving and innovation.

A special thanks to Dana Vetan and Dan Levy for their help with editing and contribution to this article.

Get in touch with other Design Sprint practitioners by joining our Design Sprint Masters Facebook group or the Design Sprint Group on Linkedin.

Learn more about Design Sprint 3.0 by joining one of our workshops offered worldwide by Design Sprint Academy and our global network of partners: More Space for Light (Australia), QGLUE (India), Libeo (Canada) and LeLaptop (France).