This article is part of a series that centers on Design Sprints. Find Part 1: an overview of Design Sprints here, and Part 2: a guide on when to apply it here.
Design sprints are a well-known tool we can employ when we want to validate solutions and face challenges in a user-tested approach. It’s short, it’s full of insights and for the most part it’s an invaluable tool for many teams. But it’s not always the right choice for your needs. Read on to discover if design sprints are right for you! Find part 1 here.
Design sprints have a solid reputation as a quick, insightful and efficient tool for problem-solving, validation and user testing. I’m a big fan, but I’m also ready to recognize that this tool doesn’t benefit everyone, every time: it’s no silver bullet. There are aspects of your project that you need to consider before diving into it that will determine how useful and successful this methodology will be.
I’ve previously talked about the cases where design sprints can be the tool you need – read about it here. But now, I want to explore the cases where design sprints are not the way to go.
You should look into other design thinking techniques different from a Design sprint when…
- the product’s level of definition is high.
This is one happy problem to have. If you find that you’ve reached the stage where you already have a very well-defined product, and do not intend to explore either any change, new opportunities, improvements, or even reductions, then certainly don’t go for a design sprint. It makes no sense to dedicate the first days to exploring solutions when you could be prototyping. Particularly, preconceived solutions by the deciders will cloud the possibilities of potential innovations as they will tend to gravitate towards those in the voting sessions.
- there are insufficient inputs and user data.
Design sprints deliver all of their power when they rely on good input regarding target personas and users. Naturally, you don’t need to know everything before you start. But how will you define your experts and users to test without a target persona? If you have little to no knowledge of your users, it might be time to step back and perform some user research activities that gather information about your potential users.
- your scope is too broad. Or your scope is too narrow.
You’ll make the most out of a design sprint when you have a big enough and concrete enough challenge. While it’s true that design sprints help you and your team focus and narrow down the scope of your product, it’s also true that starting from a challenge that is too broad and full of variables can be unattainable if we consider that the complete extension of the design sprint is 5 days. Imagine tackling a problem such as the future of public transportation in just 5 days!
On the other hand, if your challenge is framed as a narrow question such as ‘How can we improve the visibility of our customer support chat assistant on our homepage so that it becomes easier to access?’, the specificity of the question determines that a fitting solution might be to gather your product and design team and work on improvements outside of a design sprint. Some examples could be color changes, adding buttons and other minor modifications. A good design sprint question is on that sweet spot between specific and broad.
So… what’s the challenge you’re thinking about tackling? Reach out to me at vico@arionkoder.com and we’ll help you frame it and choose the right tool for your needs!