How NOT to Use Design Sprints: A Warning
October 18th | 2017

Once we discover something we like, we sink our teeth in.

When we first started talking about design sprints and how to incorporate them into our work in 2014, it felt like the perfect match.

At Zeus, we like to work fast. We find a lot of value in focusing our time and making progress quickly. And we’re always looking for new ways to test our ideas. So, when we started incorporating design sprints into our work, they started getting more and more popular, internally, as we realized they were a great addition to our toolbox.

But, fast forward to a few months ago, and I found myself cringing every time someone mentioned them – doing my best not to roll my eyes at the proclamation, “Let’s sprint this!” Because, here it is – I hate design sprints.

We use them for a lot of applications: to concept and ideate for new products, to articulate value propositions, to evaluate brand architecture, to design and concept entirely new brands – the list goes on. The thing is, I like rules! And appropriate naming conventions. Which means “design sprint,” as a term, was starting to feel inaccurate and inadequate to me.

So, I lied: I don’t hate sprints. But I don’t like how we’re using the term as a catch-all to describe working fast in a bunch of different ways. When it comes down to it, is it still even a sprint if you’ve totally butchered the process? Are we just working fast? Could we just call what we’re doing “work”?

Scribbles_4.jpg#asset:1467

So, when I realized the real problem, I made a pros and cons list to organize my thoughts.

Sprint Pros:
  • They’ve helped us think about MVP (minimum viable product) models, how to design for only part of a concept, and how to create something that has a lower level of fidelity in order to move forward.
  • They’ve helped to make the testing process a natural part of most everything we do, and we have a lot more ways to think about testing than we used to.
  • They get everyone involved and help us practice putting pen to paper and getting ideas out.
  • We generate a larger number of ideas and accept more ideas from a larger group of people.
Sprint Cons:
  • We’re not always working on problems that can be solved in a standard one-week design sprint. The questions we’re trying to answer are often the big, messy, complicated ones that require us to break down the problem into more discrete, smaller problems (that would thus require many design sprints). So we have a hard time applying the design sprint method to the right kinds of problems.


  • We often aren’t fully dedicated to one project, and have other internal obligations that limit our ability to spend more than a full day focusing on one thing, so the process ends up feeling fragmented.

What I realized, looking at all of it, is that good does come out of sprints, and they can be useful. But when you get caught up in the terminology, and in sticking religiously to the process, whether it’s the right one or not, you’re doing both your project and the idea of a sprint a disservice. Instead, the best thing to do is take the principles behind design sprints, break them down, and use what’s applicable and efficient to move projects forward.

But don’t expect me to call that a sprint.

Here are my best tips on how to use the principles of sprints the right way:

  • Adapt the process. Take the parts you like and ditch what’s not working. Just because you use a crazy eights exercise doesn’t mean you’re running a sprint (and that’s ok).


  • Be careful what you call it. Sometimes your process doesn’t need a name. If you’re just working fast, you don’t need to call it a design sprint. The wrong terminology can confuse things, especially because “design sprint” is a widely recognized term that carries a very specific meaning.


  • Clarify the level of fidelity you need to test. Get everyone on the same page up front before you think about how much time you’ll need and what the right process is.


  • Better yet, think about defining the test plan as your very first step. If you know the result you need from the “sprint,” it’s a lot easier to figure out what you need to make, how much time you need to make it, and who can help you get to the right solution.


  • If you are sprinting, make sure the people and resources you need are in place for the entire time you need them, and make sure everyone’s 100% focused on the task at hand.