What is a Design Sprint?
This article is part 1 in a series on Design Sprints.
The Design Sprint Framework
Do you find that ideation is a matter of consensus building or debating everything down to one idea? Do you often feel that the idea could have been taken further or that alternatives were never explored at all? Do you feel like the endless debate around the idea severely eats into the time to build the actual solution for launch?
In comes the Design Sprint, developed at Google for product thinkers. This is not agile scrum or other agile production & project management methods. This is not the “Lean Startup” approach. This is not “Design Thinking”. It is a combination of all of these methods, targeted at the earliest stages before you have an idea. It is for makers, and guides conceiving of that new product or service and protects against bad ideas getting to far down the path. Market/idea validation is only days away, whether you are going to a consumer or internal executives.
In case you’re thinking well I don’t have a product or services here are two quick definitions for our purpose:
- A “product” is something tangible that you use
- A “service” is something intangible that you do
Going Fast!
Imagine if you could work through questions like “Should we build this service?” or “What are the key elements to deliver value?” in days instead of weeks or months. Many companies are already doing that today with both big picture and detailed problems. The design sprint is a five-day process for answering critical business questions through design, prototyping, and testing ideas with “customers”. Going fast comes with risks of artificially creating tunnel vision and general opportunity costs for what is missed. Design sprints build in a strong sense of purpose first and then structure “wide vs. narrow” thinking by ensuring multiple ideas are generated.
Who and How Long?
Beyond problem definition, the questions of time and resources required play a critical role. The actual number of days isn’t important, what is important is that this way is comprehensive and fast! By manufacturing deadlines it creates time box structure to get things done! Getting the right people in the room and remembering that there are usually more “right people” than you think. You want a broad cross-section of individuals, rather than just a senior management team or “the usual group” of people. What about outsiders? What about people from the production team? These are interesting idea that could bring about the success required to solve the problem at hand.
Cutting the debate
The Design Sprint process shortcuts the usual endless debate cycle and multiple stakeholder reviews. It also shortcuts the process of building the actual product and than having to start over, massively redesigning or incorporating feedback at that late stage. In short, it can compress months of time into as little as 1 week! This 5 day process that uses design thinking to reduce the risk of successfully bringing solutions to market and should be incorporated into all facets of serious problem solving and product/service design. This process ensures alignment and accountability with the business goals and wise investment of time, effort and money.
This process was invented at Google and today is used through the main company and their venture capital wing, Google Ventures. It has been very successful both inside and outside of Google and really brought together a lot of product thinking into a tangible process for the first time.
Not your regular “agile”
As you learn more about Design Sprints you may notice similarities to traditional scrum/agile thinking. This process does borrow some of the good elements but is fundamentally different by maintaining a focus on ideation and exploration of those ideas.
Empathy. Creativity. Rationality.
Understand (Context) → Diverge (Ideate/Generate) → Decide (Converge/Short list) → Prototype (Make) → Validate (Test & Learn)
More on these steps in the next post.
The time frame itself is not rigid and should adapt to the problem at hand. That said, the time should be boxed upfront and the sprint held accountable to the timelines. Schedule it ahead of time starting with the validation. Get everything into calendar and don’t forget the facilitator!
“Before embarking on a design spring, make sure the players involved come to a common understanding” -Jake Knapp, Google Ventures
Always start at the beginning
Chances are everyone is coming to the table with a different view of the problems itself. Some may have been living with it daily, others not at all. Everyone’s background will create different perspective. It is important to start with a clear vision of problem, what the finish line could look like and where everything is today. This understanding will provide the objectives and constraints which focus the problem solving throughout the exercise. By everyone sharing in the beginning these new perspectives help to put everyone in a beginner’s mindset. Constantly ask “Why?”
Don’t just have one idea
How Might We? → Diverge! Dust off your old ideas. Put ideas on an even footing. Keep ideation quick and light. Don’t get attached to ideas. Generate lots! Constantly ask “How might we?”
- Problem statement (from the understand phase)
- How might we considerations?
- Concept map / mind map
- Idea sketching (Crazy 8’s)
- Storyboard
Iteration: Individual Critiques → Short Group Critiques → Vote
Not design by committee
Decide! Combat groupthink and decisions in a room full of people being driven by one individual. Best shot or battle royal? List your assumptions to compare options. Complete the storyboard(s) and/or journey map. Keep the gloves off, battle royale is not an excuse to avoid difficult decisions but to truly discover differences between alternative solutions.
Mock it up
To get ready for feedback you need to build something high fidelity, as quickly as possible. This is where prototyping comes in; you’re not building a finished product. It is too late and therefore too costly to wait until you have a “real” product/service to get critical feedback. Make it minimally real. Use paper or a drawing program like Sketch, Keynote or PowerPoint. Build a template library to make the task easier as you get more Design Sprints under your belt. Divide and conquer among the team and just like at the earlier stages of the work, use timers! A simple process for iteration: Do short group critiques, consisting of both silent individual and collective group discussion → followed by outsider critique (if necessary).
Get feedback right away!
Demo your idea, before you go all in → Validate!
Getting excited about the potential of Design Sprints? Hopefully this was a good introduction to they “what” and “why’s” behind the method. The next post will get into the “how”.