You’ve got a killer idea for a new product, but aren’t sure if it’s viable, and you’d really like to test it out without wasting a lot of resources. How can you quickly and inexpensively come up with a prototype? The use of a Design Sprint could be one possible solution.
As popular as they are, Design Sprints are not ideal every time a product team wants to solve a problem.
Let’s quickly review what a Design Sprint is intended for. It is a problem-solving framework for product teams to get answers quickly and effectively. It is not intended to produce only design assets.
Due to its flexibility, it has become the go-to for time-boxed innovation sessions with an emphasis on collaborative ideation, solution sketching, prototype building, and user testing. However, that flexibility doesn’t translate to being an elixir for all problem solving.
I’ve had people tell me about a successful “sprint” they ran, where they removed the Prototype and Test days, shortened the Map and Sketch phases to two hours, and told everyone it was a hit. Hey man, that’s not a Design Sprint — that’s just an organized and efficient meeting!
“How do I know if it’s the right time to run a Design Sprint for my project?”
There are few cases when a Design Sprint is especially effective:
1. When big challenges need to be solved
Asking for five days of someone’s work week is a big ask. So it’s important that the problem you’re tackling is big enough that it’s worth investing five days of your cross-collaborative team to solve.
2. When there’s no obvious solution to your challenge
Running a Design Sprint when there’s no obvious solution is also really good for the early days of defining a new product. You may not even understand the problem yet!
3. The problem requires a cross-functional team to solve it. Also, it helps to engage the team.
One of the best things about a Design Sprint is how five days in the same room bridges the boundaries between really different teams that don’t usually work together to achieve product decisions within a timeline that doesn’t normally happen. I’ve seen teams who can’t even agree on what the problem is on Day 1 end up agreeing on the solution by Day 3. The problem mapping, idea generation, and single-vision of a Design Sprint allows the team to build a deep, working relationship in a way that a series of meetings never can.
The question of whether a Design Sprint is appropriate for your organization, however, isn’t necessarily as important or appropriate as the question: Is a Design Sprint right for my challenge?
The future belongs to the curious ones
Be open minded; if we as curious designers won’t do that, we can’t ask for others to do so — we are the creative ones :). So, don’t misjudge or underestimate one method over another unless you try it; you’ll never know what kind of value it will bring you in the future, even if it’s a minor one. Always strive to learn more methods and acquire new tools for your professional toolkit both technical and theoretical ones. When there’s a doubt, don’t be afraid of trying a new method — the worst case; you’ll fail and learn from the process. Right?
