What is a design sprint?
Maximize your chances of making something people actually want by reading the first chapter from Design Sprint.
Maximize your chances of making something people actually want by reading the first chapter from Design Sprint.
A design sprint is a flexible product design framework that serves to maximize the chances of making something people want. It is an intense effort conducted by a small team where the results will set the direction for a product or service.
A design sprint consists of five discrete phases:
A design sprint reduces the risk of downstream mistakes and generates vision-led goals the team can use to measure its success. For the purposes of this book, we’ll focus on digital products, as our direct experience lies in that arena, though the design sprint has roots in gaming and architecture,1 and many industries have employed them successfully.
There are many ways to utilize a design sprint; one way is to look at which stage of development the project is in. Are you at the beginning and need to understand a wide array of unknowns? Or are you looking at a mature product that has been on the market for a while?
You might use a design sprint to initiate a change in process or start the innovation of a product concept. This works well when you’re exploring opportunities with the goal of coming up with original concepts that ultimately will be tested in the real world—for example, if we need to understand how young parents would buy healthcare products online.
You might use a design sprint to start a new cycle of updates, expanding on an existing concept or exploring new ways to use an existing product. For example, we worked with a marketing data company that realized the data it gathered might be useful to other market segments. Building a prototype gave the team the validation it needed and prompted a deeper investment into that product segment, which ultimately was rewarded with a significant increase in sales.
A design sprint can also be used to test a single feature or subcomponent of a product. This allows you to focus on a particular aspect of the design. For example, your team might need to know what improvements can be made to the onboarding process. Using the design sprint to discover the pros and cons of a new onboarding channel could give you granular insights into a high-return part of the product experience.
However you use it, the design sprint brings clarity to your road map to kickstart and obtain initial validation for almost any new, product design–related work.
The design sprint evolved from a number of different approaches to design. As Agile and design thinking became more popular, design sprints became a way to encapsulate them.
The word sprint comes from the world of Agile, and it describes a short period of time, typically 1–4 weeks, set aside to accomplish a focused goal. The design sprint is no different. It uses the original concept of the sprint to describe a period of time dedicated to working on the necessary design thinking. This time-bounded paradigm is critical to the success of the design sprint. Timeboxing, as it’s sometimes called, is essential to driving the right types of behavior from the participants. In addition to speeding up the product design and development process, it also takes advantage of core parts of our human nature: energy economy and social collaboration.
Going way back, the term charrette was used to describe any collaborative workshop session among designers, and design-thinking frameworks from Stanford’s d.school emerged as a way to apply more structure to this concept. Industrial product design firms like IDEO developed short-cycle design sessions called deep dives, which built on the design charrette concept popularized by Stanford’s d.school.
IDEO’s most famous example is the Shopping Cart Concept, a deep dive that was featured on Nightline in 1999.2 The team pushed back on age-old mythologies about how design gets done and brought a multidisciplinary team together to brainstorm, research, prototype, and obtain user feedback that went from idea to a working model in four days. By collapsing the time constraints, the designers were essentially holding a gun to their heads and forcing themselves to come up with better solutions in less time.
The influence of industrial design and software design was the genesis, but it was the emergence of digital product design that brought on a more formal framework for testing ideas out in the wild. Several organizations started to converge upon similar processes with similarly named phases.
Although there have been company-specific versions of this approach used over the last decade, it was the work of Jake Knapp at Google Ventures (GV) that brought them to a broader audience.
GV invests in startups, and at times those startups require product design advice to align their teams. To help with this, GV would send a designer to work with each startup for one week’s time. As it turns out, these processes have five phases, one for each day of that week. The structure and time constraint proved useful. Lo and behold, the design sprint was born.
Startups are notoriously fast-moving environments that value speed to market over almost everything else. This commitment to speed gives them an advantage but also risks leaving out a lot of the essential thinking and testing required to build a truly useful product. Too many products go to market without customer validation. How do you maintain the speed while including the necessary research and design thinking? Many startups in the Constant Contact InnoLoft Program cite a design sprint as one of the most valuable parts of their participation.
Enterprises that have well-established processes may also look to a design sprint as a way to accelerate their product design and development so that they can work more like a fast-moving startup. The accelerated learning can give the enterprise an advantage and also reduce the amount of resource investments for exploration of product ideas and concepts. Spending three to five days on a project idea to see if it makes sense to move forward is better than working three to five months, only to discover it would have been better to not have proceeded at all.
Any product or product feature will be validated or invalidated. You can do that validation yourself, or let the market do it. Which do you think will be less expensive?
A design sprint’s success can be measured in many ways. What works for metrics in your organization may differ from others. Here are a few ways we have seen design sprints measured.
You can’t change what you can’t measure, right? One of the biggest questions we initially faced when implementing design sprints in our organizations was “How do you measure the success of a design sprint?” In our experience, it was often the absence of something that we were trying to measure. For example, how do you measure the amount of time you won’t spend on bad product development? How much money will you save by not investing in a product that will make less ROI? Those questions point toward future gains by not spending some difficult-to-calculate amount of time or money. How do you measure the absence of a failed product?
There’s no way you’re not going to save yourself time and money. Because the way these deals usually work is to go out and build things and just invest thousands of dollars and all this time, and then, find out that it falls flat. There is no testing done, no exploration done with end users,” remarked Dana Mitrof-Silvers, a design-thinking consultant who works with many nonprofits, such as the Indianapolis Museum of Art and the Denver Museum of Nature and Science. She measures the success of a design sprint by the ideas generated. “While ideas aren’t usually the problem, most organizations find themselves with an excess of ideas—validated ideas and the execution is what’s missing.
In many cases, a design sprint will lead you to something that gets initial user validation, where the next steps are defined. You’ll have reduced risk by doing some validation early, and developed next steps faster than would have otherwise been possible. Character Lab3 had a design sprint like this with thoughtbot. In a week, a large group of diverse stakeholders from an educational nonprofit got on the same page about what would be built, and remarked upon how quickly they reached agreement. Teachers and students were excited about the prototype they saw and couldn’t wait to use it. What we needed to build was clear and could proceed unimpeded at a good clip, which was very much needed given the size of the app and its shoestring, nonprofit budget.
Sometimes issues come to light that need some clear changes in your product, and you can fix those things and plan additional research. For example, thoughtbot did a design sprint for Tile4 to optimize the team’s mobile app design to help users find keys with a device attached. After the sprint, we iterated based on what we learned and continued additional research sessions. In those following weeks, we found that making the device beep louder helped users find keys three times faster than anything else.
Design sprints can help prevent you from building the wrong thing even when your customers say it’s the right thing. Larissa Levine, from the Advisory Board Company, believes that a design sprint is successful if it guides you toward building the right product feature. As she explains, “Product marketing wants to sell this one feature and says, ‘let’s build XYZ because we heard that the user said they wanted XYZ,’ when actually, that’s not the problem at all. They think they want XYZ, but it’s not it at all. So you end up building the wrong thing.”
Sometimes a design sprint can get rid of those preconceived notions. Michael Webb, cofounder of InnoLoft startup resident itsgr82bme, entered a design sprint with a clear idea in his head about using APIs as a means for connecting its calendar of family-friendly events with other sites’ event listings. During the sprint, he realized this could be done without using any APIs at all. He ended the sprint in a very different place.
Lastly, a design sprint can stop you from building any product at all. Marc Guy, CEO of Faze1, also went through a design sprint at the InnoLoft. The sprint made him realize his company needed to stop building a product and instead go out and talk to customers. Mind blown, product invalidated! The business model has shifted significantly since then, as it subsequently focused on customer development. In fact, C. Todd didn’t see Marc or his team in the InnoLoft much after their design sprint. They were all out talking to customers, even their development team! The results were impressive and yielded an 8x increase in booked revenue over their previous year.
Each design sprint will have its own needs and idiosyncrasies, and you’ll have to determine up front what’s best for your project. Any good design-thinking process might help identify the real problem in each of these cases. What makes the design sprint approach more effective is the structured, time-constrained framework, along with the appropriate exercises. This will force the team to make decisions and validate ideas faster than most methodologies.