To get the best results in 4 days
WHAT IS A DESIGN SPRINT?
The Design Sprint is a proven methodology for solving problems through designing, prototyping, and testing ideas with users. Design Sprints quickly align teams under a shared vision with clearly defined goals and deliverables. Ultimately, it is a tool for developing a hypothesis, prototyping an idea, and testing it rapidly with as little investment as possible in as real an environment as possible.
DESIGN SPRINT GOALS
This Design Sprint Kit aims to share this flexible model created for internal Google teams, while also acting as a methods repository for the design and product development community. It includes a range of different approaches to driving clear outcomes for a team, and we look forward to seeing this collection grow over time.
ORIGINAL DESIGN 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.
UPDATED DESIGN SPRINT 3.0
The main difference is that in v3.0 all the activities are happening during 4 days cycle (instead of 5 days). Technically, in the Second Day both activities (Sketch and Decide) are going together, which is a huge benefit for the whole team: usually, it's hard to get the full DS team working on a 3 day's workshop, and with v3.0 we need only 2 full days of the team capacity, while 2 last days only designers are working to Prototype and Test the idea.
HOW TO DRIVE A DESIGN SPRINT WORKSHOP
Design Sprints can generate remarkable output for your company — such as a backlog of impactful ideas, functional prototypes, learning and key insights from customers along with real business opportunities.
To get real value from a Design Sprint, you must emphasise on the right setup, preparation, and readiness — or you may end up hosting an expensive multi-day brainstorming session outputting just noise.
1. Define the problem statement
Don’t let the problem statement become your real problem! Most of the unsuccessful Design Sprints and prototyping sessions I have experienced so far, share this specific single point of failure: a poorly defined problem statement, which triggers time-consuming discussions, iterations, and unnecessary regression — setting the entire process at risk.
2. Set up the right team
The synthesis of the team sets the foundation for the entire Design Sprint — you need diversity of thought, skills, and perspectives along with expertise and creativeness — all combined in a small multidisciplinary team with the right culture: a team willing to share, collaborate, challenge assumptions, think big but also be pragmatic and purpose-driven.
The wrong dynamics in the team (for instance, members do not express their ideas for fear of getting criticised by more senior members in the team)
a large team (add more than 6–7 people and you’ll get additional problems to solve)
or the wrong mindset (people tend to protect ideas versus sharing, or believe that they know the right solution, upfront).
3. Make sure the team is well-prepared
Design Sprints are demanding — fast and intense. The key to success is to have a well-prepared team. Even if your dream team consists of domain experts and senior business leaders, they all have to put some extra effort to get prepared — so they fully understand the problem and its wider context, the technology, the competition, and the relevant global trends. Make sure that you clearly communicate to the team not only the context and the problem to be solved but also the rules and the need to get prepared.
4. Focus on ideation
Assuming that a solid problem statement and the right preparation is there, the next most important element is ideation. While the Design Sprint process provides some tools to empower ideation, I would strongly recommend that you:
increase the time allocated to idea generation, sketching and pitching and
capture the ideas in digital format — with more detailed descriptions.
5. Get ready for ‘rapid prototyping’
Delivering realistic prototypes is a critical part of this process — since they will be used to capture user/ customer feedback. You don’t want your great concept to receive negative feedback due to a poor prototype implementation — that could mislead related decisions and undermine the overall value of the Design Sprint. Your team must be capable of real rapid prototyping — able to build realistic user experiences in just a couple of days or less.
6. Find a great Facilitator
This is a key role — in fact, I see the facilitator as the real protagonist of the Design Sprint. The facilitator must maintain the right pace, direction, energy levels, and interaction patterns, to lead the team towards a clear, shared goal: define and prototype a great, novel concept solving the problem for real users.
7. Capture everything
Design Sprints are typically very ‘noisy’ with tons of sticky notes, ideas, and stories on the walls — all these, in-between discussions, arguments, decisions, and random thoughts. And yes, this ‘controlled chaos’ is exciting, but unless you have a dedicated person responsible for taking (digital) notes, you will end up frustrated, trying to decode colourful sticky notes and ‘reverse-engineer’ random drawings.
8. Find a Leader, not just a ‘decider’
I find the proposed decision-making process — with the super-voting concept and the sticky votes on the sketches — oversimplified and very sensitive to team dynamics and the overall state of the team. Moreover, given the extra power, the decider must demonstrate a deep understanding of the concepts, the ability to think strategically and communicate with clarity. You need a real leader there, not an ‘authority’ or ‘political’ person.
9. Measure Success
A design sprint is an expensive process — consider the associated direct and indirect costs of having x members full-time for z days. Thus, measuring the success of the Design Sprint itself is important. In the case of an ‘isolated’ sprint, success can be measured by processing direct feedback, outputs and mid-term outcomes — for example business opportunities and success stories linked with the deliverables of the Sprint.
MAIN PHASES OF THE DESIGN SPRINT
Phase 0: Problem Framing
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.
DAY 1
Phase 1: Understand
Develop a common understanding of the working context including the problem, the business, the customer, the value proposition, and how success will be determined. By the end of this phase, we also aim to have identified some of our most significant risks and started to make plans for reducing them.
Several 'Understand' Methods:
How Might We
Lightning Talk
Experience Mapping
User Interviews
Empathy Building Exercises
User Journey Mapping
Importance/Difficulty Matrix
Visualise the Vote
Job/User Stories
Phase 2: Define
In the Define phase, the team evaluates everything they learned in the Understand phase to establish focus. This is done by defining the specific context and desired outcomes of potential solutions. The phase concludes by choosing a specific focus for your Sprint, as well as goals, success metrics, and signals.
Several 'Define' methods:
Success Metrics & Signals
Business Model Canvas
Define Design Principle
The Golden Path
Future Press Release
Pick a target
Personality Sliders
Assumptions Mapping
DAY 2
Phase 3: Sketch
In the Sketch phase, the Design Sprint team generates and shares a broad range of ideas as individuals. You will start by looking for inspiration, such as solutions in alternative spaces. Then, each Design Sprint participant will individually generate ideas for consideration. From there, the team will narrow down ideas as group to a single, well-articulated Solution Sketch per person.
Several 'Sketch' methods:
The Warm Up: Comparable Problem
Boot Up Note Taking
Crazy 8's
Crazy 8's Sharing and Voting
Solution Sketch
Phase 4: Decide
In the Decide phase, the Design Sprint team finalises the direction or concept to be prototyped. Each participant will share their Solution Sketch, and the team will find consensus on a single idea through decision-making exercises. The final direction will aim to address the Design Sprint focus.
Several 'Decide' Methods:
Present Solution Sketch
Assumptions and Sprint Questions
Dot Vote
Decision Matrix
Heat-map Voting
Note and Vote
Rumble or All-In-One
Day 3
Phase 5: Prototype
In the Prototype phase, the Design Sprint team will work together to create a prototype of your concept. This is when many decisions are made around what exactly the concept is and includes. You will aim to create a prototype that is just real enough to validate, and you will do it really fast!
In the context of Design Sprint, we use the word “prototype” in a slightly different way than in standard product development. A Design Sprint prototype is a facade of the experience you have envisioned in the Sketch phase. You are building just what you need to make the prototype real enough to get an authentic response from a potential user in the Validate phase. This means mapping out the exact flow for the experience and only building the steps you want to test. There is no need to build a full functional back-end or to solve for every flow in your product.
You can think of your prototype as an experiment in order to test out a hypothesis. This means you have to think critically about what you will build in order to get the feedback you need to validate or invalidate your hypothesis. Anything can be prototyped in a day if it is clearly mapped out.
Several 'Prototype' methods:
Storyboard
Assign Tasks
Create a Kanban Board
Narrate the storyboard
Instant collaboration using G Docs/Miro
Prototyping with Figma
Prototype playback in Figma Prototype
Day 4
Phase 6: Validate
In the Validate phase, the Design Sprint team will put your concept in front of users - this is your moment of truth! You will gather feedback from users who interact with your prototype, and if relevant, you will conduct stakeholder and technical feasibility reviews. You’ll end your Sprint with a validated concept– or an invalidated concept to improve on. Either way, you’ve made progress.
Several 'Validate' methods:
Stakeholder Review
Technical Review
Recruit Interview Subjects
Plan the interview
Master the interview
Score the Interview
Sprint Conclusion: Recap and Next Steps
DESIGN SPRINT RESULTS
If we are running successive Design Sprints, we'll need a framework to capture and quantify Sprint outputs and impact — a flow towards a centralised idea and knowledge repository. This data store should enable full tracking of the real business opportunities and financial gains associated with each of your Design Sprints — while specialised KPIs allow tracking the success of the overall innovation program.
The key question, in this case, is regarding the baseline to compare this ‘quantified innovation output’ against — to be covered in a forthcoming article.
Design Sprints can generate remarkable output for your company — such as a backlog of impactful ideas (also with IP opportunities), functional prototypes, learnings and key insights from customers along with real business opportunities. At the same time, assuming proper and frequent execution, Design Sprints can lead to significant cultural improvements towards the ‘innovation mode’.
Comments