The Design Sprint: A Brief Introduction
Design Sprints have become a popular tool in designing applications but the term Sprint, in this case, is quite separate from the agile-sprint methodology so common in software development. They do share the limited time-frame for completion and both are deemed best practice in their fields, however, their goals are very different.
The Design Sprint focuses on gaining insights into crucial business questions over a single five-day period through design, prototyping and testing ideas with users and clients. Businesses are more reluctant than ever to commit to projects without understanding the chances of success. Design Sprints are “best of ” mashup taking in elements of business strategy, customer development, innovation and design thinking.
How the Design Sprint started:
In 2010 Jake Knapp wrote the book Design Sprints: how to solve big problems and test new ideas in just 5 days, but the methodology was a collaborative effort over several years of project insights. One of the unfortunate projects Jake worked on which served as inspiration was Microsoft’s Encarta Encyclopaedia in 2001. The Encyclopaedia which was originally CD-ROM based was being moved to the web. However, Wikipedia had just emerged and was growing fast, within 2 years it hosted more articles than the whole of Encarta, and for free. Soon after, the first Google search result for “Encarta” was a Wikipedia page, this spelt the beginning of the end for the Microsoft product.
Jake noticed that in the case of Encarta and so often with projects, customer research is considered at the final stage of the project, as part of marketing’s brief. The team is asked to now sell their new idea when the product is ready to ship. There is zero customer research up-front.
Many projects later, Jake is working with his team at Google on their new Hangout’s application. On this occasion, they decide on testing product demand at the initial stage to help make better decisions. They make a quick prototype and test with users over one week.
By concentrating efforts on a single problem for this short time, they were able to quickly get to the core of the problem. Since then Jake has been iterating this process, firstly within Google and then evolving and adapting it for other industries. The outcome was the Design Sprint.
The Design Sprint Week
You take a small team, between 4 and 7 in size and rapidly progress from problem to tested solution. The week follows a predefined pattern, each day has a specific objective. There is some prep work in terms of choosing the team along with several subject matter experts and stakeholders to interview on day 1.
The most important element of the team is “the Decider”, this person is usually a senior stakeholder who has the influence to resource potential solutions arising from the Sprint. The Decider does not have to be present each day but will need to be at hand at certain stages to make difficult decisions when the team needs.
Below is the Sprint timeline as set out in Jake’s book.
Monday
Monday’s structured discussions create a path for the sprint week. You’ll start at the end and agree to a long-term goal. Next, you’ll make a map of the challenge. In the afternoon, you’ll ask the experts at your company to share what they know. Finally, you’ll pick a target: an ambitious but manageable piece of the problem that you can solve in one week.
Tuesday
On Tuesday, you get to focus on solutions. The day starts with a review of existing ideas to remix and improve. Then, in the afternoon, each person will sketch, following a four-step process that emphasizes critical thinking over artistry.
Wednesday
You and your team will have a number of solutions. You can’t prototype and test them all — you need one solid plan. In the morning, you’ll critique each solution, and decide which ones have the best chance of achieving your long-term goal.
Thursday
A realistic façade is all you need to test with customers, by focusing on the customer-facing surface of your product or service, you can finish your prototype in just one day.
Friday
Interview customers and learn by watching them react to your prototype.
The Benefits:
- Mitigates Risk
- Solves Design problems quickly
- Allows you to fail early
- Direct user feedback
- Stakeholder validation
- Align teams
The Drawbacks
Stakeholder engagement is both the biggest advantage and biggest obstacle for Design Sprints. Indeed, substantial stakeholder engagement is factor number one in the success of most projects. Some might baulk at the trouble in getting stakeholders to commit to some of the sprint sessions; they are needed for part of the first and second day. However, the potential benefits thoroughly out-weigh the inconvenience.
Design Sprints are not a replacement for conducting user research, they can be used in tandem but that’s a topic for another day.
With benefits so large in terms of saving time, effort, mitigating risk and building client relationships. The Design Sprint is a battle-tested tool to get clear feedback on a project’s viability before a single line of code is written.
Even Medium uses Design Sprints!
Learn more
There are Design Sprint meetups in cities around the world. In Dublin, you can attend the official Design Sprint Ireland meetup. The organiser, Rohan, also runs facilitator training which a few of us in the UX team at Version 1 recently attended. The Ladder is a meetup group based in Dublin which uses Design Sprints to tackle real-world problems.
You can, of course, read the book itself, Design Sprints: how to solve big problems and test new ideas in just 5 days, which works as a step by step guide to the process.
About the Author
Robert Harte is a UX Consultant at Version 1, working with a wide range of customers to solve their User Experience needs. Recently, Robert has worked in the Innovation Labs, where he has helped to provide design thinking practices and service design to our customers.
