We’re huge fans of design sprints, as popularised by Google Ventures.
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.
Jake Knapp is running a public Design Sprints workshop in partnership with Clearleft in London on the 7th September. Tickets are on sale now. If you’d like to see how we can run a Design Sprint for your business, do get in touch.