Chapter 4. Before the Design Sprint: Make a Plan
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.
Determine the Timebox
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!
Construct the Agenda/s
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.
Set the Scope
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.
Pick a Facilitator
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.
What Makes a Good Facilitator?
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.
Recruit and Inform Team Members
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?[12] 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).
A small organization, such as a startup
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.
A team in a larger enterprise organization
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 studio, agency, or consulting model
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.
UI Designer. If your team has designers experienced i design sprints, deep dives, or any structured design thinking, that will help provide momentum and efficiency.
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.
What Is the Difference Between Product Management and Project Management?
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.
Secure and Prepare the Space
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.
Stock Up on Supplies
Yes, we love Post-it notes and Sharpies, whiteboards, and good old-fashioned paper. Hereâs whatâs in our âsprint kit:â
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.
Whatâs in Your Sprint Kit?
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)
Pushpins (100)
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)
HDMI
VGA
Audio cables (3.5mm stereo audio cable)
Time Timer (7â³)
Speaker (small, Bluetooth and 3.5â³ inputs)
Conduct a Pre-Mortem
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.
What happened? | The fix! |
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! |
Prepare and Distribute Background Materials
Before the sprint, request that each participant send background material that you can organize for the team to review. These can include, but are not limited to:
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.
Schedule Time with Users
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.
Post-it Note Pro Tip
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.
Takeaways:
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.
[12] A âHiPPOâ refers to the âHighest Paid Personâs Opinion,â and it can ruin many good things.
Get Design Sprint now with the O’Reilly learning platform.
O’Reilly members experience books, live events, courses curated by job role, and more from O’Reilly and nearly 200 top publishers.
