Innovation is hard. Oftentimes, though, the thing stopping us from creating great products isn’t a lack of ideas but finding a way to operationalize them. Moving forward to see if what we plan to make is worth developing further can be confusing. This problem can stump many teams and keep them from providing their users with continuing value. A design sprint is a great tool to help teams get out of their heads and create a usable product.
What Is a Design Sprint?
What Is a Design Sprint?
A design sprint is a workshop designed to help teams iterate on ideas quickly. The workshop consists of a cross-functional team that can answer the hardest questions that come up during development. The core team generally consists of product managers, designers, and engineers but can extend to almost any discipline. In fact, the process only gets better with more insight, especially from teams you rarely hear from.
Design sprints help a team get out of its own way by doing two things. First, it gives a team a process that has a finite goal. You have a set task for the day, and if you accomplish it, you move forward. This helps teams avoid wasting time “figuring out” so much and empowers them to get to work instead. The second important thing is that everything is time-bound. You have to finish this whole process in a week.
Finite goals and a time-bound scope are intimidating for teams, especially those who are used to working with unlimited time or without such clear constraints. The pressure that the design sprint puts the team under is a great way to get out of the rut that many teams get stuck in, however. There isn’t much time to quibble; you have to get what you need and move forward.
The movement that the design sprint forces us to embrace is much closer to how innovation should work. We’re trying something new, so we will mostly get things wrong.
Let me repeat that — we get our first iteration mostly wrong. How many times have you worked on a product for months only to see it get a fraction of the usage you expected? If we’re honest, that lack of usage happens a lot more than we care to admit.
That’s why the design sprint process matters. By using a defined process, you can tailor it to fit your needs. If something doesn’t work, try another method and tailor it to how your team works. By working under a time crunch, you are lowering the investment to see if the product you are creating is worth building or iterating upon. You didn’t spend six months on this - you can try again next week without much guilt.
- What does a design sprint look like?
- What are the stages of the design sprint?
- What does the finished product look like from a design sprint?
Well, stick around, and we’ll go over all three questions so that, after reading this article, you’ll be ready to try one with your team. To help make the design sprint process clear, we’ll go through it with Jane, a product manager (PdM) from BobCo as she commits to the process to help her team work on a new tool they wish to launch.
What Does a Design Sprint Look Like?
The design sprint process was created at Google Ventures in 2010 by Jake Knapp. He explores its history and processes more deeply in Sprint: How to Solve Big Problems and Test New Ideas in Just Five Days.
Jane found herself in situation at BobCo where teams were failing to communicate effectively. After a few months, she started to get a sense of how the team worked, but she identified a few problems and had just started getting the organizational trust to handle them. Two of the major issues were how long it took to gather data from the customer and a lack of connection to the team.
Jane knew from previous experience that a design sprint is a great way to help mend those issues, so she began to prepare a sprint with her design peer and engineering team lead. She also took the opportunity to invite a few folks from sales and customer support. She did this knowing they didn’t know much about the team or the product and that the development team could use their perspectives.
What Are the Stages of the Design Sprint?
A design sprint consists of six stages: understand, define, sketch, decide, prototype, and validate.
What Are the Stages of a Design Sprint?
- Understand
- Define
- Sketch
- Decide
- Prototype
- Validate
Understand — Are we working from the same place? Consider this the phase where the team can level set and make sure everyone is talking about the same problem. As the PdM, Jane took lead on this portion, making sure anyone that the team rarely interacted with (i.e., customer success and sales) had time to talk about their experiences.
Define — What problem are we solving? Problems are less like straight lines and more like Russian dolls, where each problem is inside another, bigger one. This phase is all about clarifying which problem you want to tackle and what outcomes you expect. Remember, we usually get this wrong whether we spend a day or six months on it, so the sooner we get clear and iterate, the better. Jane also took the lead here to make sure the outcome was tied to company and product strategy.
Sketch — How can we translate what’s in our head? Now that we have an ideal outcome(s), we have a place to start sketching out ideas. The goal for this stage is to get what is in our heads on paper. The rule here is more ideas the better, and the thought is the goal. For BobCo, Jane’s design partner, Dan, facilitated this portion to ensure they were generating ideas.
Decide — How can we focus on the solution? Once the sketches are out, it’s time to match ideas into a story. Deciding what ideas make sense and weaving them together gives everyone the chance to tell their part of the story and come up with a comprehensive picture. The goal here is to end up with an idea to prototype. Jane took this on with her engineering partner, Sarah, to ensure that they were talking about things that were feasible.
Prototype — How can we put something in front of our users? It’s time to build a prototype. The prototype isn’t a fully functional product; the goal isn’t to roll out something that is production-ready, but just finished enough to test the concept. Feel free to use whatever tool you have at your disposal to get the prototype down. Teams can use a webpage, a tool like Figma, or even pen and paper. Sarah and Dan took care of getting something simple put together to show potential users.
Validate — How do we make sure what we did was useful? It’s showtime. Time to put the prototype in front of customers. This is where the team learns about the past week and sees what’s useful and what isn’t. When you do this, you’re able to get direct insights from the people who will use the product to make the changes you need. You’ll often see critical issues your team missed or a more important problem to solve. This is good! Think of it as taking a week to discover that we could go down the wrong path instead of six months. Jane took lead on the interviews and took along four other people in the workshop (one each from design, engineering, sales, and customer success) for every interview to tie everything together.
What Is the Finished Product From a Design Sprint?
Once you’re done with the design sprint process, the team should have a prototype or insight on a better problem to solve. From there, you’re able to pivot into building something or doing another design sprint to see another solution.
Either way, the team itself is much more knowledgeable from getting direct customer contact on a problem instead of guessing. Another benefit of the design sprint is just that: The team gets visibility on how other functions work in the business. By working together so closely, people can get at least a surface understanding of how other folks spend thier time. This visibility grows team empathy and trust.
The process did this at BobCo. Engineering got to understand what customers do when using the tools they built. The designers got to hear about the customer success issues directly, and they were able to make clear decisions. Jane got a chance to catch up to sales, and both sides were able to see why tradeoffs happen.
Design Sprints Work
As product development teams, we make mistakes. These mistakes aren’t because we’re incompetent, but mostly because we are shooting in the dark. Design sprints are great to get teams moving to do build something, measure its success, and learn how to make it better.
