Why Your Design Sprints Always End in Tears
Don’t let these common mistakes trip up your sprint
When I was a kid, I watched Julia Child make hundreds of omelets. She’d melt what looked like a pound of butter, effortlessly crack a few eggs into a bowl, whisk them, and in the blink of an eye — an omelet would seemingly blink into existence on a plate. Voila.
This absolutely fascinated me. If I could just follow simple instructions, I could have an amazing, elegant breakfast in less time than it’s taking me to write this introduction. But to this day, every time I walk into a kitchen planning to make an omelet I walk out with a plate of scrambled eggs.
Classically trained French chefs have their expertise evaluated by how well they can make an omelet. Omelets look easy to cook, but they’re really difficult to cook well. It’s not that I couldn’t learn; I could—I’ve just never spent the time.
In this metaphor, Google is Julia Child. Google’s put forward a great, simple-looking recipe for innovation with design sprints. They’ve published a bestselling book, posted hours of lectures online, and made a fantastic website that walks you through the process. So why do so many people walk away from their first design sprint wondering how things could have gone so badly?
Just like omelets, design sprints can be really easy to mess up.
After my first design sprint, my team trusted me less and were more confused than they had been the week before. As a design professional, this was extremely disappointing; as a researcher, it was fascinating. I asked myself “What just happened? Was that my fault?” The bad news is that it was absolutely my fault. The good news is you can do it well. But just like omelets, design sprints can be really easy to mess up.
I’ve already made those mistakes, so you shouldn’t have to. I want to share the most common ways I’ve seen sprints go wrong so that when you run your next sprint, you’ll be set up to walk away with something amazing.
The most common areas where sprints go wrong
- Grounding: You don’t understand your problems well enough to start.
- Scoping: Your problem isn’t a good candidate for a design sprint.
- Execution: You aren’t following or breaking the right rules.
- Testing: You’re not set up to get the right feedback.
Let’s look at each of these with a bit more detail.
1. Grounding
One of the biggest mistakes I see people make in a design sprint is not actually knowing why they’re doing one. I remember several times when executives told me “We’re doing a design sprint in two weeks! We’ll figure out what it’s going to be about then!”
That’s backward; your solution should fit your problems — not the other way around. If you spend your first day figuring out what you’re trying to do, you’re taking an already aggressively time-boxed exercise and making it even shorter. Even worse, you may not be able to collect the necessary information or expertise to explore your topic successfully. Now, it’s always an option to run design sprints to practice doing design sprints, but if that is your goal, making sure everyone both understands and agrees that’s the goal is imperative.
Before starting a design sprint, ask yourself: Do I know enough to get started? Are you hypothesizing that the people you’re trying to help have a particular problem? Are you unsure whether the people you’re trying to help even exist? If so, it might be worth doing some more homework before investing a week of your team’s time.
It’s okay to use your intuition to guide a sprint, but make sure your intuition is backed up with facts. There are lots of places you can find facts like these: Maybe you’ve seen something weird when analyzing a click-through stream; maybe you’ve heard about people using a product of yours in an unexpected way; maybe you’ve watched people live through some daily frustration. The important part is having data. Without data, it’s easy to confuse stereotypes with empathy.
2. Scoping
Design sprints are a fantastic way to tackle some problems, but they’re not the best way to solve every problem. “What color should our sign-in button be?” might not require a week of exploration and testing; “How can we expand into the EMEA market at a sustainable 3% growth year-over-year?” might be a bit too much to tackle in a week. The successful sprints I’ve seen are in that Goldilocks zone in the middle, where the problem isn’t so big that you couldn’t solve it in a week, but isn’t so small that you’d get a better result from just leaving a designer alone for a day or two.
Another common way I see design sprints misapplied is when they’re not actually exploring a design problem. I’ve been asked to use a design sprint to figure out how to increase conversion rates — a marketing question. While a design sprint might have been a fine way to begin exploring that issue, it wouldn’t have been able to get us the answer our team was looking for. Design sprints can tell you “This might be a good idea,” but they aren’t set up to give you a concrete answer to whether Option A is measurably better than Option B.
3. Execution
While there are lots of ways a design sprint can go wrong once you start, the two I see most are ignoring guidance on how many people to include, while adhering to the rest of the guidance far too strictly.
Google does a great job explaining why larger teams (more than seven people) can be a mistake (p. 34 in Sprint). But because design sprints can be such a powerful political tool to share information and align on a vision, it can be tempting to include as many people in the process as you can. Don’t.
Successful sprints need deep engagement from everyone to thrive; the more people you have in a room, the less time each person will have to contribute.
Because design sprints are so time-constrained, there isn’t much room to recover when anything unexpected happens — or when you realize you need more time to do quality work. I see this happen most when people are creating new ideas or testable prototypes. The design sprint process allots about 30 minutes to come up with the ideas you’ll be exploring over the week. But what happens when 30 minutes isn’t enough? What do you do when you’re creating a prototype and realize halfway through that this is a four-day project and not a four-hour project?
In both these cases, I’ve seen teams fail dramatically by ignoring the problem, or succeed by realizing they need more time, reevaluating their goals, or both.
Don’t forget: The entire point of a design sprint is to get fast feedback on your idea without having to build and launch a complete product.
Not everybody creates at the same speed. If you aren’t excited about what you’ve come up within the amount of time you’ve given yourself, seriously consider giving yourself more time. Not only is there a good chance you’ll come up with something cooler, but the whole team will also be more engaged when they’re working on something they’re excited about.
If you’re still having difficulty developing a good idea, you may be exploring the wrong “level of zoom;” you may be concentrating on the specifics when you could get further by exploring something more abstract.
For example, say you find yourself with a day to make a prototype and realize it would take a week to get right — would you still get valuable feedback by scaling back and showing a storyboard of your experience instead of the finished prototype?
Don’t forget: The entire point of a design sprint is to get fast feedback on your idea without having to build and launch a complete product. True, getting feedback on something conceptual like a storyboard isn’t the same as letting users actually touch your design — but you’ll still learn a lot about what they think of it.
4. Testing
One of the most essential parts of design research is making sure you’re talking to the right people. Anyone can offer feedback on a design, but how useful is that feedback if you aren’t talking to your target users?
Design sprints give you three days to recruit participants. If you’re creating a product designed to have mass appeal, that may be enough time. But when I talk to professional recruiters, they usually ask me for two weeks.
Unfortunately, I don’t have a magical suggestion as to how to get around that (direct message me if you do…). What I do have is advice. Be realistic about how long it’s going to take you to find users to test with and adapt your plans accordingly. Personally, I’ve had the most success when I’ve started the recruiting process before design sprints begin.
I’ve already alluded to the other place I see testing most frequently go wrong. Design sprints are an excellent tool to say “This might be a good idea.” They aren’t well equipped to say “This is a good idea” or “Idea A is better than Idea B.”
From a statistical standpoint, talking to six people usually has a margin of error of about ±40%. Put another way, any measurements you try to get out of talking to six people aren’t going to be very accurate. Fortunately, if you’re using design sprints to test what they’re good at exploring, you don’t need that level of statistical accuracy. Concentrate on how people feel about your prototypes, how they could see it working in their lives, how it compares to what they do today, etc. If you do that, you’ll get what you need.
Design sprints can be a powerful tool. But just like any other powerful tool, they can go disastrously when used wrong (props to every wood shop teacher reading this).
So long as you’re thoughtful about what you’re using design sprints for, you’re making sure you adapt the general outline provided to your specific needs and constraints, and you know what you’re trying to learn from them, they’re going to serve you fantastically.
Originally published in One Design
