In 2016, Jake Knapp’s book Sprint: How to Solve Big Problems and Test New Ideas in Just Five Days debuted—and completely transformed how organizations around the world solve problems. Since then, the book has become a New York Times best seller and design sprints are a staple of the collaborative process.
Learning more about design sprints will help you understand how to apply it to your organization’s strategic challenges.
What is a design sprint?
A design sprint is a five-day process that solves strategic challenges associated with releasing a new product, feature, or service using design thinking principles, rapid prototyping, and user testing.
Design sprints came out of the work that Jake Knapp did at GV (formerly Google Ventures), which defines the sprint as:
a ‘greatest hits’ of business strategy, innovation, behavior science, design thinking, and more—packaged into a battle-tested process that any team can use.
Author of Sprint
Why are design sprints important?
One of the best things about a design sprint is the environment it creates. During that one week, you get to work shoulder-to-shoulder with people you probably only see when you walk past each other in the hall.
Because everyone that’s part of a design sprint is called an Expert (other than the Decider), it levels the playing field and dissolves any sense of hierarchy. This opens the door to transparent, collaborative discussion that’s focused on finding the best way to solve complex challenges.
The intimacy and speed of the design sprint allow larger companies to be agile. It sidesteps the bloated, slow-moving tendencies that become more common as organizations grow.
Design sprints empower organizations to answer critical questions through user research, experimentation, and validation from real customers. Avoiding assumptions, focusing on the user, and maintaining an experimental mindset means that products, features, and services are all validated quickly and with minimal risk.
Different types of design sprints
The beauty of a sprint is that you can apply the format and structure to so many different organizational challenges. So it makes sense that they’re used by agencies, universities, insurance companies, airlines, museums, and more.
At a ProductTank San Francisco conference, Kai Haley, Lead of Design Relations and the Google Sprint Master Academy, and Burgan Shealy, UX Design Lead at Google, delved deep into the adaptive nature of the sprint, outlining the four different types.
- Product sprint: This is what most people think of when they think of a design sprint. It helps you assess the viability of a new product or feature, or find new ways to tackle the flaws of an existing product.
- Process sprint: It may seem redundant at first, but sometimes processes need new processes (say that five times fast). The sprint format and structure allow organizations to tweak and refine their approval process, hiring process, or general project process.
- Vision sprint: This sprint focuses on solving the needs of your customers/users. Unlike a product sprint, it’s not specifically tied to product offerings.
- Moonshot sprint: Because it centers around a complete upheaval of what your organization offers or makes, this kind of sprint allows your organization to get way out of its comfort zone. It gives your team the space to think big and experiment, which might help you identify new opportunities or business models.
How to conduct a design sprint
Before you start your sprint, you need to determine three things:
- The challenge you’re solving (hint: the bigger the better).
- Who will be on the team.
- The time and space.
Knapp advises clearing everyone’s calendar for the entire five days of the sprint. During that time, there’s a no-devices rule in place (except on breaks). The process is pretty analog and makes use of whiteboards, paper, Post-its, and writing tools. He also recommends a team of seven or fewer that involves the following:
- Decider (this could be the CEO, head of design, product manager, founder, etc.)
- Finance expert
- Marketing expert
- Customer expert
- Tech/logistics expert
- Design expert
Once you know what problem you want to solve and have assembled your team and supplies, you can get to the fun part: the sprint.
If you don’t have access to the Sprint book, Google has a detailed breakdown of everything you need to create your own sprint, including checklists, resources, and templates.
Day 1: Monday
Your team agrees on a long-term goal, maps out the challenge, and decides which part of the challenge you can solve in one week.
Day 2: Tuesday
Your team derives inspiration from existing solutions and starts sketching various strategies you could use.
Day 3: Wednesday
Your team goes through the solutions you came up with on Tuesday and decides which one is most likely to solve your long-term goal. Then, you create a storyboard from the best parts of your sketches. This is the foundation for your prototype.
Day 4: Thursday
Your team creates a working prototype based on Wednesday’s storyboards. You’ll prepare the prototype for user testing.
Day 5: Friday
During the user tests, your team will receive feedback on the prototype from real customers. They’ll let you know what’s working and what’s not, informing your next steps.
At the end of the week, you can’t help but feel accomplished. So much of the regular work day and work week can feel insignificant because you’re not always able to see how the different pieces become the whole. But design sprints enable you and your team to do so much that you’ll look back and think: “Wow, we really did that.”
Design sprints made easier
From Day 1 to Day 5, InVision tools can power every step of your organization’s design sprint process.
Outline the challenges you want to solve with Freehand on Day 1. Use Boards to glean inspiration on Day 2. Sketch out wireframes on Day 2 and collaborate on storyboards on Day 3 using Freehand. Put a working prototype together quickly with Prototype and preview your work with Studio on Day 4. Keep track of and share your team’s design assets with Design System Manager. This way, when your team conducts user testing on Day 5, everything you need to channel that user feedback into the next iteration is already in one accessible place.