The Design Sprint hammer

Advice

We’re huge fans of design sprints, as popularised by Google Ventures.

Andy Budd

12th July 2017

We’ve been running our own variation of design sprints for over five years now. This takes the core elements of a design sprint—rapid iteration over a short period—and bookends the process with a little more research up front, and some follow-on support at the end. We’re not alone. In fact we’ve seen dozens of agencies follow suit and start offering design sprints as a service.

From the agency’s perspective, it’s a great way of getting to know a potential client and delivering value much earlier in the process than usual. From a client’s perspective, it’s a great way to tackle a small but well-scoped problem efficiently and effectively, while trialling a potential new design partner. We’ve seen design sprints used as a credible alternative to the old-fashioned design pitch we’ve all grown to hate.

That being said, as any tool gains popularity, it opens itself up to abuse. Or as the saying goes, “if all you have is a hammer, everything looks like a nail.” Over the last 18 months we’ve seen design sprints sold as a catch-all solution to all life’s design problems, whether they’re appropriate or not. We’ve seen design sprints used to solve problems which are far too large to be solved in a week, and problems which are far too granular and nuanced. We’ve also seen design sprints used as innovation theatre, with little thought or planning around what happens afterwards.

So I wanted to take a quick step back, to look at what design sprints are good for, and where they fall down.

Choosing the right project for a design sprint

Design sprints are great at solving well understood problems, so stack the team with domain experts and share as much insight as possible. If you’re lacking either experts or insight, your sprint team will get stuck at the first hurdle. A lack of insight is easy to fix. Simply commission a small research project in advance of the sprint. Lacking access to domain experts is more tricky to solve and will greatly hinder decision making. In this instance it may be better to revert to a more traditional six-week discovery phase where the design team works around the stakeholder’s schedule, rather than the other way around.

Design sprints work best when they are solving a well scoped problem. Too big and you’ll run out of time; too small and you’ll spend the week rearranging the proverbial deckchairs. Not all problems fit nicely into a week-long timeframe, so choose carefully. Prototyping a major new feature will probably work; creating a production-ready version of your next product probably won’t.

Design sprints are great at creating interesting but messy prototypes, ripe for further exploration. They rarely produce production-ready solutions. If you assume you are going to solve the entire problem in a week and have it live the following Monday, you may be disappointed. Instead, you need to manage expectations, and allow more time than expected at the end of the sprint to clean things up and turn your ideas into reality. As hinted above, the fidelity of the final output is also key.

Design sprints are a great way to reduce the cost of failure in situations of high risk and uncertainty. If you’re comfortable working in a Lean environment, the outcome may simply be understanding what doesn’t work. Whilst sprints are often sold as a silver bullet, there is no guarantee you’ll be left with a usable solution at the end. To steal a Ron Burgundy quote, design sprints “work 60% of the time, every time”. You should try to avoid promising the Earth with design sprints, or using them to solve problems that are too important to fail.

It’s best to use design sprints wisely and relatively infrequently. They are fun and highly addictive, so it’s easy for teams to try and solve every problem with a design sprint. But they are also incredibly hard work, and a great way of burning out your team. I wouldn’t want to see the same product team sprinting more than once every four weeks, and even external consultants need a break between sprints.

If you’re careful in selecting the right project for your sprint, and you avoid some of the above traps, design sprints are a great way to solve 80% of the problem in a short amount of time. However the time and effort comes from designing the last 20%. It’s best not to see design sprints as some magic shortcut that can collapse the fabric of space and time, but as an efficient design approach to solve the bulk of the problem at an early stage, when the risks are at their lowest.

Jake Knapp is running a public Design Sprints workshop in partnership with Clearleft in London on the 7th September. Tickets are on sale now.