A week is a lot of time to waste. And if you jump into a design sprint just because you heard it can solve any problem in a week, throwing away your week is exactly what you’d be doing.
Don’t get me wrong—I’m a big believer in design sprints. At Studio Science, we’ve been able to use this methodology to rapidly find solutions for ourselves and for our clients, and we’ve also been able to use elements of the sprint to inform our other, more traditional processes.
The problem comes from thinking that this shiny new methodology is a one-size-fits-all solution to any problem.
Related: Frequently asked questions about design sprints
We’re often asked if we can get results quicker by doing a design sprint. And sometimes the problem we’re looking to solve is perfect for a design sprint—it’s the right size and type of problem that can be prototyped quickly, it’d benefit from multiple perspectives in the room, and it can be effectively validated through user testing at the end of the week.
Many times, though, a sprint just isn’t the right method. Let’s go over 3 situations where that’s the case, and what to do about it.
“Design sprints aren’t a one-size-fits-all solution.”
1. When there isn’t enough information up front to effectively inform the solution
Day 1 of the design sprint reserves time for key stakeholders and subject matter experts to help inform requirements from the perspective of the user, the business, and the technical side. This is always helpful, and it’s often informative enough to act as a foundation to design upon, but sometimes even the key stakeholders and subject matter experts don’t possess an understanding of the customer that’s complete enough to speak on their behalf.
Before conducting a sprint, you—or an expert involved in the sprint—should be able to speak to:
- The overall vision for the product
- Customer needs and feedback
- How the product currently works from a technical perspective
- Any previous efforts to solve this problem, and what was learned from them
It shouldn’t be difficult to get background on most of this list from stakeholders, but often there’s a big gap around customer needs and feedback. To be able to design anything meaningful for people, you need to first learn about them. What motivates them? What are they trying to accomplish? What are their metrics for success? (Hint: they’re probably not the same as yours.) This level of understanding comes from talking with users, spending time with them, and getting to know more than just their demographics.
“You need to learn about your users before you conduct a design sprint.”
The point of Day 1 is to define the problem, and a critical piece of this is being able to clearly outline the user, technical, and business requirements. Without these, a team can’t complete Day 1 of the sprint in any meaningful way.
When we’re lacking information, the right move is to figure out a research strategy before moving into a sprint.
2. When it isn’t a product design problem
The design sprint is meant for product design problems, and this is a fairly large bucket. Examples in the Sprint book include an ecommerce website and a hotel service robot—both products, but with significantly different considerations.
However, when the problem at hand is outside this area—a brand or service design problem, for example—the GV design sprint isn’t meant to prototype and validate a brand or service design problem.
GV recently posted their 3-Hour brand sprint, which contains valuable exercises for getting your team started figuring out your brand. But as they note in the article, it’s meant as a way to “get started on your brand” and is “not a replacement for a good branding agency.”
Related: Go inside design at GV
Defining a brand requires insight into core areas both inside and outside of the company. And while 30-minute discussions are a great way to get your team thinking about these things, it’s not going to yield the kinds of insights, perspective, or results that a research-driven branding process will.
3. When an effective prototype can’t be produced in a day
The default sprint schedule allows a day for building the prototype. For a broad range of solutions, you can build an excellent prototype in a day that feels real enough and will be able to elicit meaningful results from testing.
Sometimes it takes more than a day to get to something real enough to test, though. For example, prototyping a new onboarding process is a great fit, but redesigning an immersive, interaction-heavy experience might require more time than fits within a sprint.
Adding days onto the prototyping phase of the sprint can often be a fine way to handle this, but it’s worth considering and planning for up front so that you don’t end up trying to test with a prototype that just isn’t ready.
Note that just because a sprint isn’t right for a problem, it doesn’t mean we can’t use elements of it to be more efficient and collaborative in our process. In fact, the authors of the Sprint book even recommend it. The sketching and deciding exercises within GV’s design sprint process aren’t especially novel—similar concepts have been a part of the design toolkit for years. But they’re effective, especially when it comes to being time efficient.
We’ve been able to use these exercises during a more traditional product design process to gain efficiency when a full sprint isn’t possible or isn’t the right method. For example, when we need to spend more time ideating on our own and then come back together as a group, we can still use the sticky notes decision-making exercise to narrow down solutions together and keep the process moving forward.
Design sprints are a great way to validate a prototyped solution in a short amount of time. But before you jump in, make sure you question whether it’s the right method for the problem at hand.
Keep reading about design sprints
As a Design Lead at Studio Science, Justin leads a team of UI/UX designers and developers focused on digital product design and development. He has worked with clients from small startups to established brands including Salesforce, Stack Overflow, and MailChimp.
