What are Design Sprints?

Design sprints were born out of Google Ventures about 5 years ago, and the developers of the process considered the build and measure component of design the foundation for creating successful products. By building on the familiar principles of design thinking, they provide an executable system that turn questions and problems into testable prototypes and direct customer feedback. The result is a practical and objective method for companies to build and learn from customers quickly.

Each design sprint lasts 5 days (see diagram below), with each day focused on a critical process within the system arc. Let’s jump in and look at a breakdown of the activities of each day:

Day 1 – Map and Target

Developing the Map (How Might We’s)

Starting immediately with design thinking and brainstorming can sometimes be a roadblock, since defining the challenge or problem is impossible without an awareness of how it fits into the greater customer experience. For this reason, the mapping exercise is the focus of Day 1 since it allows the sprint team to define the problem and choose a target before beginning to solve and sketch in Day 2.

The goal of the mapping exercise is to simplify lots of touch point complexity into a single diagram. The ability to reference a visual model of how customers move through a product or service will keep everything in context when solving for gaps, pain points, or disruptive experiences and processes. The way Jake Knapp (previously of Google Ventures and widely considered the founder of the design sprint process) describes the map in his book “Sprint”:

“The map is a big deal throughout the week…you’ll use the map to narrow your broad challenge into a specific target for the sprint. Later in the week, the map will provide structure for your solution sketches and prototype. It helps you keep track of how everything fits together.”

It’s important the experts that understand the company’s product or service are part of the sprint team, including a representative from the product marketing, development, and customer experience teams, along with a decision maker that can effectively get everyone on the same page. Getting all the players involved early becomes critical down the road as they help each other decide which part of the map they’ll focus on during the week and work to define solutions together.

Defining the Target

After interviewing the product and customer experts and organizing the map, the next step in the process is to identify one target user and one target event on the map. This is the critical moment of the target customer’s experience that requires the attention of the design team. It’s important to hit this target precisely, since the rest of the week’s sprint will focus on it.

Day 2 – Solve and Sketch

Day 2 is all about brainstorming solutions. It starts with the team looking at what’s been done, what works, and what can be “remixed and improved”. It ends with one of the most effective (and oldest) design techniques in the book: sketching.

It’s uncommon that re-inventing the wheel is needed or even useful when determining a solution for a given target customer and target event. This is where remixing and improving comes into play. There are many opportunities to remix and improve that go undiscovered by designers, and Day 2 methods like list creation and lighting demos create opportunities for capturing these opportunities and working as a team to identify potential game-changing inspiration that can empower the user experience.

Next up is sketching. Design sprints specify a four step sketching process that emphasizes critical thinking over artistry, so it should help those in the room who don’t aspire to be the next Bonheur to relax. Plainly put, everyone in the room should be more than capable of sketching solutions. The sketches become the fuel for the rest of the sprint, so much so that it’s surprising to look back after testing prototypes with customers and realize that all the team’s progress began a few days ago with some simple drawings.

Day 3 – Decide

Based on the sketching process completed on Day 2, during Day 3 the group will brainstorm together on which solution is going to be prototyped in Day 4. As anyone that’s ever been a participant in one would probably agree, group brainstorming sessions like these can be difficult. The conversation flow in the room can easily devolve into this:

Image source: “Sprint” by Jake Knapp

The design sprint methods for Day 3 are intended to transform this communication cobweb into something much more productive, with a consensus group decision being the end goal. Using these methods, the process of providing critiques of the solutions and coming to a final decision should look something more like this:

Image source: “Sprint” by Jake Knapp

Once the group has critiqued and chosen a particular solution, it’s tempting to dive right into the prototyping process. Luckily, Day 3 includes a group storyboarding exercise that helps define the solution and avoid any unanswered questions from becoming a future time drain. This allows the entire group to visualize the user interaction behind the solution and identify any unknowns before the prototype process starts. An additional bonus about storyboarding is you don’t need to be a professional designer to complete them, so the process will be effective even though it’ll most likely be new to some members of the group.

Day 4 – Prototyping The Solution

The Design Sprint Prototyping process outlines four basic principles to keep Day 4 as focused and efficient as possible:

1. You can prototype anything (literally)

“Sprint” explores a case study of how Google Ventures worked with the Savioke design team to build a prototype that allowed the company to test hotel guest’s reactions to a service robot that delivered amenities to their room. The team chose two major solutions to test: a simple set of eyes to display on the screen, and a “happy” chime that provided a pleasant life-like response to the guest tapping a button confirming that their items had been delivered successfully.

The prototype was crude when compared to the final version (shown above). A mockup of the eyes was displayed on an iPad mounted to the robot. The robot’s interactions itself were extremely limited for the first prototype test – it could simply open it’s carrying hatch and move back down the hall after the delivery. It’s movements were not autonomous, but were instead controlled manually by an engineer with a playstation controller.

The focus should be on what matters to the target customer within the target experience, and the sprint team shouldn’t worry if the first version isn’t pretty.

2. Prototypes are disposable

In order to move fast and make bold decisions, it’s important that everyone keep in mind that the prototype might receive poor reactions and feedback during the test. This is okay. A prototype should be built quickly, tested, changed based on customer feedback, then tested again. A home-run on the first round of testing is rare, and the validity of the testing results should be considered suspect if this occurs.

3. Build just enough to learn, nothing more

In order to build a prototype quickly enough that it’s ready to be tested the next day, the importance of this principle can’t be understated. Since only a specific solution is being tested and not the entire product feature set, scenario based prototype design is key.

4. The prototype must appear real

The prototype doesn’t need to function the way the final solution will. The only important thing for the purpose of testing is that the solution appears real to the participant (see Savioke example above).

Day 5 – Test and Learn

Day 5 provides the team the opportunity to test the prototype with customers. Validation testing provides objective customer feedback for designers and decision makers, and thus is considered a critical step in the Design Sprint.

In his book “Sprint” Jake Knapp specifies that user research expert Jakob Nielsen determined that 85% of usability problems were observed after just five tests based on 83 of his own product studies.

Image source: “Sprint” by Jake Knapp

Based on this data, Knapp recommends that 5 tests be conducted per sprint. These tests can all be scheduled on the same day with enough time for a short break between each with a full team debriefing session to close out the day:

Image source: “Sprint” by Jake Knapp

A seasoned UX designer with a familiarity of proper UX interviewing and usability testing principles should conduct each test. It’s recommended to have a document camera record each session and send a live feed to the rest of the team, who can observe in real time. This allows everyone to be on the same page quickly and prioritize the major issues that come up during each session. In this way, the debriefing session effectively allows the team to make decisions together before the fresh findings get stale over the weekend.


The Takeaway

Design Sprints have now been around long enough to demonstrate their effectiveness, and companies large and small are achieving great success by implementing them. The Solutions center recommends working with a seasoned design team that can guide your company through the process with the goal of launching better products, features, and solutions that your customers will love. If your team is interested in running a design sprint, set up an initial discovery meeting today!


CRi Solutions focuses on UX Research and UI Design as critical processes in building quality products that customers love. We provide both research and design projects as stand alone services or combine them with our mobile and web development services. If you would like more information email us at gig@clientresourcesinc.com or click on the contact bubble in the bottom right of your screen.