A design sprint is a methodology invented by Jake Knapp and Google Ventures used to validate ideas through design, prototyping, user testing, and collaboration in only five days. While it won’t leave us with a finished product, it’s debatably the fastest and cheapest way to validate business strategies or product ideas with real users.
It’s a low-risk/high-reward process that offers a more structured and more effective approach to creative thinking compared to traditional brainstorming. The design sprint methodology has been adopted by top companies such as Medium, Slack, and IDEO as well as Google Ventures and the many successful companies they’ve invested in.
Warming Up for the Sprint
5-day design sprints can be intense, but they’re also fun, exciting, and very insightful as long as the sprint process goes smoothly. In order for this to happen, some planning is required.
Recruiting the Team
A design sprint is run by a facilitator, or “Sprint Master.” Their first objective is to clarify the problem that needs solving and recruit a team to conduct the sprint.
A sprint team usually consists of only 5–7 members, which makes managing the team easier. It’s important that these members have diverse skillsets so that we can approach the problem with a broader spectrum of opinions; hence, a sprint team usually consists of a facilitator, a designer, a developer, a customer service representative, and a marketer.
For remote design sprints, the facilitator should ideally recruit members from similar time zones (or as a last resort, use an app like Every Time Zone to decipher the “time zone sweet spot” where everyone is awake and available at the same time).
After the team is recruited, name one member to be the decider—this person will make the final call on all important decisions. A decider doesn’t have to be a high ranking officer in the company, just someone whose decisions are trusted by the rest of the team.
- A facilitator, to ensure that the team stays on track
- A customer service representative, for user insight
- A designer, for their knowledge of design software and UX
- A developer, for their understanding of any technical limitations
- A marketer, who can determine if the solution has a market value
- A decider, who’ll have the final word on decisions (assigned to one of the above)
A facilitator should ideally book a meeting room for the week, as it’s better to keep the design sprint team isolated from the rest of the company and focused on the sprint.
Remote Teams: Ensure Good Equipment and Surroundings
Each team member should be in a can-talk environment (for example, if using coworking spaces, other members of the coworking space should be okay with us talking throughout the day). A good internet connection and microphone are also essential.
If some team members are in-house while others are remote, consider purchasing a conference microphone (an omnidirectional microphone that sits on a table).
Tools for the Design Sprint
The team will need a way to share their notes, check each others’ schedules, and most importantly, communicate with one another. A natural choice of tools for these tasks is the G Suite, as Google offers a wide range of tools that work seamlessly under a single login, and where team members and documents are super easy to manage.
The tools we’ll need for a design sprint are:
- Google Hangouts, for group calls
- Google Calendar, for checking schedules
- Google Docs, for taking notes, and
- Google Sheets, for recording the user test results
As well as the G Suite tools, we’ll also need:
- A whiteboard (or if the team is remote, a digital whiteboard such as Mural, Google Jamboard, or RealtimeBoard)
- A prototyping tool such as InVision, Marvel, Sketch, Axure, Figma, or Balsamiq
- Duco or Design Sprint Kit, a cheat sheet used by the facilitator
- Pen and paper, for sketching ideas independently
- A snack, because design sprints can be fairly exhausting!
Once we check every item off this list, we’re all set to start our design sprint on Monday. It’s worth noting that due to the natural time constraints of design sprints, everyone on the team should understand the design sprint process beforehand.
The first day of the sprint is dedicated to reverse-engineering the problem. Reverse-engineering is the process of deconstructing the problem in order to understand its root cause, (and in turn, the solution).
Reverse-engineering the Problem
After agreeing on a long-term target (e.g., to increase signups), draw a customer journey map on the whiteboard that depicts the various ways that users might reach this target. Place the users on the left side, the target on the right, then write down all of the steps in between. To keep the whiteboard somewhat organized, the facilitator should draw the map while the rest of the team suggests ideas. This process will set the foundation for the rest of the design sprint, so we should take our time here.
Before moving on, the facilitator will discuss the customer journey map with each team member individually, tweaking it if necessary.
Creating “How Might We” Notes
The next step is to add How Might We notes (HMW for short) on the whiteboard. Where each step in the customer journey is likely to come with its own stumbling blocks, HMW notes are formulated as a “How might we…” question on a sticky note—for example, “How might we make the signup form easy to use?” These stumbling blocks are opportunities for improvement and will determine the direction of our MVP design.
Focusing on a Specific Customer Journey
We’ll need to organize the HMW notes by similarity and consolidate them, as we don’t want our whiteboard to become too cluttered. With a cleaner whiteboard, assign each team member two votes to decide which HMW notes should be a high priority.
Once the voting is over, add the winning HMW notes to the customer journey map and discuss which journey to focus on for the rest of the sprint (other journeys can be explored in another sprint at another time). The decider ultimately has the final decision.
Planning Ahead: Finding User Testers for Friday
During the day, a nominated team member should begin looking for user testers because, on Friday, we’ll want to test the solution that we’ll build on Thursday. It’s recommended that these interviews be conducted face-to-face, or using remote user testing tools such as Lookback and UserTesting (which conveniently integrate with prototyping tools Marvel and InVision respectively).
6–10 interviews is a reasonable amount. Schedule the interviews for about 10-ish so that there is enough time to review them at the end of the day.
Tuesday is about finding a solution. Get ready to start sketching!
First things first, get inspired. Most innovations are made by remixing old ideas, so try to explore already-existing solutions to similar problems. While the team suggests solutions to look at, the facilitator will place viable solutions on the whiteboard.
After that, each team member will choose a section of the customer journey to sketch by themselves, using a method known as The Four-Step Sketch.
The Four-Step Sketch
The four-step sketch approach to prototyping is designed to systematically turn abstract ideas into concrete solutions via rapid iteration. They don’t need to be perfect.
- Step 1: Notes—start with 20 minutes of note-taking
- Step 2: Ideas—for another 20 minutes, sketch some rough ideas
- Step 3: Crazy 8s—sketch eight variations of the best idea, one minute per variation
- Step 4: Solution Sketch—create a three-step storyboard of the solution, spending 30–120 minutes adding more fidelity to the chosen variation
After completing the exercise, wrap up the day by handing over the sketched solutions to the facilitator. (Remote teams: Upload them to an InVision Project or Mural Whiteboard.)
Wednesday is about selecting the best solution and creating a final storyboard.
Once each team member has privately reviewed the sketches, discuss each solution as a group, spending no more than three minutes per sketch. Then take another vote, this time deciding on which solution will be storyboarded and prototyped for user testing.
Next, we’ll need to prepare the storyboard for prototyping by increasing the fidelity. It’s best if the designer recreates the chosen storyboard as a high-contrast wireframe, as we don’t want to overthink the design due to our time constraints. A simple or “ugly” UI will do fine, as long as the user tester is able to visualize and understand it.
It’s up to the designer whether to use Axure, Balsamiq, or something else entirely to design the wireframe. Even a design tool like Sketch or Adobe XD would be suitable, as long as we’re focusing on the UX and choosing function over form.
On Thursday, we’ll turn this wireframe into a clickable prototype!
Before anything, we’ll need to confirm the interview times with the user testers. As mentioned earlier, aim to start them at around 10–11 AM so that we have enough time to review the interviews (and the effectiveness of the overall design sprint) afterward.
Assign at least one team member (preferably the marketer or customer support representative) to write a script for the customer interview. This person will create a list of questions in a Google Sheet to ask the user tester as they review our prototype.
Meanwhile, the prototyping designer will begin turning the wireframe into an interactive prototype with the rest of the team’s input and direction. It’s up to the designer which tool should be used, and also depends on the tool used to create the wireframe.
For example, if Axure was used to create the wireframe, then we could also use it for prototyping, especially since we can preview the prototype on mobile afterward.
If the wireframes were sketched on paper, Marvel offers a dead simple way to import and recreate them before turning them into interactive prototypes and conducting user tests with their Lookback integration.
If the wireframes were created in Sketch or Photoshop, the way to go would be InVision as it’s easily the most widely-adopted and full-featured prototyping app available today. It also allows for live previewing and directly integrates with UserTesting.
If created in Adobe XD, then we can also use it to create and user test our prototype without any additional tools.
Friday—the final day of the design sprint. Our prototype is ready for user testing, and we’ll start the day by making sure that the team has the prototype and script at hand.
After that, we’ll begin the interviews using the The Five-Act Interview method:
The Five-Act Interview
- Act 1: Friendly Welcome. Make the tester feel comfortable and welcome, then explain what user testing is and why we’re doing it.
- Act 2: Context Questions. Ask broad questions to learn more about the user and their background, then gradually steer the conversation towards the prototype.
- Act 3: Introducing the Prototype. Make sure that the tester understands why something might not work as expected and that there are no wrong answers when it comes to feedback. We want to encourage honest, candid feedback.
- Act 4: Tasks. Let the user figure out the prototype for themselves. Ask open-ended questions to encourage the tester to think aloud.
- Act 5: Debrief. Ask the tester to summarize their experience. Don’t forget to thank them for their time, and request if we can follow up if needed.
During the customer interview, record the answers in a Google Sheet. Once all of the interviews are complete, try to identify common insights and label them as positive, negativeor neutral. From this, we’ll be able to decide whether or not our prototype was a good solution to the problem, and if so, identify areas of improvement.
While design sprints won’t result in a finished product, they do help validate ideas quickly and affordably, providing a wealth of insights in a relatively short space of time. Before wrapping up the sprint, decide what to do with the prototype.
Will we improve the prototype and conduct a follow-up sprint?
Will we tackle a different customer journey in another sprint?
A huge benefit to learning how to conduct an effective design sprint is that we can reuse the technique to develop and experiment with ideas time and time again.