R.I.P. Design Sprints
No, they aren't dead. But they are a Really. Intensive. Process.
R.I.P. Design sprints.
No, they aren’t dead. But they are a Really. Intensive. Process.
If you’ve never done one before, or have no idea what those words mean together, welcome.
Design sprints have become a favorite of mine over the past few years, especially post-pandemic. They are a great tool regardless but now also a great excuse to get disparate teams in the same room collaborating (and earning some miles). So naturally, I’m a bit of an evangelist now.
They’re not always easy (I mean, is anything really easy in product?), but, done right, they are an effective way to condense months-long discovery and design processes into a very structured five-day period. I’ve seen initiatives that were sitting on the roadmap for literally a decade come to fruition by leveraging design sprints.
Today, we’ll cover:
What a design sprint is
When to use
How to prepare
My lessons learned facilitating them
Bonus tip: Why you should write on Post-its with a dry erase marker
What is a design sprint, and when would you use one?
The concept of a design sprint was born and built at Google by Jake Knapp and John Zeratsky and has been implemented at companies like Slack, Medium, LEGO, The Home Depot … the list goes on, so the process is pretty well-tested. They wrote a book called Sprint that lays out everything you need to do, hour-by-hour, to execute one of these sprints.
A design sprint is intended to guide teams through identifying a design problem, building a prototype, and testing it in a highly structured five-day period.
“Use sprints when the stakes are high, when there’s not enough time,
or when you’re just plain stuck.” — thesprintbook.com
You’re essentially blocking off a week of time for a team of about seven people to dedicate themselves to finding solutions to a customer problem. Each person attending has a designated role with well-defined responsibilities, such as Facilitator and Decider.
The week looks like this:
On Monday, your big goal is to choose the problem you’ll tackle. You’re taking this day to share all the information you know about the problem and consult your company’s experts on the topic.
On Tuesday, you’re beginning to review solutions to the problem. You discuss previous attempts to solve the problem, and then everyone works individually using a four-step process to create their own solution. On this day, you’ll also recruit customers for your customer test.
On Wednesday, all the sketches you made on Tuesday go up on a whiteboard you call your “Art Museum.” You go through a formulated approach to collectively decide which solutions you’re going to prototype. You’ll end up with 1-3 possibilities that make it into Thursday’s prototyping effort.
On Thursday, you’re building prototypes of your proposed solutions. These are designed to be “facades,” with just enough detail for a customer to imagine what the real thing would look like.
On Friday, your recruited customers review this prototype and give you feedback in real-time.
How to prepare for a design sprint – space and supplies
There’s a fair bit of planning that goes into making sure you’re prepared for the week. Once the week starts, everything is pretty fast and furious, so you don’t want to be scrambling for supplies or realizing that the room you’ve chosen is not really set up to serve the purpose.
First, follow the supply list exactly!
Then, ensure the conference room or space you reserve is big enough with lots of windows and natural light. Why?
You’ll be in the same room with the same people for five days.
You’re going to need five or six stations, including two whiteboards, if you want to keep your Map (from Day 1) up the whole time, which I highly recommend. It’s really helpful to be in a room where there is a ton of blank wall space. If there is glass that is usable as makeshift whiteboards, that works, but if you don’t have access to either, you’ll need Post-It Easel Pads.
Station 1 (whiteboard):
Write up the time-boxed agenda as a checklist for the day. Include timing so everyone is aware of exactly when everything will happen. The book doesn’t tell you exactly where to put in breaks, so you have to work around what makes sense based on the group.
Station 2:
Wall space for your “How Might We” Post-it notes.
Station 3:
Big blank wall space for the Art Museum.
Station 4 (whiteboard):
Sprint questions
Station 5:
Lightning demo takeaways
Station 6:
Whiteboard or easel pad to further explain subsections of the day’s agenda.
How to prepare for a design sprint – team and process
Preparation for a design sprint is about more than supplies and logistics, though. You also need to make sure all of the human beings know what to expect, are on the same page, and are prepared to run this sprint.
The following should be done 3-4 weeks ahead of time:
Give copies of the Sprint book to everyone involved. People can skim or read it, but ultimately, they need to have buy-in about the process if they’re going to be on the team.
Order your supplies and reserve your room. Don’t rely on whatever you have on hand. Everything they recommend in the book is intentional, and time and energy will be wasted if you “wing it.”
Coordinate travel logistics. It’s important to carefully select your team well in advance. It’s likely that one or more important attendees will need to travel to the a central location.
The following should be done 1-2 weeks ahead of sprint:
Hold a Kick-off meeting.
Invite everyone on the team, as well as their leaders, to make sure everyone is on the same page. See if anyone has any questions and take the time to identify anyone’s hesitations about the process.
Walk through the problem. Even though Day 1 is about articulating the problem, you don’t want people coming in cold. Your problem is likely part of an overarching product vision or strategy or aligns to a broader company initiative, so provide that context. It may be helpful to include this as a pre-read to the Kick-off. You may also need to pre-socialize the problem space with key stakeholders to get alignment.
Walk through the process. Watch the intro video provided on the site and then walk through the week’s schedule. The authors also provide a slide deck that you can add additional slides to if needed. There are a lot of steps involved with the process, so providing visuals to attendees can be helpful, particularly if you have a mixed group culturally or are navigating any language barriers.
Lessons learned
This section assumes you’ve either read the book or are familiar with a design sprint. These are my lessons learned after facilitating several sprints.
For the Facilitator: All week
Whether you’re new to design sprints or you’ve done them several times, it’s okay to rely heavily on the Sprint book to guide you.
For example, when I lead a design sprint, I hold the book open in front of me the entire time.
Before I start each part of the process, I either summarize or read aloud from the book to set up that section. This allows me to explain what’s about to happen and why.
Always pause, ask for questions, and address anything before you go forward. You will be glad you identified any confusion before diving in.
Monday: Day One
Make sure you have the right people involved and that everyone’s roles are determined up front. It may not seem like a big deal to change the team mid-week, but it can actually be very jarring when some people in the room don’t have the same context or prep as others. This can really throw off the vibe of what you’re trying to do. Once the team is set, maintain this team for the duration of the sprint.
Make sure that someone besides the Facilitator role is doing customer recruitment. The book mentions this way too late, in my opinion. Customer recruitment can take a really long time because you have to come up with criteria to identify the target customers, find a way to reach those customers and gauge their interest, screen them for quality, and then schedule them for Friday of the design sprint. Don’t leave this to the last minute. In fact, scheduling 1-2 weeks ahead is advisable.
Product discovery platforms like Userinterviews.com, Maze, Hubble, and Tarka can help you with customer recruitment, giving you opportunities to “buy your audience.” This can be particularly helpful for pre-PMF initiatives. Determine what your incentive will be, whether monetary or otherwise, because they’re unlikely to do it out of the kindness of their hearts.
“Ask the experts” is when the team can ask others in the company for their input and knowledge. It can be challenging because if you haven’t yet honed in on which problem you’re going to solve, you may have experts that are too general. It’s okay to keep those expert interviews very short (e.g., 15 minutes).
Don’t talk about competitors on Day One. Many people will be tempted to, but remind them that there is an opportunity to do competitive benchmarking on Day Two.
Assign a transcriber for your Map on Day One. You’ll want it in Miro or another workflow tool of choice after the week ends. (Also keep it up on the whiteboard the whole week if you can.)
Wednesday: Day Three
Ensure your Decider is prepared. It may be helpful to hold a pre-meeting on Day Two or Three to prepare the Decider to start making decisions. I have seen the person in this role, someone who has read the book and is bought in, get flustered because they weren’t prepared to find the signal through the noise during the decision-making process on Day Three. Help them understand what decisions they will be making and that all of the decisions of the week can be changed later. Nothing is binding. The important thing is direction over perfection.
Storyboard Karaoke. (This isn’t in the book; I made it up.) After you have your storyboard completed, ask multiple people to present it back to the group. Make it fun for the first person who volunteers (or is volun-told) to take the pressure off. For example, tell them they have to do the worst job presenting possible. They have to make it really bad. Or that they have to present as if they are a sports announcer or present using an accent. Generally speaking, your Troublemaker/class clown type is going to volunteer for doing “the worst job ever” presenting, and it usually lightens the mood so the second person has more courage to give it a shot.
Create two copies of the winning storyboard tri-folds. This way, you can cut up and mark up the copies for storyboarding purposes and leave the originals hanging in the Art Museum. For example, you might cut up and use only ⅙ of one person’s sheet on the storyboard. The other copy is useful for the prototypers to have easy access to the originals while they’re working on Day Four.
Day Three is also a good time to schedule a night out with the team to do something fun. This can help with camaraderie and help you bond and recover from what has potentially been a heated day in the deciding process.
Other lessons learned:
Facilitators: Have your “right-hand” person identified. The one who will jump in and do anything, watch for non-verbal cues from the group, give you straight talk feedback, and buoy you up. (It’s a long week.)
At the start of each day, show the day’s video from the Sprint site. Walk through the time-boxed agenda. As you move through the day, mark each item complete enthusiastically.
Include someone from your Marketing department on the team. They will be especially helpful on Day Four, prototyping day. You need someone who can quickly access stock imagery, icon libraries, and other brand assets. This is especially key when your sprint has more of a go-to-market focus, when you're putting together messaging or a sales pitch deck.
The book tells you to eat lunch at 1 p.m. so you miss the lunch rush. That might be true in the U.S., but if you’re in a country where the lunch rush is later, you’ll want to break earlier if you can. Adjust the schedule to accommodate the group’s preferences. I also highly recommend leaving the building every day. Don’t bring in catering. And, especially, don’t bring in the same catering every day.
Design sprints should focus on the biggest problem you’re facing as a team. They can be used to solve business and/or customer problems. Some might be focused on market messaging and how sales will take the product to market, while others will focus on the details of the product design.
Take pictures and video. I like to create a 1-2 minute recap video to share out broadly to the rest of the company. While only 7-8 people participate actively in the design sprint, nothing you work on should be kept a secret. Do a read out to the broader organization or team. And make it fun and visual!
Don’t mix Sharpies and dry-erase markers! Don’t allow permanent markers / Sharpies in the Design Sprint room. Just use the dry erase markers to write on the post-it notes. If you have both, literally every time you go from writing on a sticky note to writing on the whiteboard, the room will erupt in a chorus of, “Wait! Nooooo!” Save yourself the trouble. Use the dry erase markers for everything.
Is it possible to do a half-day or remote sprint?
Doing a five-day design sprint is a R.I.P. (Really. Intensive. Process.). Ideally, you do it exactly the way the book outlines: five full days, in person. But that doesn’t mean that there aren’t ways to adapt the sprint and still get value out of it if you don’t have the resources or schedule to make a week-long commitment. The goal is to accelerate learning without wasting time and energy coding new functionalities or features (or even building a whole product) before validating market interest and gauging customer feedback.
I’ve modified design sprints in the following ways:
Four-day week instead of five. Day 5 was done over the course of the month following the sprint. Not ideal but it made sense for the pre-PMF initiative at that time. We had a lot of parallel work to do in between recruiting potential customers (we had no existing customers).
Half-day “mini” design sprint. Divided the group into two teams. Gave them each a different flavor of a solution to a problem space we had been exploring for several weeks. Each team had 2 hours to develop a prototype and present it back to our panel of judges, Shark Tank style. We invited in a few of our top Sales team members with the main question of, “Could you / would you sell this solution and how?”
I’ve never done a remote sprint and I don’t recommend it. That’s the one rule I wouldn’t break.
Final takeaways
Hopefully, you now have a better understanding of design sprints, when to use them, and how to avoid some of the common mistakes teams can make when they attempt this really intensive process.
If you have more questions, I’d be happy to answer them! You can drop me a note in the Comments below or DM me on LinkedIn.