Design sprints. The term really took off after the publication of the book Sprint. They seem like this magical thing everybody’s talking about and, although they can be really useful, design sprints can do more harm than good when they’re misused.
The broadest definition of a design sprint I can offer is this: Take between one and 14 days to go through a fixed process in order to find a solution for specific challenge.
I have to admit, I have a love-hate relationship with design sprints. I definitely see a role for design sprints in their current form. They’re great for implementation and execution, and I fully understand why design sprints are so appealing to both clients and practitioners—they provide a lot of energy, are relatively low-risk investments, and they focus on coming up with new ideas.
But, I’m going to raise a warning regarding the upsurge of these sprints. I’ve seen them misused or not used mindfully, and they can end up doing more harm than good.
Here are the three big problems—and how you can improve the quality of your design sprints.
Let me illustrate the first big problem I see with design sprints using something that I call the design clock, and it looks something like this:
In this clock, design sprints are represented by seconds. The minutes represent the project of which the sprints are a part. The hours represent the program in the project. And finally, a day represents the bigger why of an organization, as in, why are we doing any of it?
I hope this makes sense so far!
Problem #1: A total lack of awareness of the bigger picture.
The danger in a sprint is running so fast, you end up tripping over your own feet. A person assumes that if they complete a design sprint, it also automatically moves the minute (project) hand forward.
That’s a really big, dangerous misconception. So, every design sprint should also have design clock, to encourage a focus on the big picture.
Problem #2: Designs sprints can give a false impression that you’re solving a problem actually worth solving.
I like to think about design as the balance between spending time in the problem space and in the solution space, and design sprints, as they are positioned right now, don’t really take the problem space into account.
When you’re participating in a design sprint, you usually don’t spend a lot of time (if any) doing exploration and discovery. Design sprints are often focused on idea generation and idea validation. This is what Ash Maurya calls the innovator’s bias (here and here).
The problem with this is that, although you might get your idea validated and the impression that your ideas are worth pursuing, you don’t know if you’re actually addressing some of the bigger pains in your customers’ lives. You might end up creating the perfect solution for a nonexistent or trivial problem.
The cure for this is remarkably simple and easy to execute. Make sure you spend at least 50% of your time in the problem space.
Problem #3: Designs sprints focus on adding, when often design should deal in simplicity.
Chirryl-Lee Ryan said in her appearance on the Show that we should do our best to design less not more, because in many cases we can achieve a better design by actually removing stuff, not adding.
However, design sprints are always focused on creating something new, something that will consume that attention of your users or add to the complexity.
I’d like to argue that we need to do design sprints that focus on simplifying things. The most elegant solutions aren’t the ones where there’s nothing left to add, but where there’s nothing left to remove.
So, my perspective on how you can improve the quality of your design sprints is to take the design clock into account, making sure you spend 50% of your time in the problem space and strive towards simplicity.
What is your experience with design sprints? Do you like them? Try to avoid them? I’d really love to hear your perspective, so leave a comment and let’s continue the conversation there!