What is a Design Sprint?

By Danny Nathan

What is a Design Sprint?

The Design Sprint: An Overview

The Design Sprint is a (typically 5-day) process for testing new ideas, validating products, and solving business problems. Originally created by the team at Google Ventures (GV), the Sprint framework was designed to condense the process of defining a problem, creating solutions, and testing with users into just one week.

By bringing together a small team of key stakeholders for this intensive period, we democratize the problem-solving process by placing participants on an equal footing, regardless of title, standing, or office politics. Each participant has equal opportunity to champion a solution to the problem at hand and share with the group; however, the ultimate decision-making power is placed in the hands of a single person (aptly named the Decider for the duration of the Sprint). The exercises in a Design Sprint are explicitly geared toward minimizing the often endless debate and conversation that slows down a traditional group brainstorm.

A variety of well-known companies and startups have used the Design Sprint process to help them execute quickly and pivot with purpose on their way to success, including: Uber, Slack, Blue Bottle Coffee, Flatiron Health, Airbnb, and more.

Our Design Sprint Process

At Apollo 21, the Design Sprint process varies slightly depending on the type of engagement you’ve arranged: either a stand-alone Design Sprint, or a Sprint that’s part of a larger, ongoing project.

Our Standalone Design Sprint Process

If our engagement is limited to a Design Sprint, then our process typically takes place over a 3 week period with the bulk of the work happening during the second week when we execute the Sprint itself.

In the week leading up to the scheduled Sprint, we will work with you and key stakeholders to manage the preparation process and answer any questions the team may have in order to set expectations for the Sprint week.

The week of the Design Sprint breaks down roughly as follows (there is some flexibility in scheduling, and we do have experience shortening the Sprint process to fit your needs):

Sprint Day 1

Morning: Discuss and map the key problem. Outline challenges and opportunities.

Afternoon: Interviews with internal and external stakeholders and domain experts.

Sprint Day 2

Morning: Disruptive inspiration demos. Select an area of focus.

Afternoon: Ideation and individual solution sketching.

Sprint Day 3

Morning: Review and vote on presented solutions. Decide on idea(s) to prototype and test.

Afternoon: Storyboard the selected ideas in preparation for prototyping.

Sprint Day 4

Morning: Work as a team to prototype the selected solutions. (Everyone on the Sprint team contributes.)

Afternoon: Finalize prototype. Dry run of user testing interviews.

Sprint Day 5

Morning: User testing interviews and note taking.

Afternoon: Continue user testing interviews. Discuss findings and define next steps.

In the week following the Design Sprint, Apollo 21 will create a recap document that captures the Sprint process (on a day-by-day basis) as well as all of the collateral and ideas generated by the participants. This will be delivered to you as reference material, and may provide the foundation for future Sprint activities. We will also be available for one or two follow-up calls to discuss next steps and help your team prepare to move forward based on the learnings from our Sprint.

Our Design Sprint Process During Longer Engagements

At Apollo 21, we also use the Design Sprint framework as a means to kick off longer engagements. This process helps us clearly define the long-term goal of a project as well as the initial requirements for an MVP build. In addition, the user testing interviews offer an early measure of validation to determine next steps.

For these types of engagements, we begin with a Discovery Session ahead of our scheduled Design Sprint. This session allows us to clearly define the problem which we’re aiming to solve. The Design Sprint then follows the same steps outlined above for days 1-3, after which we deviate slightly. For these engagements, the Apollo 21 team takes on the implementation of a light-weight, clickable prototype with the help of our design team. This process takes place over a couple of days following the Design Sprint. Once we have reviewed the prototype and have sign-off, then we (collectively) schedule user testing interviews to get valuable feedback on our solution.

Once we’ve collected this feedback, the Apollo 21 team works with the project owners to determine next steps and prepare for development of an MVP product for future launch.

Remote vs. In-Person Design Sprints

Our team has extensive experience hosting both in-person and remote Sprints, and each has advantages and disadvantages. A remote Design Sprint accommodates today’s social distancing needs while also limiting the travel necessary to get a Sprint team together for the duration of a Sprint.

An in-person Design Sprint, on the other hand, is an excellent team-building exercise. These intensive, week-long efforts create camaraderie and cultivate a sense of “working in the trenches” alongside other key stakeholders. In addition, being together in a physical space helps spur conversation and limits participants’ abilities to “hide behind a screen.”

Both remote and in-person Sprints have merits, and neither should be discounted with regard to generating valuable outcomes.

Design Sprint Requirements

The Sprint Team

Your Sprint team should consist of 3-7 stakeholders across relevant teams within your organization. One of the key roles in the Sprint is the Decider — this role should be assigned to the person in the group who is most prepared to take responsibility for hard choices throughout the Sprint process.

Due to the intensive nature of the process and the manner in which each day builds on the previous day’s work, it is ideal to have the members of the Sprint team involved throughout the entire week. Participants should make every effort to clear their schedules for the duration of the Sprint.

In addition, it can be helpful to include additional participants specifically on Prototyping Day (typically Thursday of the Sprint) to help with the quality of the prototype. This may include designers, developers, data scientists, etc. These extra participants are not a requirement, but can help to improve the fidelity of the prototype used in testing on Friday.

Space Requirements (for in-person Design Sprints)

The Sprint team will need a space that’s available without interruption for the duration of the Sprint week. White boards are hugely beneficial throughout the Sprint process; the selected space should either include white boards or at least clear wall space to accommodate a temporary solution. In addition, for the final days during which the team is conducting user testing, a small room for conducting interviews may be helpful.

Materials Requirements

Materials needed to facilitate the Sprint process include: sharpie markers, whiteboard markers, pens, pencils, blank white paper, post-it notes (more than you’d believe!) in varying sizes, tape, large & small dot stickers, etc..

For remote Sprints, participants will need less physical materials as we’ll use a “digital whiteboard” for collaboration.

User Testing Compensation

Depending on who is asked to participate in user testing, compensation may be warranted. (If testers are expected to be existing customers/partners, this may not be necessary.) It is generally acceptable to make these payments in the form of cash, cash gift cards, or retailer gift cards (such as Amazon). It is advisable to have backup compensation available for those who show but aren’t needed.

The White Paper

Click here to download our white paper.

Download

Subscribe