Design Sprint

Applied regularly at Google, Airbnb, McKinsey and LEGO, the Design Sprint allows you to solve any design problem. During the sprint, you take a small team, clear their schedules for a week, and rapidly progress from problem to tested solution. In only 5 days, it accelerates and simplifies the design process of a digital product.

Browse through this page to understand better:

• what the design sprint methodology is
• why it makes sense for your business to apply this methodology
• what happens during a design sprint
• in what situations design sprints work best
• what you cannot use design sprints for
• read a specific case study on how we run design sprints
• how to prepare for design sprints and what can go wrong
• what happens if you hire UX studio to run a design sprint for you

What is a Google design sprint?

Most companies are stuck within old-fashioned office behaviors: endless arguing at meetings, decision churn, extroverts dominating brainstorming sessions, bad roadmaps. It all results in wasted months or years.

The Design Sprint, developed by Jake Knapp, Braden Kowitz and John Zeratsky at Google Ventures, is a five-day process for answering critical business questions through design, rapid design prototyping, and testing ideas.

What is the outcome of a design sprint?

By running a design sprint, you get a concrete and measurable outcome in just 5 days, thanks to user validation built into the process.

By getting from problem to solution without running errands, and time spent with unuseful development, you’ll be able to convince investors faster, reduce risks, avoid developing unnecessary features, and maximize your ROI.

• To reduce risk.
• To minimize time wasted on meetings and fruitless brainstorms
• To align cross-functional team collaboration through co-creation in a very compressed time-frame.
• To give structure to a collaborative design process.
• To act as fuel for the product design process by giving it an initial direction.

What are the advantages of a product design sprint?

• It shortcuts months of debate and development, saving you money and time.
• It sets clear boundaries and a sense of urgency that helps the team really put the goals in focus.
• It’s a flexible framework that you can experiment with, and apply it to many different types of problems.
• It requires your cross-functional team to work together in a structured way – this builds bridges and sets a foundation for better and more synced future collaboration.
• It allows for creativity but it doesn’t require it – the process naturally brings it out of people.
• It builds upon spatial memory (everyone will remember the “sprint war room”).

What does a sprint look like? – The 5-day design sprint process

On Monday, we map the problem, based on expert inputs from the client. On Tuesday, we sketch possible solutions together. On Wednesday, we decide on the strongest solution.

On Thursday, we build a realistic prototype.

The client is actively involved in the first days of the sprint. Day 4 is devoted to Prototyping and can be performed remotely. On Day 5, we test the prototype: we invite users to test our prototype and take advantage of their feedback to assess the potential of your product. We seek to answer all strategic questions through design prototyping.

The process

Monday – Define

• Goal: defining product/service goal, proposition or features (positioning, user journey, metrics)
• Key outcomes: long-term goal, sprint questions, user journey map, experts interviews findings, target – sprint focus

Tuesday – Diverge:

• Goal: creating individual solutions to the original design challenge
• Key outcomes: lightning demos, solution sketches

Wednesday – Decide:

• Goal: the deliberates on the possible solutions, then narrows it down to the optimal one, in order to come up with a solid storyboard
• Key outcomes: voted solutions, storyboard

Thursday – Prototype:

• Goal: creating a tangible prototype (wireframe, mockups, video, etc.) that it triggers reactions rather than just feedback.
• Key outcomes: prototype

Friday – Validate:

• Goal: Capture reactions from target customers and discover patterns with which we can determine whether our hypotheses and assumptions are true
• Key outcomes: user interviews results

Who should participate in the design sprint?

In short: the more diverse team the better, but not more than 7-8 people.

At the bare minimum, decision-makers should be present, plus a facilitator that doesn’t participate in the decision-making. The point is that all stakeholders are represented so that they can give input and be part of the decision-making process.

We should create a balanced mix of expertise in business, human and technical areas. A typical assortment of participants include:

• Finance (CFO, CEO)
• Marketing (CMO, Community Manager, Content Manager)
• Customer Support (Sales, Research)
• Tech (CTO, Engineers)
• Design (Design Lead, UX Lead, Interaction and Experience Designers)
• + additional experts (on Monday)

Some helping questions:

• ‣ Who is responsible for the project?
• ‣ Who sponsors changes, new initiatives and has decision-making power?
• ‣ Who knows about the history of the project and previous efforts?
• ‣ Who represents the voice of the customer/user?
• ‣ Who builds it? Maintains it?

Why do you need a design sprint facilitator and what do they do?

Why don’t all companies just read the book and run sprints all the time? Because a successful sprint works much better if the person(s) who facilitate(s) it is impartial outside experts.

Among other things, the sprint facilitator (sprint master):

• Knows the process inside and out
• Manages group dynamics
• Empower each team member to bring their contribution
• Manages time and facilitates the process
• Documents the progress and outcomes

When the design sprint is a good answer (typical scenarios):

We’re often asked if we can get results quicker by running a design sprint. Why spend months on a long product design process when 5 days is enough?

The GV design sprint is a tool for a very specific situation:

• You have a big project or big problem to solve
• You’re just starting out
• You don’t have the answer
• It’s going to cost a lot of time or money

Typically good design sprint objectives:

• Assessing the viability of an idea or business model
• Discovering the right priorities and features for a product
• Ideating on or redesigning a specific area of a product
• Jumpstarting a project
• Creating a roadmap for an MVP
• Finding ways to engage new audiences

Let’s look at a concrete example!

Redesigning a JIRA e-mail handler during a Design Sprint (Case Study)

The client:

We recently ran a design sprint for Meta Inf, an IT company specializing in the Atlassian ecosystem.

The product:

They were working on an automatized email-handler solution that synchronizes and sorts incoming support request emails with Jira. Out of all our possible design sprint examples, this one describes simplest how we do sprints here at UX studio.

The issue:

User feedback indicated that the rules page of the mail-handler was hard to use. Users had difficulties programming the rules that set email automatization in motion, which resulted in high support need. The team felt that they needed a quick UX boost to kickstart the redesign process.

The team:

The sprint team included product, development and marketing professionals from Meta Inf’s side. At our UX agency, UX studio, we work in pairs, so we had one UX designer and one UX researcher facilitating the sprint together.

What Meta Inf’s design sprint looked like

Day 1 – Understand:

The first day was about sharing prior technical and user knowledge about the product, discussing business goals, assumptions, and fears. Then, we created a user journey together.

The objective for the sprint week: to rethink the user flows and interface of the mail-handler add-on. The team was hoping that by the end of the sprint, they would have a high-fidelity prototype that can be sent to development.

Day 2 – Diverge:

Based on Monday’s inputs and a quick competitor analysis, we ideated together about the possible solutions for the rule-setting tool. Then, at the end of the day, during some structured design sprint workshops, we already picked the winning sketches.

Day 3 – Decision:

Based on the winning ideas, we drew a storyboard to have a clear overview of the user flow and different scenarios. This day, we already started prototyping in Marvel.

Day 4 – Prototype:

With the help of the UX team, this day was all about prototyping and preparing for Thursday’s tests. By the end of the day, the interview script was ready, and a trial user test was run.

Day 5 – Validate:

The first part of the day was about testing the prototype during several user interviews run by our UX researcher. Then, in the afternoon, we analyzed the findings together, modified the prototype accordingly, and after defining the next steps together, the project was handed over to Meta Inf.

The final outcome of the project: not a finished product but a completely re-thought process in a high-fidelity prototype, ready for final design and going into development.

Design sprint facilitation process

In 5 days, we will follow the world’s most innovative companies, step by step, and lay the foundations of your future strategy or product. All this will take place in an open and creative atmosphere.

As stated above, the design sprint methodology has been developed by UX experts at Google Ventures (described in detail in the Sprint Book). Our methodology is based on theirs. Every sprint we run is different and completely tailored to your needs.

1. Our experts will assess whether your challenge is suited to be solved with the design sprint methodology.
2. Two UX-ers (a designer and a researcher) will be appointed to facilitate the sprint for you.
3. We will have a pre-kickoff: you will describe the challenge and the stakeholders involved in it.
4. We run the sprint: we will spend 5 days together, during which we will get from problem to solution, backed by customer research insights.
5. We will summarize the results, and define the next steps.

When a design sprint isn’t the answer

• All aspects of a complex service need to be covered.
• You want to explore multiple use cases and hypotheses.
• You can’t articulate the problem you are trying to solve.
• The project requires significant prior research.
• You already know what the solution is or what to build.
• There is no clear plan or support to execute the sprint outcomes.
• You are looking for just small improvements to your product or service.
• The team does not want to invest personally in the creative process

Sprints are not a replacement of standard UX processes. Use sprints to answer big questions and set/validate a direction. Design Sprints are not sufficient by themselves but when they are integrated with other processes in the organization.

Why not simply do a group brainstorm? — The 4 big fixes of the sprint

There are four major problems with group brainstorms. When I designed the sprint process, I built in steps to address each one.

Shallow ideas from the group

In a group brainstorm, the goal is quantity, assuming that something great might come out of it in the end. During a sprint, there are fewer solutions but each one is opinionated, detailed, and highly suited for the problem.

Personality outshines content

Charismatic extroverts tend to dominate the whole discussion, outshining everyone else’s possibly great inputs. During a design sprint, ideas don’t wear the creator’s name on them: they are anonymous until after everyone else has given their opinions.

Opinionated decisions

Thanks to the encouraging, positive environment of a group brainstorm, teams often lead talk themselves into shallow or half-solutions. During the design sprint, decisions are made by one person: the Decider (a CEO, executive, product manager, or other leaders).

A prototype and data, every time

Instead of a pile of sticky notes , the sprint process requires your team to build an actual prototype and test it. This helps the team in clarfying what to do next.

Test yourself!

To check whether your project/product would benefit from a design sprint or not, here are the 5 main questions you should consider:

1. Is it a specific problem that needs a solution?
2. Is this problem complex with no obvious solution?
3. Does the problem require a cross-functional team to solve your problem?
4. Is the problem worth investing 5 days into?
5. Do you need full-on innovation for a changing or a new market?

If you have answered yes to most of the 5 questions, you might benefit from a design sprint at this point.

Let’s kickstart your project with a design sprint together!