The design sprint is one of the most relied upon yet formidable processes a designer goes through. Teams use design sprints for many different reasons like at the start of a new project, when time is on the line, to get a product or team unstuck, or to leverage new data or research. Some teams use design sprints as shortcuts to tackle big problems quickly, while other teams see design sprints as the most effective way to complete any project. The design sprint idea and methodology uses simple prototyping, user research, and user testing to solve complex problems. Since its inception, teams around the world have adopted, amended, expanded, and molded the original design sprint concept to meet their own needs.
In this post, we’ll look at how design sprints were first created, provide a detailed plan for planning a design sprint, and give you the how-to for running your sprint.
A design sprint is a tried and true methodology for solving big problems through designing, prototyping, and user research and testing. The sprint is set to run for a definite period, usually five business days, so that teams are encouraged to quickly align under a shared vision with defined goals and deliverables. The design sprint follows six phases: Understand, Define, Sketch, Decide, Prototype, and Validate.
The design sprint methodology was developed at Google out of a need to build UX culture and design leadership across the organization. The core methodology is inspired by thinking and processes from traditional UX practice, IDEO, the Stanford dSchool, business strategy, and psychology. The modern framework is flexible so that teams in any organization can adapt it to meet their specific needs.
Preparing for a design sprint is just as important, if not more important, than the sprint itself. Don’t expect to get it all done in one day. For each day you’re planning to sprint, set aside a day for prep. Planning and preparing properly ensures you’ll get the most out of every moment once you start the sprint.
The sprint brief will act as a guidepost for the team throughout the sprint. It should list your defined goals (the problem or problems you’re solving), deliverables, agenda, and methods. It should also provide the sprint team with background for the project and any user research that’s already available. You don’t want the team to waste any time looking for answers you already have, so be sure to include all relevant details in the sprint brief.
A design sprint is meant to tackle one big challenge at a time, so your brief should clearly reflect that. Anchor your sprint with one clear question to answer. Instead of “Make our homepage more shoppable,” a better framing is “Redesign a user flow to increase conversion.”
Who should be in the room? Keep groups to five to seven people, and break larger teams into small groups that are all working on the same problem. More people creating and iterating means more ideas and multiple versions of a prototype.
Your design sprint team must include the people who are responsible for carrying out the work after the sprint. Design sprint teams typically include a UX designer, a user researcher, a product manager, a developer, and key members of leadership.
The simplest way to build your agenda is by following the six phases of methodology—Understand, Define, Sketch, Decide, Prototype, and Validate—but depending on your timeline and goals, you may need to modify to meet your needs. The design sprint team may already have a deep knowledge of the space and problem you’re working on, so you’d want to devote less time to the Understand phase and possibly reallocate the time to prototyping.
The sprint brief is just one important visual. Whether you choose to put together a deck or another preferred visual, make sure you have all anticipated references at hand. That includes screenshots of current websites, inspiration sources, data, research summaries, and anything else the team might need to know or want to quickly reference throughout the sprint.
Robust user research is what your design sprint team will rely on for clues on how to build a prototype. Without a few hints about what people want, the process could go off the rails fast. Exploratory research before the sprint can help guide new ideas and compiling existing data can help uncover how people are currently using the product, and the changes you might need to make to shape that behavior. This compiled data will help kick off the Understand phase.
In addition to the compiled data, you may want to line up key speakers and external experts who can share a fresh perspective on the problem the team is working on. Google’s design sprint methodology calls these Lightning Talks since they’re meant to be a concise presentation lasting between 10-15 minutes. Helpful topics might include a summary of customer research from someone on the support team, competitive audits from an analyst, and a review of product performance from a product manager. You’ll need to reach out to and invite these presenters ahead of time, and be flexible if someone can’t join in person. An audio or video call is perfectly fine; any method that helps get the sprint team all the info they need.
A design sprint is all about creativity, so you want your meeting space to reflect that from the moment participants walk in. Find a spot with lots of light that you can make your own. That might mean moving furniture or taking over whiteboard walls. Don’t feel locked to the space for the duration of the sprint either. Break up the week with a field trip to a coffee shop or nearby park.
An ice breaker is a great way to get everyone comfortable with each other and jumpstart creative thinking. If you don’t already have an idea for a warm up, a simple search will yield tons of options.
Have all the necessary supplies ready to go before day one of the sprint. You don’t want an awesome idea to get lost because someone didn’t have a pen. Start with the list below and add anything else that might help support your unique design sprint:
A few days before the design sprint is set to start, prepare participants and set expectations. Reconfirm everyone who accepted the invitation will, in fact, be participating throughout the sprint. If people are dropping in here and there, the process isn’t nearly as effective. Share the agenda and schedule along with any other special requirements such as turning phones off.
Again, a design sprint is what you make of it, and what you need to get out of it. Your sprint could last three days instead of five. It might devote just one morning to the Understand phase if participants already have a deep knowledge of the space and problem. Here we’ll cover every phase of the traditional design sprint methodology so you have the full gamut when it comes time to organize your design sprint.
The Understand phase is where all design sprint participants create a shared knowledge base. That base comes from provided info in the brief, Lightning Talks, user interviews, and exercises like Experience Mapping where the team maps out step by step the experience a user has within a problem space or context, and How Might We which encourages the team to reframe pain points as opportunities. See Google’s entire compilation of Understand activities here.
In the Define phase, the team uses everything they learned in the Understand phase to zero in on a specific focus for the sprint. They’ll also define goals, success metrics, and signals. One popular Define method is The Golden Path, which requires participants to list out the possible user stories if the product already exists, or if the product does not exist yet, to sketch the ideal path through the new product. See more Define methods here.
In the Sketch phase, the sprint team individually generates as many ideas as possible. From there, the team works together to narrow down the ideas to one expanded Solution Sketch per person. One popular exercise is Crazy 8’s, a fast sketching exercise that challenges people to sketch eight different ideas in eight minutes. Check out more of Google’s suggested Sketch methods here. You can also take this activity digital with Figma and have fun watching what everyone comes up with in multiplayer mode. This is also handy if you are running a design sprint with remote teammates.
The Decide phase pushes the design sprint team to land on a final direction that everyone will work to frame up and build out during the rest of the sprint. Dot Vote is a simple exercise that gets to a decision quickly. Everyone gets three minutes to present their solution while the rest of the team can ask questions. Then, with all sketches hung up on the wall, each team member gets three total votes, represented by dot stickers. The sketch with the most stickers becomes the sprint focus. If you’ve already done your Sketch work in Figma, create a Figma component to use for dot votes. Here’s more Decide methods to try.
In the Prototype phase, the sprint team works together to create a prototype of the concept. Full product prototypes take a lot of time, but here we’re focused on speed and creating a representation of the solution that’s just detailed enough to get a response from a potential user. This usually means mapping out the exact flow and including only the steps you want to test. You can easily create prototypes in Figma by simply ordering frames on your screen or linking objects with connectors. If you’re looking for more ways to expand your prototyping skills, check out these tips.
In the final phase, the sprint team will use their prototype to conduct user research. Crucial notes during this process include user feedback and stakeholder and technical feasibility reviews. The sprint will end with a validated concept or a concept that still needs improvements, but comes with helpful feedback notes. Validating is all about getting the prototype in front of users, but there are a few different approaches you can take.
A design sprint is a kickoff to a larger project, so next steps after a sprint wraps should be clear from the beginning. Project or product managers should be able to provide clear action items to the team members responsible for seeing the project through. During the sprint, be sure to take ample notes and photos of the team’s work so that you can provide everyone with a complete summary of the process afterward.
Sprints are hard work! End the sprint with a mini celebration to help the team unwind after several days of intense effort.
For more support for collaboration, brainstorming, and prototyping, invite Figma to your design sprint, too. Use Figma as an online collaborative whiteboard; discover, design, prototype, iterate, and comment all in one tool; and get early feedback quickly with the Figma wireframing kit.