If you’ve arrived to this point, you’ve decided that a design sprint is applicable to your idea or project and you need to know where to start. In this chapter, we’ll show you what you’ll need to do to get ready for your design sprint, from defining the scope, to crafting agendas, selecting participants, and even to setting up your own “sprint kit.” By the end of this chapter, you will have primed the pump and be ready to turn on the spigot.
Design sprints work best as a one-week exercise, Monday through Friday, where each phase takes one day. This timebox allows time for enough depth, while the constraints lead to accelerated results. This one-week schedule is the most common practice and recommended as a priority for your team.
Sometimes this schedule just isn’t possible, or the needs are a bit different. As mentioned in Chapter 3, there are a number of alternative approaches to a design sprint; whatever your time availability is, your preparation is as important as the work you’ll do before and after the design sprint itself. All the participants should be sent the agenda beforehand and see examples of what the results of a design sprint might look like; however, we discourage an over-engineered approach to the expected result. For example, it’s not useful to enter a design sprint with an exhaustive feature list because it could prejudice the outcome of the sprint, which may be something very different altogether. If you’re reading this book, we assume you’re on the right track!
Each phase has associated objectives and should have an agenda. We provide a recommended agenda in each chapter for the phases. The days should be short—seven hours is ideal. The days are intense and can be tiring, so plan plenty of breaks. A good rule of thumb is to take a break every 80 to 120 minutes.
With that schedule, there’s room for exercises to go over time when needed, and attendees can have set time slots to be available to answer urgent issues.
A “plan-to-be-flexible” approach is best. The agenda should have a prescribed list of exercises and associated timeboxes. The nonnegotiable part of the approach should remain the design sprint steps. The specifics of the timing and exercises used during these steps can be adjusted to fit your project’s constraints. Overall, we have noticed that the discipline of the timeboxing is essential to structuring the work. In situations where you don’t have timeboxing, you run the risk of participants running over time on one exercise, leaving no time for subsequent exercises.
When crafting your agenda, you might consider a backup if you’re first starting out, as you do not yet have experience to guide you when things take a left turn. When Kayla Doan, an Innovation Catalyst at the Constant Contact InnoLoft, finished her design sprint training and was tasked with running them on her own, she created a plan for each sprint she was to facilitate. Then she made a backup of a project that had a different time constraint and used different exercises. But she wasn’t done there—she made yet another backup of a scenario that used different problem statements and exercises: “I’d look to see how I think the design sprint would go and then create a plan B and plan C. This helped in those moments when I needed to change gears—I didn’t need to resort to calling a break or some other intervention. Always have a contingency plan.” A plan B and plan C usually include backup exercises planned at various stages. Make sure to include a few optional exercises that you can turn to at different points of the sprint. If it all blows up, take a break. Then go back to the drawing board. Literally.
What are the guardrails of the sprint? Scoping a design sprint often includes interviewing stakeholders and doing some research. Determining who in your organization may have input to this project can be a challenge if you work in an organization that has thousands of employees. Short 20-minute interviews ahead of the sprint with the right people can help you determine not only the scope, but also who should be in the room.
The size of the scope depends on a number of variables. What stage is the product in: Early stage? Pre-Market? New-to-market? Mature? A scope that is too broad will be too difficult to wrangle, and a scope that is too narrowly defined will not have enough meat for a full sprint. An example of a scope that is too broad: We want to rethink digital marketing. Too narrow: We want to fix the login page. Just right: We want to explore new ways to engage our users in a brand ambassador program.
A well-scoped design sprint needs to be flexible, especially if it’s quickly discovered that the greatest user or business need is outside that scope. However, this scope will be focused on the problem statement described in the Understand phase and used throughout the rest of the sprint. Do not come into the sprint with a challenge statement 100% formed; it’s best to have a direction to refine during the Understand phase and honed in the Diverge and Converge phases. We want to exit the sprint with something that will have the greatest impact on the business and our users.
It helps if you have the luxury of bringing in an external facilitator to run the sprint with you. A web search will reveal dozens of design-thinking experts that might be able to help with this; however, not all will truly see the application of design sprints, as they are a combination of Agile and design thinking. When C. Todd ran the first design sprint at Constant Contact, he hired a consultant from DesignIt, a global design agency, to facilitate. It was a huge help not only to have an objective third party present, but also to have someone in the room with knowledge of the design-thinking framework.
Rie Yamaoka, a UX Manager of Consumer Products at Trulia, hired Dana Mitroff-Silvers for one of the company’s first design sprints based on past workshops where she facilitated and was left exhausted. Being both facilitator and participant can be daunting: “I was like, ‘I want somebody to just run this whole thing. Tell us how it’s done,’ instead of me trying to figure out what to do and read about it and read about it and then try to put it in practice while designing at the same time.”
Having an external facilitator is desirable but rarely happens in practice. What’s most common is to ask one of the selected participants to facilitate the sprint. The appointed facilitator will also be speaking often and leading the group, so they’ll need to let everyone have their say and not just push their own agenda. At first blush, many believe the product owner or product manager should lead the sprint, but we caution against that, because the owners/managers will have the most attachment to the outcome. Whoever has the most exposure to design sprints and good facilitation skills would be the best choice, and that might just be you. Don’t worry—if you’re reading this book, we’ve got your back, and you’re on the right track. In many cases, there is no facilitator, so it may be up to you—yes, you!—to lead the sprint. We cannot say it enough: it’s important to truly facilitate and not to use the facilitator position to push any agenda. Your goal is to move things forward and ensure everyone can speak at the right times.
The ability to listen, adapt, and remain as objective as possible during the sprint. Everyone has a bias, and as mindful as you can be of that bias, there must be an effort to remain neutral throughout the sprint. This will be important in allowing those who have ideas that may seem wild at first to continue to drive to the crazy idea. After all, the crazy idea of strangers sleeping in your house turned into a billion-dollar business (i.e., Airbnb).
The facilitator’s role is to monitor progress continually and keep the time. If an exercise is slotted for three minutes, it’s the facilitator’s job to enforce that. As we’ve mentioned already, the timeboxed nature of a design sprint might produce some anxiety, but it will force you to produce results. Some teams have shared the time-keeper responsibility rather than have the facilitator enforce it throughout. This can promote a sense of togetherness in the timeboxing.
Facilitators wield the power of the pen, and one tactic is to allow all participants to hold such power. When you write down what others say, be sure to write as close to what they say as possible. In fact, if you can write exactly what they say, it’s all the better. Why? Because you show the team members that their input is valuable, and seeing it written exactly as it was said is gratifying to the individual. It’s subconscious, but others will notice, and it helps to set the right tone for the design sprint. If a participant says something completely off base, then you can use your facilitator skills to say “so what I’m hearing from you is...” and then write a more appropriate version.
We recommend a one-page “Here’s what you can expect” session plan that informs all participants of the basic questions: What’s the objective? Where is it held? Who will be there? What time(s)? What’s the outcome?
The ideal team for your design sprint will be about four or five people. Fewer than this, and you’re going to struggle to finish all the work ahead. More than this, and you’ll start to have some friction around “who does what” and making sure everyone is included. In the spirit of writing this book for the real world, we know four to five people might not be possible. Certainly we have seen groups as small as two and groups with dozens of participants. Be advised that the size of the group can affect the outcome. Too big and you can have an unwieldy number of ideas and the Converge phase will be a challenge; too little and you risk not having enough different viewpoints in the room.
Often, it’s wise to include those who have been through the design sprint process before. Jürgen Spangl, Head of Design at Atlassian, cautioned, “If you tried to do it with too many people at the same time who didn’t have this experience, it was usually too much explanation, constantly restating why we are doing it.” By having others in the room who have been through this before, you can better proceed without too much start-and-stop for educational purposes. This is why Dana Mitroff-Silvers runs an educational exercise at the start of a design sprint where no one has any prior design sprint experience (more on that in Chapter 5).
One important note regarding participants: if there’s a person who can veto the results, having that person present for as long as possible during the sprint is advisable. If they are unable to attend, there’s a possibility that any progress will come to a screeching halt. You’ve heard of the HiPPO stampede? Do whatever you can to prevent that from happening. To make the team selection task a little easier, we’ve created three separate lists; one for startups, one for bigger companies, and one for design firms (or consultants).
The participants in a small organization will include the following:
Product Manager. It’s probably you. If it’s not you, you’ll want to find the person who has the highest responsibility for getting the product built.
Designer. Specifically, a digital product designer or UI designer. An illustrator or graphic designer without web/digital experience is not going to be able to translate ideas into designs efficiently.
Engineer or Developer. This person will be a core team member responsible for leading development of the project. If you’re a small startup, this might be your technical cofounder or CTO. Again, a little frontend experience goes a long way. If you’re asking questions that impact device functionality, you’ll be glad you included someone with experience dealing with accessibility, load times, and transitions.
Customer-Facing Expert. In a small startup, almost everyone will have some contact with customers. Your designers and developers and founding team will all have frequent contact with the customers. If they don’t, you have bigger issues. However, if there’s a single person responsible for customer support, that person will definitely need to be included.
CEO or Founder. Including the CEO is tricky, so there are some guidelines you can follow to get it right. In smaller companies and startups, it’s inevitable and important that the CEO is present. If she is also out trying to close deals or raise money, then at the very least have her be there at the start of the sprint and at the end. Design sprints should never be used to get around the task of getting buy-in from the CEO. As Keith Hopper, former Director of Strategy and Product Innovation at NPR, states, “Design sprints shouldn’t be a mechanism to bypass the CEO or they’ll never work. People will be looking for [the CEO’s] blessing and buy-in on everything anyway.” The CEO can also be useful as a tiebreaker when you’re stuck. The key is not letting the CEO’s opinion override customer needs when the two are obviously contradictory.
Marketing Manager or CMO. The marketing manager’s viewpoints on positioning and marketing messaging are essential to having the right visuals and copy in the prototype. Just don’t let that supersede the need to get something built quickly. Nitpicking on copywriting options will jeopardize meeting your deadline.
The participants in a larger organization will include the following:
Chief Product Officer (CPO), Product Manager, Director or Owner. You may not have the CPO, but you’ll need a product person there. For complex projects, we sometimes see more than one person in charge of different aspects of the same product. Include them all if you feel they are all going to help you make the sprint a success.
Project Manager. In some cases, there might even be a product manager and a project manager overseeing a product design. Again, include them both. If you’re wondering what the difference is between a product manager and a project manager, read the sidebar in What Is the Difference Between Product Management and Project Management?.
Designer. This should be a competent UI designer. If you have a big group and are going to be producing several prototypes, we recommend including another designer.
Engineer or Developer. In our experience, this will most likely be a frontend developer but you might have a backend specialist on the team too. Either way, because you’re going to be designing the prototype of your product interface, the more frontend experience, the better.
Customer-Facing Expert. In larger companies, this is a defined role: “Customer Support Manager” or “Chief Feel-Good Director” or something like that. If you have more than one customer segment, you might want to have an additional person in here from the marketing team.
CEO. See earlier explanation in A team in a larger enterprise organization.
Product Marketing Manager. The marketing manager’s viewpoints on positioning and marketing messaging are essential to having the right visuals and copy in the prototype.
The participants in this type of organization will include the following:
UX Strategist or Product Lead. If you work at a design firm, then this is probably you. If it’s not, you’ll want the person tasked with leading the project from the agency or consulting side of the fence.
Engineer or Developer. See earlier explanation.
Project Manager. For most design firms, this will be a more typical project manager role. In some ways, this person will be one of the most important members of the team. The project manager will capture all the conversations, sketches, and decisions and will help make sure the team stays on schedule and meets deliverable deadlines.
The client. Probably a good idea, right?
Third parties, such as partners, vendors, and advisors to the client, also need to be considered. The client might feel compelled to invite these types of people because they fear leaving them out might alienate them. The choices here can be sorted out by applying the Chicken and Pig Test. The story goes that when preparing breakfast, the chicken’s contribution means they are simply involved, while the pig is totally committed. Committed people have a lot to lose if things don’t go well, while involved people are mostly bystanders. For a design sprint, it’s always better to have the people who are committed than those who are just involved. The test is to ask, is this person involved or committed?
We’ve also seen suggestions to include “anybody else who’s interested.” This is inadvisable. More is not better: design sprints are not for anyone. They work best when you include the product team and the people who directly influence the product’s success. Including the office manager because he says he once spoke to a customer is just a waste of everyone’s time.
There’s an ongoing confusion as to the difference between product management and project management. Let’s try clear this up once and for all. Product managers are responsible for the overall product vision, directing the people (including all the touchy-feely stuff) and the road map (the strategy) for getting there. Project managers are responsible for getting the logistics, scheduling, planning, and task allocations done. Think of the product manager as the CEO of the product and the project manager as its COO. Another way to think about is that the product manager is in charge of the why while the project manager is in charge of the how.
Regardless of the company size or structure, these roles need to be distinct. In a service company like a design consultancy, the product manager is normally a member of the client team and the project manager is normally a person on the design service team. At Fresh Tilled Soil, the company insists on having a project manager on every project. If the client offers to provide a project manager, Fresh Tilled Soil will still provide its own project manager to ensure that the team has all the support it needs to be awesome. Responsibilities such as updating schedules, managing task lists, coordinating phone calls and meetings, and staying on track with sprint schedules should not be passed off on designers and developers when they have so much else to do.
The physical space in which you host a design sprint is crucial. Secure this space for the duration of the design sprint. It’s inadvisable to move to a new space each day, as this will disrupt the work and create gaps in workflow when whiteboards are erased or Post-it notes get lost between sessions. We recommend having a room that contains ample wall space and whiteboards, with room to move about. For tables and chairs for larger sprints, we usually configure the room into “pods” with four to six people at each pod. The Fresh Tilled Soil team has five dedicated spaces with large walls painted with IdeaPaint. This allows us to commit a team to a room for the duration of a design sprint.
It’s recommended that participants attend in person; however, design sprints can still work if people are in different cities and can’t afford to travel. If the days are consecutive, you want the same room for each remote group so everything stays in place between days. Ensure a solid remote setup and that the remote party can upload its materials immediately as they’re created. Let’s be very clear here—remote design sprints are not easy. You will need an experienced facilitator. You will also need to plan around time zone differences and schedules and allow for additional time for technical issues, which inevitably come up.
For example, at thoughtbot, a client wanted a design sprint in NYC but had one participant who needed to participate remotely from Portland, OR. We double-checked everyone’s connectivity and communication tools before we started, and created a Trello board where everyone uploaded their sketches, storyboards, wireframes, and other content as soon as it was created.
Post-it notes. A variety of colors, avoiding darker colors like purple and blue, as black Sharpies tend not to show up well on them, especially in photos. Get two sizes at a minimum: 3 × 3 and 5 × 7. Super-sticky preferable. (And yes, we think 3M should sponsor this book. Are you reading this 3M marketers?)
Drawing markers. Any standard black or blue pen is probably fine.
Whiteboard markers. Black and red are great.
Whiteboards. Self-explanatory. Not much good without markers though.
Dot stickers. For voting. You want something small with a few colors. Red/yellow/green are recommended.
8.5 × 11 or A4 blank copy paper. Preferably thicker than typical copy paper. We found that copy paper tends to bleed and can leave marks on tables.
Snacks. Sugar and carbs are your friends.
Coffee. Seriously, caffeine is your friend.
Adhesive putty. To stick things to the walls or windows.
Easel pads. To put up on the walls, so that they stay nice (alternatively, you can use IdeaPaint everywhere, like Richard does).
It’s also nice to have the following items:
Large ½-inch thick foam core boards sized 4’ × 6’ or larger.
Camera. Your mobile phone works quite well (unless you have an old Nokia flip phone).
Timer. Optional, though totally awesome. Your mobile phone can work as a substitute, but nothing motivates people like a big clock timer.
Preparation for design sprints happens long before the wrapping comes off the Post-it notes. Make sure each sprint is the best it can be. Assemble your supplies methodically, because every sprint is a little bit different. Discuss what might be needed with the sponsor ahead of time. Keep in mind the space the sprint will take place in, the participants, and any activity-specific needs.
Some things are obvious: Post-it notes, pens and markers, printer paper. As sprint planning continues, other things will become obvious, too: will there be any projection? (Bring the right cables and adapters!) Are any of the activities timeboxed? (Bring a timer!) Are you using whiteboards? (Bring dry-erase markers and erasers!) Most supplies are inexpensive, and will show their value when they’re suddenly (sometimes unexpectedly) necessary.
Of course, not everything about a sprint kit needs to be functional. It’s important for participants (and facilitators) to have fun, too. Include supplies for a funky warm-up exercise. Bring a wireless speaker for some up-tempo beats while participants are working. Keep participants happy (and healthy) with drinks and snacks for energy throughout the sprint.
Be ready. Build a kit that works for any situation, or be strategic and build a sprint-specific kit. Ensure the tools necessary for a successful sprint are ready when the participants are.
Ethan’s sprint kit:
Very small Post-its (assorted colors, 2″ × 1.5″, 200–300)
Small, square Post-its (assorted colors, 3″× 3″, 1,000–1,500)
Small, square Post-its (yellow, 3″× 3″, 1,000–1,500)
Medium, long Post-its (assorted colors, 4″× 6″, 50–100)
Medium, long Post-its (assorted colors, 6″× 8″, 50–100)
Sharpies (black, 12)
Sharpies (assorted colors, 12)
Pens (black, 12)
Pens (blue, 12)
Dry-erase markers (black, 12)
Dry-erase markers (assorted colors, 4–6 per color)
8.5″ × 11″ plain printer paper (heavy weight: 35+ lbs., 50 sheets)
Index cards (unlined, 200)
Dot stickers (assorted colors, 200)
Painter’s tape (1″ roll)
Name tents (12)
EXPO White Board Care Cleaning Spray (Dry-erase cleaning fluid, 1 bottle)
Dry-erase cleaning eraser (1–2)
Display adapters (VGA, DVI, HDMI - PC, Mac)
HDMI - Thunderbolt
VGA - Thunderbolt
DVI - Thunderbolt
HDMI - VGA
DVI - VGA
DVI - HDMI
Display cables (HDMI, VGA)
Audio cables (3.5mm stereo audio cable)
Time Timer (7″)
Speaker (small, Bluetooth and 3.5″ inputs)
To prepare for and prevent the things that can go wrong (and ask any of us, many things can!) we recommend conducting a “pre-mortem” before the design sprint begins. It’s like a port-mortem, though you’re predicting why the project will fail before even producing it. Stacey Dyer of iZotope uses these religiously: “Instead of asking what could go wrong with that feature, imagine it has completely flopped and has now become an epic fail.”
It’s a simple exercise you can do with the project sponsor: first, imagine that the design sprint has miserably failed. Second, consider the plausible reasons for this design sprint’s failure. Then review these fail-points and discover ways to strengthen the project.
Let’s now take a look at some standard things that can go wrong, and what you can do to fix them.
Room was too warm. People fell asleep.
Make sure room is at a comfortable temperature.
The team was hungry.
Buy cookies. We prefer chocolate chip.
Everyone was on their computers all the time.
Establish a “no devices” rule except when reviewing existing materials online. Come prepared with lots of pens and paper and Post-its to write on. Or just conduct the sprint in Tahiti. We hear there’s no signal there.
The main stakeholder ducked out for meetings when key decisions were made, then came back and reversed them.
Ensure the key stakeholder has the time reserved on her calendar.
An executive came in mid-sprint and derailed the team.
Involve the executive earlier in the design sprint, or at least get them to help set the course/tone.
People ran out of steam.
Take frequent breaks. We recommend a short break every 80 to 120 minutes as a humane duration for focused work.
Exercises went way over time.
Set timeboxes for exercises and use timers!
A list of apps, sites, or products similar to parts of what you want to create, as well as others with aspects you may wish to emulate.
Any existing materials you already have on hand, such as pitch decks, user stories, wireframes, or prototypes. These are great background materials, but don’t flesh these out more than you already have. The design sprint will move these forward, and what you come to at the end of the sprint will likely be different.
Information about each of your key customer types: who they are, their stories, and how they feel about the problem you’re working to solve. If there’s documentation from interviews you conducted with them, that’s great to have too. Of all the things to do pre-design sprint, this requires the most lead time, so you’ll want to start identifying and scheduling users first.
For the Test phase of the sprint, you’ll need to schedule time with users. Sometimes you’ll need to schedule a few interviews on the first day as well (foreshadowing: Discovery Interviews, more in Chapter 5). Bookending a design sprint with customers can be very powerful. Should you choose to conduct Discovery Interviews in the first phase, you don’t want those same users on test day. One or two is fine, but not all. Scheduling these appointments before the sprint begins will save you from scrambling as you have a deadline to get everything ready for testing on the final day. The downside is you may not be able to schedule with the “right” users until the end of the first day, as you’ll define who these users are during that phase. If the desired user type drifts from who is intended, you may need to cancel some sessions and reschedule with users who are better matches to the type you seek.
Based on Steve Krug’s guidance in Rocket Surgery Made Easy: The Do-It-Yourself Guide to Finding and Fixing Usability Problems, we recommend six to seven users for 30–60 minutes as ideal, though if users are very hard to come by, schedule longer sessions for fewer users. For example, we recently did a design sprint where the target user was the manager of a factory floor. These people were hard to come by, so we spoke with two users for 90 minutes each instead of six users for 30 minutes each. This approach gave us a lot of great information, but there’s always a caution that you’re designing a product for a small market, so be sure to consider the outcomes of these interviews and take into consideration the quantity versus quality debate. You’ll need to finish by late afternoon to prepare findings for an end-of-day discussion that will conclude the design sprint. Each participant will use the prototype and be asked questions to get their feedback.
Many people peel a Post-it straight up and off, but the problem with that is the edge where there is adhesive curls. Even if you flatten this when sticking to a vertical surface, the Post-it does not lay flat. The best way to peel the Post-it off is to pull it from the side as flat as possible. The result is that the Post-it will lay flat on the surface, and also there’s less chance of it falling off.
Agree and align on the scope (not too narrow, not too broad).
Select a facilitator and recruit your team to have the right mix of different viewpoints in the sprint.
Set the daily agendas and circulate to the team so they have an idea of what to expect.
Get your space and supplies ready.
Co-create guidelines and rules of engagement at the start.
Prepare background materials.
Schedule time with users in advance, if possible.
 A “HiPPO” refers to the “Highest Paid Person’s Opinion,” and it can ruin many good things.