Design Sprint — What? Why? Who? When? How?

The current pandemic has put numerous businesses against the ropes, pushing them to reinvent in pursuit of survival. COVID-19 has challenged where and how companies work, how they engage with customers, and even the customers’ purchasing behaviors. Consequently, many of these companies, from diverse industries, have “turned to practices commonly associated with agile teams in the hope of adapting more quickly to changing business priorities.” Agile, once a software project management tool, is gaining traction across traditional industries that require innovative solutions, increasing their adaptability, and continuous learning.

This post focuses on the Design Sprint, a proven Design Thinking method invented by Jake Knapp (former Google and Google Ventures employee), with the purpose of “answering critical business questions through design, prototyping, and testing ideas with customers.” Arguably, one of the first steps a company can make towards creating a culture of innovation.

What is the Design Sprint?

Initially, the design sprint is a five-day intensive workshop used to “solve complex problems throughout co-creation, rapid prototyping, and qualitative testing with targeted users.” Though the tools and activities employed may vary, the goal remains the same: to progress from problem to tested solution. A cross-functional team comes together for a week, schedule 100% cleared, to deep-dive into a problem and design a 360° solution that may solve it.

Why should we do this?

Engagement. Speed. Clarity.

It generates engagement because it brings people from different areas together to collaborate and co-create a solution to the problem.

It sets a tight deadline that motivates the team to speed up, make decisions, and build a working prototype in 4 days. This is accomplished by having a testing day by the end of the week.

It provides clarity to the process. The design sprint allows you to see how real users react to your solution before you build the final product.

In the end, design sprints help you prevent time-consuming and resource-intensive solutions from failing. They guide the company through which direction to go and help avoid future pitfalls. Teams can take significant risks and test them before building these solutions.

Who is this for?

Design Thinking and Agile methodologies pave the way towards adopting a user-centered perspective. In an era of mass-customization, a design sprint gives first-hand insights on the reaction your target users may have towards a particular solution. Though born within Google and perfectioned for startups, the design sprint is now valid to produce and test ideas to solve problems independently of the industry or business.

When should we run a design sprint?

You should consider running a design sprint when:

• There is a complex and specific problem to solve and the solution will require a lot of time and money;
• Innovation is needed, as known approaches are failing to deliver the desired results;
• You need a working solution, fast.

Though most of the time it is used at the beginning of a new project, the design sprint is a valuable workshop at any stage of a project when the team faces a challenge that demands an innovative solution. You can find interesting sprint stories here.

How do we implement a design sprint?

Who participates? What do we do each day? Which tools do we use? What can we expect?

Selecting the right team to participate in the workshop and defining the problem to tackle are the two key milestones when preparing the sprint. The team, cross-functional, should include a Decider (the one that has the power to approve or kill the project), a Facilitator (the one in charge of running the sprint), and representatives from all those stakeholders whose perspective adds value to the solution (i.e. finance, marketing, tech, supply, and design). When working with early-stage startups that need a software solution, we team up a designer, a backend dev, a frontend dev, and one of our executives with the startup’s founding team.

For five days, we block the team’s calendar and deep-dive into the problem. Due to the nature of our business, at LoopStudio we have adapted the workshop to be run in a remote environment, making good use of tools like Miro that allow us to recreate the desired atmosphere. Yet, we still keep a physical whiteboard in our office.

The Design Sprint activities are spread into five different stages or days. Each day has a different purpose and list of activities.

Design Sprint blueprint — day by day

Source: LoopStudio archive.

1. The first day is about understanding. Understanding the client, the business, the problem, the users, and every team member’s point of view about the problem. Sharing information and spotting necessary research to be done. Defining the problem statement, the current situation, and the desired one, to finally agree on a critical path (meaning: minimum steps required for the user to solve the problem). All findings and assumptions must be included in a backboard, which will be updated as the workshop continues.
2. Diverge means “separate from another route and go in a different direction.” In other words, brainstorming. We use different activities that aim to unleash creativity and generate many ways of solving the challenge, disregarding how crazy they may sound. Our favorite ones are the Crazy Eights and Solution Sketch. Every member of the team must end the day with a solution sketch to share.
3. On the third day, our goal is to decide on the best ideas and finalize with a storyboard of your future prototype. Though an individual choice is promoted throughout the whole day, giving each member a vote and voice to explain, the Decider has the responsibility to choose the winning ideas. We like to use Silent Critique and Group Critique as core activities to explain, evaluate, and decide on which ideas from the solutions sketches are going to be a part of the final storyboard.
4. Once the storyboard is set, we are ready to prototype. It must be a super lean prototype, built in one day. The whole point is to cover the surface, enough to recreate the interaction of the solution with the user and receive feedback. For software solutions, we like to use tools like Sketch or Invision for our prototypes. After dividing the tasks, each team member adopts a different role to build a part of the prototype. By the end of the day, there should be a trial run of the prototype to detect mistakes and fix them before the big day.
5. Finally, it’s Friday! After a lot of hard work, the team has put together a compelling solution to the problem, and it’s ready to be tested by real users. The way you approach this stage depends a lot on what you are testing and with whom. Overall, the goal is to learn as much as possible from the users’ interaction with the prototype. We suggest preparing a set of questions to ask the user before, during, and after testing the prototype, as well as recording the user’s expressions, actions, and reactions while interacting with it.

This data is of great value. The learnings resulting from the sprint will serve as hardcore evidence when deciding which direction your project should go. By the end of the sprint, you will have stories of real users validating, or not, your proposed solution. A week’s time can prevent you from many future headaches and frustrations.

To continue reading on this topic, I strongly recommend going back to where it all began and read “Sprint”, the book written by the Design Sprint creators Jake Knapp, John Zeratsky, and Braden Kowitz. You will get a detailed explanation of how to plan and implement your design sprints.

Feel free to leave your own experiences and learnings with Design Sprint in the comments section, especially if you are doing remote ones! Or contact us to discuss your current challenges and coordinate your next Design Sprint.

PS: Knapp’s talk titled The Design Sprint: One Small Change to Create a Culture of Innovation is also a must-watch.

Andrez Ruiz 

  Find Loopstudio on KAPSLY