Editors Note: This is an excerpt from InVision’s Enterprise Design Sprints Handbook, which highlights the methodology behind successful design operations.
The original design-sprint format popularized by the Google Ventures team has been interpreted by some as a one-size-fits-all model. This was never the intention, and it’s definitely not the case for enterprise-level projects. Although UX, design and product teams have adapted sprints to find new applications for its prototyping value, it can’t be used in every situation.
Below are some situations in which a design sprint is not useful for enterprises. (It’s worth noting that this list is specific to enterprises. In some startups or small innovation groups, a design sprint might be the appropriate tool in these situations.)
For small iterative changes to an existing feature(s)
If you have an established product and you’re making small iterative updates, a design sprint is going to be too much tool. Rather, use one of the many exercises in the design sprint repertoire to answer a specific question. A quick prototype of a new improvement doesn’t need five days to prepare. Mock up a rough version and get it under the noses of customers that same day.
To update a prototype that’s already generating feedback
Once you have a prototype out in the wild and you’re receiving feedback from customers, it’s not necessary to do an entire design sprint before making refinements. Simply determine the questions you’re seeking to answer, identify the relevant feedback you’ve received, and make adjustments. If you want a more formal process, consider doing the just the last three phases of the design sprint (Converge, Build and Test).
Whenever there is no research
When planning a new project initiative or innovation, it’s best to already have research about what problems are worth solving (see chapter 1). Although the exercises in a design sprint help reveal a customer pain point and potential solution, they’re not ideal for establishing whether a market exists for that, or any, solution. Fundamental research is necessary for enterprises to discover opportunities that can then be validated with a design sprint. Don’t skip the research. Solutions without markets are destined to fail.
When seeking a high fidelity design output
A design sprint intentionally doesn’t provide high fidelity designs that you can immediately use in final product design. Remember, the purpose of a design sprint is to provide answers and direct your team’s attention to potential viable solutions. The final design of your product or feature probably won’t look anything like the prototype you made to test your hypothesis. Keep your expectations real and you’ll be fine.
As a replacement for iterative workflow
Workflow considerations are slightly different from the iterative feature changes listed above. A feature change is often a discrete update, while iterative workflow is a choice of methodology (i.e. Lean). While a design sprint can be valuable to test feature changes, it won’t be a substitute for the daily design and dev backlog. In enterprises where waterfall is still the preferred methodology for processing this daily work, the cadence of a design sprint is going to feel much faster. But that’s not a problem as long as you run the design sprint in parallel to your backlog of design and dev work. Stopping regularly scheduled work to do a design sprint, however, can be more disruptive than helpful in waterfall environments.
When looking for evidence of product-market fit
Finally, there is little evidence that evidence from a design sprint also confirms a product-market fit. Unless you are also testing pricing and benchmarking competitive offers, you’ll find it very difficult to know if your validated prototype is something people will pay for or switch over to from a competitive option. You’ll need to do further testing and possibly even ship an MVP to establish whether your market even wants your lovely new solution.
Like personas, JTBD (jobs to be done) and experience maps, the design sprint is just one of the many tools available to the designer and the broader product team. So it’s important to make sure you’re applying a design sprint to a design-sprint job. It’s also wise to remember a design sprint can invalidate an idea as easily as validate it. This sometimes means you’ll get an answer you don’t expect.
In a recent enterprise-client engagement, we were faced with a situation where a senior manager was convinced his product needed a significant redesign. It likely would have cost several hundred thousand dollars considering the complexity of the product. However, the team learned on the first day (Understand phase) that a redesign wasn’t a problem in need of solving. We pivoted to focus on the real issue affecting sales: The lack of a clear value proposition with accompanying language and sales collateral.
Here’s an Unfortunate Truth…
Even if you do a design sprint correctly, you’re still likely to have lots of unanswered questions.
The very nature of this type of inquiry is that it reveals potential problems that need solving. Expecting your design sprint to be the endpoint for research is a recipe for disappointment. Instead, look for the doors that open through the process, and use your new insight to define additional research and data-gathering efforts. Establish this expectation with participants throughout the design sprint so you’re not asked to answer awkward questions at the end of the process.
The design sprint is a powerful tool with wide appeal and application. But it’s not going to solve every problem. Whenever you’re considering a design sprint, come back to these last few sections and confirm you’re setting yourself up for success. It’s also useful to know the exercises inside the design sprint, as each has the ability to be used discreetly. Understanding the value of each exercise will help you decide if you need to run an entire design sprint, or just a few of the phases.
I like to think of a design sprint like a superhero’s utility belt. Sometimes you need all the tools in the belt, and sometimes just one or two will do. Chapter 5 will examine the tools in the design-sprint belt. The guidelines follow directly from your decision to move ahead and will provide you with a detailed plan for your design sprint.