Skip to main content

Don't do Design Sprint when

A Design Sprint is a structured, 5-day process to learn about critical business problems. Companies of different sizes use the Design Sprint to innovate, move faster and be more confident in their product investments. Yet sometimes a Design Sprint is overused, misused and wasted. Reason being the lack of the process understanding and lack of application experience. When shouldn't you use a Design Sprint?

When problem is too small

A Design Sprint is an investment. It requires time, people, their attention and a bit of money. You want to spend those precious resources only on a problem that big enough. What is NOT a big problem?
For example: whether the button should be red or blue.
Even if it's the most important button of your entire business - it's still not big enough for a design sprint. You can do an A\B test instead.
Shall we charge $12,5 or $14,5? Is also not a big enough problem for a design sprint.
What can we upsell on a checkout page might be big enough, especially if you tweak it to what people want to buy together with their initial order?

When you'll not be able to prototype a solution

80% of everything could be prototyped. But when you're after the rest 20% - a Design Sprint might not help you there.
For example, you're building a new recommendation engine for movies. With a design sprint, you can check if your users would appreciate recommendations and how you need to present it to them. But until you actually write an algorithm - it would be very hard to test its effectiveness. So when you want to test the technology itself - a Design Sprint might not be the best choice.

When you can't commit to a process

A Design Sprint is a process. Every stage is important and serves a purpose. If you can't commit to the entire process - you're putting sprint results at risk. For example, you decide that you don't need an entire team to prototype the solution and dispatch it to a designer. As a result, you might have a prototype that is not consistent with half of a team. Or, in another example, you don't do an "Unpack" phase and jump immediately to the ideas and solutions. In this case, you risk wasting the entire week because your team didn't understand the problem space or they haven't heard\found enough evidence.

When design sprint mediator has an own agenda

A Design Sprint should have a facilitator or a mediator. A person who knows the process and would guide the team through it staying as objective as possible. When such person has an own agenda, interest and not being objective - it could jeopardize the entire process. The best when a facilitator only cares about the process and not the design sprint topic itself.

What you should do before and after a design sprint


Gather as many knowledge about the problem and market as possible 
A Design Sprint has an "Unpack" day when the entire team shares their knowledge about the problem and the market. Yet it's very useful if before design sprint you already gathered some insights. Get as many data as possible. Talk to users and customers. Read industry materials and studies. The more you'll have to share at the beginning of a design sprint the better. But remember it should be an information about the problem, not a solution.

Get the tools ready
A Design Sprint is a great method because everyone can get involved. During the "Prototype" phase everyone can contribute. Here is a good overview of how everyone can prototype using their familiar presentation software. And it is useful if you share those instructions with your future sprint participants. This would save you a fair amount of time during the 4th day of a sprint.

After the sprint

Share the insights
Your design sprint team should participate (observe) how real users try out a prototype you've all created. And when insights gathered and result described - share them with the entire organization. You'd benefit in the various ways from it. Firstly, it would show your organization how you work. It would add to your team credibility. Secondly, it would improve internal communication. Now everyone could learn about the problem, possible solutions, try the prototype and see the users feedback.

Be transparent about next steps
What is the outcome of the sprint? Would you develop a solution? Would you do another sprint? All these questions should be answered after the sprint. Your sprint members invested a lot of time and effort into it and so they need to know what is next for their work.

Want to know more about A Design Sprint?

Lately, Jake Knapp, John Zeratsky and Braden Kowitz published a book about the Design Sprint process

And even before that, there has been this book.

And it's all in addition to a huge number of articles about it. To mention a few:

Popular posts from this blog

Product management and operations tools - Jira Product Discovery review

  JPD is a new player in the market of product management software. Jira (and the whole Atlassian suite) has been one of the most popular tool stacks for teams to deliver software products. Now they're adding a missing piece - product discovery.

Product Vision: an elevator pitch for your product

On this blog, I write a lot about making data-driven decisions . But what if you just starting to think about your product? You have a vague idea and nothing more. No point to go for prototyping or even talking to customers as you don't know yet who to talk to and what to talk about. In such situation - start from creating a product vision.

2 simple but powerful filters for your problem and product ideas

Nowadays lots of people and companies want to innovate. They want to generate new ideas and turn them into profitable products. But how would you separate good ideas from not so good ones? How would you make sure you invest only in good ideas?