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?
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?
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.
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.
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.
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:
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
Before
Gather as many knowledge about the problem and market as possibleA 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 insightsYour 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: