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 organizations. This includes training the Google Sprint Academy in San Francisco as well as partnering with InVision to teach Design Sprints. 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 sprint 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 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 realized 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 among 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 to achieve. 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”.

Let's also remember that design sprints originated at Google Ventures, a fund supporting innovative founders predominantly in startup environments. However, Google itself is a large enterprise operating in a realm where challenges become more intricate, value propositions require deeper exploration, teams often work in silos, and numerous stakeholders with diverse business goals are involved. The context simply cannot be overlooked, and that's precisely why Problem Framing is invaluable in this space. In fact, we were not surprised when Google invited us to train their internal Design Sprint Academy on Problem Framing in 2018.

Although five days seem like a short time, it requires a significant investment for most organizations 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 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 on board 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.

2. Sprint Duration. 4 days instead of 5 days.

One of the pushbacks to Design Sprints by management and teams is the time commitment. Reducing the program by even one day proved very valuable to our clients. We did this without removing any exercises or compromising 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 identify 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.

Ideation hack: before jumping into ideation, we warm up the team with an EVIL 8’s exercise based on reverse thinking in order to reduce the pressure to perform and stimulate bolder, more courageous ideas.

After lunch, we spent about 1.5 hours reviewing the solutions — Art Museum (30 minutes), discussing them — Speed Critique ( 45 minutes), and deciding 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 two 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, plan the next steps.

3. Exercise & process improvements

Sprint Goal and Questions

Think of these as the 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 jeopardize 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 and 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 be 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 with 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 upfront 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, e.g., 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 struggles to cluster them at the end of the first day.

In 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 lightning 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 organizations 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 the core since the first day, not just during the last day of testing.

Furthermore, for all organizations 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 our Design Sprint 3.0 an ideal candidate for all organizations which want to implement a human-centered approach to problem-solving and innovation.