Photo by Jeremy Bishop on Unsplash

Why Your Design Sprints Always End in Tears

When I was a kid, I watched Julia Childs 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 Childs. Google’s put forward a great, simple-looking recipe for innovation with design sprints. They’ve published a bestselling book, have 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; 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 Four 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.


One of the biggest mistakes I see people make in a design sprint is not actually knowing why they’re doing one. I remember a time (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 backwards; 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. This isn’t to say you shouldn’t 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 if 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 ok to use your intuition to guide a sprint, but make sure your intuition is backed up with facts. Maybe you’ve seen something weird when analyzing a clickthrough 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.


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 too small that just leaving a Designer alone for a day or two would give you a better result.

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”; they aren’t set up to give you a concrete answer that Option A is measurably better than Option B.


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 invite, while adhering to the rest of the guidance far too strictly.

Google does a great job explaining why larger teams (more than seven) 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.

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 either creating new ideas or testable prototypes. The design sprint process gives 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. Conversely, I’ve seen teams succeed by realizing they need more time, reevaluating their goals, or both.

Not everybody creates at the same speed. If you aren’t excited about what you’ve come up with in 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, if 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 showing a storyboard of your experience?

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. It’s 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 what they think about it.


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 do you know if that feedback is useful 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 (DM 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.

In Summary

Design sprints can be a powerful tool. But, just like any other powerful tool, they can go disastrously when used wrong (props to every Woodshop Teacher reading this).

So long as you’re thoughtful about what you’re using design sprints for, are making sure you adapt the general outline provided to your specific needs/constraints, and know what you’re trying to learn from them — they’re going to serve you fantastically.