Spiria logo
Interested by the tech world?
You will receive weekly the blog posts written by our geeks.

Innovate with the Design Sprint

The Design Sprint is an intense team creativity session, spread over five consecutive days, designed to find answers to company objectives. Launching a new product or service, an application, changing an offer, or increasing a rate of transformation, are all cases where a Design Sprint can be a solution. However, it is most common in reviewing and improving a user experience.

The Design Sprint concept was developed in 2010 by designer Jake Knapp at GV, formerly Google Ventures, which is Alphabet’s venture-capital investment arm. The method is intended to help a team define objectives clearly, validate ideas, and establish a roadmap before starting development. Strategic issues are addressed through rapid and interdisciplinary prototyping and options are validated through user testing. This design process is obviously inspired by the Agile methodology, hence its name. One of the main objectives is to compress the group reflection process, which normally takes months and can dead-end due to hesitation, disagreement and fatigue.

Preparation (Sprint Planning)

A well-prepared Design Sprint maximizes the chances of success. First, a description of the challenge ensures that all participants are on the same page. The Sprint Brief gathers the problem, the main objectives and the deliverables that are expected from the session. If you feel it necessary, you can do exploratory research before holding your Sprint to gather all potentially useful documents (text, audio, video), such as the results of prior user tests.

Choose the team (usually composed of 5–8 people) and make sure that it is available in full at the same time for a whole week, which is not the least of your challenges. While this can be easily done with a small team in a start-up, it is more difficult in the context of a larger company. Ideally, the team should be multidisciplinary for a greater breadth of perspective and knowledge. You could get a UX designer, a product manager, a software engineer, a marketing manager, and a technical writer to join. Strategically, it should include the decision-maker(s) who has the power to reject the Sprint’s conclusions. A Sprint team must also be composed of people who will later work on the development of the product or service, to foster a sense of ownership.

Team members can make short presentations at appropriate times of the Sprint to share their knowledge on specific points. Outside experts can introduce new and welcome perspectives. The more knowledgeable your team is, the better able it is to find viable solutions.

Space (War Room)

Dedicate a space to your Sprint. The ideal place should support creativity, be well lit, isolated from possible external disturbances and large enough for everyone to work comfortably. It must be equipped with whiteboards and have many vertical surfaces to affix documents. All necessary supplies should be available: colour erasable markers for whiteboards, standard markers, pencils, paper, scissors, tape, sticky notes, etc.

Communicate the rules to participants: abstain from using phones as much as possible (and if you really need to take a call, step outside the room), keep laptops closed as long as they are not needed, etc. This process requires everyone’s full attention.

The five different phases are each assigned a day of the week, but this can be flexible: some phases shorter, others extended.

Monday — Understand

Before you start, it’s a good idea to break the ice. Ask everyone to introduce themselves and explain their interest in the project.

The first phase is devoted to understanding the challenge from all angles. This is a stage where presentations from outside experts can be very useful. The Sprint Master captures ideas and information on the whiteboard so that team members can keep them as visual references and inspiration for the rest of the Sprint.

At the end of this understanding phase, the team must agree on a well-defined objective, i.e. an ambitious but feasible part of the problem that can be solved in four days. It also defines “success metrics”--how to agree on what constitutes the success of the project or product. For an application, it may be the number of installations or the time it takes to complete an essential task.

Tuesday — Sketch

After a full day devoted to understanding the problem and choosing the objective of the Sprint, it’s time to focus on solutions. The day begins with inspiration: review existing practices (so as not to reinvent the wheel) to eventually remix and improve upon them. Each team member researches solutions implemented by competitors or industries with similar business problems. Team members share their findings with one another, then review the objectives and everything that has been collected on the boards. Everyone suggests their idea and each is submitted to the team’s vote. In the afternoon, each person works individually, taking the selected idea(s) they think is best to sketch their solution. You’ll also start planning Friday user-tests by recruiting clients who match the target profile.

Wednesday — Decide

On Wednesday morning, everyone submits their sketch of the solution to the other members for critical review. The team votes for the one they feel is most likely to meet the objective. It is not possible to prototype and test all the ideas; a decision must be made. Sometimes there may not be a clear winner. In that case, establish a list of criteria and, in light of these, examine the projects that stand out. The Sprint Master can help resolve disagreements and friction to build consensus. The afternoon is devoted to collectively establishing a storyboard, the step-by-step plan of the prototype.

Thursday — Prototype

Thursday is dedicated to transforming the storyboard into a prototype. Each person is assigned a specific task. For example, the UX designer prepares the assets, the product manager recruits users for the next day’s test, the engineer builds the prototype, the writer prepares an interview scenario, etc. In the late afternoon, everything should be ready for Friday’s test.

Friday — Validate

This week, you have created promising solutions, chosen the best one and built a workable prototype. It’s time to test it with users and learn by watching them react to your prototype. This day is also an opportunity to carry out, if necessary, a technical review to assess its feasibility. This can be done by bringing in an outside expert.

To conclude the Sprint, the team examines the result and associated practical learning. The prototype may not be an unmitigated success, but the team has learned a lot and you may have saved yourselves several months of work developing the wrong product. It can also be a quasi-success, in which case you have learned and gained ground on a new iteration. Finally, it can be a great success and you are ready to move on to the implementation phase.

Useful Resources

Sprint Book.

Are you persuaded that the Design Sprint commonly used by Google could solve some of your problems? Here are resources to learn more about the methodology:

Design Sprint Kit is Google’s website that describes the process. It includes a description of the phases of the Sprint, many ideas for activities that can drive the different phases, tips and tricks, useful tools, case studies, etc.

The Sprint book, co-authored by the creator of the method, Jake Knapp. This practical guide is the bible of all Sprint Masters.

This entry was posted in UX/UI Design
by Laurent Gloaguen.
Share this article