How to run an effective design sprint

Running a Design Sprint can be an effective way to solve problems and validate ideas at the earliest stages of product development.

Let’s take a practical look at how this process can help you understand customer problems, develop an effective prototype and surface actionable insights from users.

What is a Design Sprint?

A design sprint is a one-off, time-boxed process during which you come up with a solution to a problem or idea that your business is facing. They’re frequently used at the start of a big project or new feature, and can help kickstart your process into action. The goal is to leave with something tangible and validated that your team can start working on immediately.

Many companies use design sprints, including Google, the United Nations, Apple, and even the NBA. And for good reason – IBM reported they had a 300% increase in ROI after they started incorporating design sprints.

If you’re interested in running a design sprint, you’ll need to choose a methodology, gather some supplies, pick a target, and recruit some team members. You’ll also need a way to validate and collect your results.

Please note: A Design Sprint isn’t the same as an Agile Sprint. For more information check out our post on how to run user research in Agile Sprints.

Design sprint methodologies

As the popularity of design sprints has risen, so has the number of methodologies.

Pick a method

The most common design sprint methodology was created by Jake Knapp, when he was at Google Ventures, named simply as Design Sprint. The Design Sprint takes place over five days. During that time you brainstorm, diverge, converge, and finally prototype and test an entire idea. Design Sprints are great if you can wrangle five relevant team members and stakeholders for an entire week of heads down progress.

Several teams, such as AJ&Smart or InVision have created modified design sprints, aimed at condensing the process down to four, or even three days. Modified design sprints are a great way to get your toes wet, but be prepared to do extra work before and after the sprint.

Or choose your own adventure

Every team works together differently. The Design Sprint is a proven process, but sometimes it just doesn’t work for your team. Consider making modifications to them, but eventually you might want to try your own.

Choose a combination of convergent (working together towards a goal) and divergent (working separately to explore) activities and make sure to schedule some time to validate your results.

Gathering supplies

The complete list of supplies will depend on your methodology, but at a minimum, you need the following:

• Whiteboard(s) or Easel Pads for group collaboration. These allow your team to contribute together in a ‘big picture’ way. Set up all the whiteboards ahead of time and make sure you’ve got a few different colored markers. If you’re using easel pads, set them up ahead of time, so you don’t have to waste time during the session. (Also make sure your markers won’t leak through!)
• Printer paper for individual efforts. Notebooks or anything bound has a certain permanence. You want to be able to tear, move, and write on individual efforts. Loose-leaf unlined paper is best. I generally grab a ream of printer paper on my way to the first day.
• Post-it notes for random thoughts and small ideas. Post it notes can be attached to whiteboards, loose-leaf paper or just kept by individuals. Having something easily stackable helps when trying to move things around.
• Snacks. Collaboration takes up a lot of cognitive energy. Keep your team fueled by having a few different snacks on hand. Healthy-ish snacks will keep them less sluggish.

You might also want to bring:

• Dot stickers or another way of marking good ideas
• Sharpies (harder to obsess over small ideas when you’ve got a fat marker)
• Timer (you can use the one on your phone, but you might get distracted)

Get all of your supplies together ahead of time and in one place. Ideally, you’ve got a conference room or other facility available to you the entire time so that you can leave everything in the same area. If you do have to switch places, bring a bucket or milk crate to bundle everything at the end of the day easily.

Recruiting a design sprint team

Your team will partially depend on your design sprint method, as well as who is available. Ideally, your team should be a mix of people responsible for project delivery and stakeholders.

Designers, developers, or other project members, are closer to the task at hand and can potentially provide some insights that others may not see. They’re also probably the people who will end up implementing the ideas after the sprint.

Stakeholders need to see and be involved in the process for it to work. If you do not include stakeholders, or at least get buy-in, they can easily disregard your sprint results. Don’t waste a week working on something that they won’t approve!

The easiest way to do this is to make sure stakeholders participate from day one. You might need to carve out some time for them to step away (because they probably have other things going on too), but invite them to your most crucial parts of your sprint.

Consider adding a ‘wildcard’ to the mix. They should be someone with no direct responsibility for the project, but someone who wants to participate. They can bring fresh ideas and question longstanding thoughts. Bringing in a wildcard helps your team get past relying on their domain expertise.

Validating design sprint results

Validating your idea is an essential part of a design sprint, and one of the ones most frequently ignored. A design sprint without validation is just brainstorming.

By validating before the team works on your idea, you can ensure they’re working on something that has some potential ‘teeth’ to it. This doesn’t mean every sprint idea needs to be fully baked, but it should be formed enough that your team conduct some basic testing. You’ll need a prototype of some nature — even if it is just paper taped together.

If you didn’t recruit participants ahead of time, you have a few options. Consider a user research tool or service who can recruit them for you. The team can also do guerrilla testing (ask strangers at a coffee shop) or other groups not as close to the project. Ideally, you’re targeting your own customer base or as close as possible.

During validation, present them with tasks, not questions. Like any usability testing, the goal is to observe and not lead the user. Measure task success and general reactions. After the testing, feel free to ask more questions around feature adoption.

Wrap up

Share your design sprint idea and feedback with the broader team. Prioritize any potential changes coming out of the feedback. Then hand it off to the developer and designer teams.

Schedule a retrospective for the week after the design sprint. It doesn’t need to be a lengthy meeting but schedule enough time for everyone to be able to discuss and give their thoughts.

The retrospective helps you understand what worked and didn’t work for your team. Design sprints work best when you’re doing them a few times a year, so take that feedback and iterate on your process for the next time.