Originally published on Matters by Designit.
Three years ago, Jake Knapp (Google Ventures) and company published the book “Sprint — How to Solve Big Problems and Test New Ideas in Just Five Days.” Fast-forward three years later, and the concept of the design sprint has spread into the business faster than multi-resistant MRSA. On paper, it sounds pretty good: Who doesn’t want to solve all of their biggest business challenges in just five days?
With its seemingly simple recipe for problem-solving, the design sprint has become a go-to method for companies that want to develop a new product, an MVP (Minimum Viable Product), or just want to test out an idea.
Most recently, the “Sprint: Digital” project in Denmark has been government-funded to organize more than 100 design sprints for SMVs.
You only get a few answers in five short days
The general expectation is that a design sprint will solve most design problems — even problems that are very complex or involve a high level of strategy: e.g. “How do we create a new core business using our existing products?” or “Design a new product for millennials that can save our future revenue.”
In these cases, the design sprint falls short as a successful method. It’s simply not possible to design a new service or a new business in five days. At least not if you want a finished product by the end of Day 5.
If your ambition is to design products or services, which solve business challenges on a strategic level, then you need a completely different set of tools:
- Do your homework: To develop successful products and services you need extensive insights into the needs of your end-user: What frustrates and concerns the users? How can we make the everyday life of the user better? Which services do they like? Which platforms do they “hate” and why? These are some the essential questions you need answer before you even start sketching. It’s almost impossible to talk about user needs and possible solutions in a five-day intense design sprint. In these cases, time pressure often results in everyone working on the first idea that springs to mind. It’s easy to skip the key user insights. That means that the product you came up with in the design sprint will probably be the easiest solution for the company — but not necessarily the most valuable.
- It’s not a sprint, it’s a marathon: It’s a common misunderstanding that the design sprint will result in a finished product, ready to implement. The output of a design sprint is, at best, a tested flow or a design that is part of a solution. All the hard work of tweaking and optimizing the product comes after the sprint. Unfortunately, there’s rarely a common understanding of how little outcome a design sprint actually produces. It’s also pointless to run a user test on Day 5 if you don’t plan on further developing the product, after the sprint, based on the users’ feedback in the test. This is often where companies go wrong.
- Not everyone is a designer: Design is a craft, in the same way that a skilled carpenter or a great musician can be a good craftsman. You don’t become a designer overnight because you have attended a course in Design Thinking — just like you don’t become a concert pianist by buying a book of music. You become a designer after spending years and years developing interfaces on different digital platforms. Or, as a product designer, when you have designed everything from speakers to hearing aids. Design is a craft, used to create great solutions. It doesn’t mean that everyone can’t have great ideas. However, it requires a team of skilled designers to execute good ideas and make products and services appealing and useful. A design sprint with a team of analysts, business strategists, and a sprint facilitator does not result in great design solutions — at best, the outcome is a good idea.
Don’t discard the design sprint just yet
These reservations don’t mean that the design sprint should be completely discarded. A design sprint is a fantastic tool for creating common ground when it comes to understanding the challenge, supporting the project’s progress, and developing specific features. That’s also why you shouldn’t consider the design sprint as an independent process. Instead, it should be considered as a subcomponent — an optional part of the overall design process.
A lot of hard work goes into collecting valuable user insights in order to understand the target audience better, before the sprint. After the sprint, you follow up and further develop the concept that you’ve already tested.
I highly recommend that you consider the role of the sprint in your overall design process: Will it help you solve your problems, or is it, in fact, an excuse to have fun and skip trivial office tasks for five days? And would it be better to spend your budget on a different approach to the design process?