Why your design sprint is falling flat
You’ve read the books, scoured the internet for advice, and cleared your local office supply store out of their inventory of Sharpies and Post-it notes. You are ready for your first Design Sprint (capital D, capital S)! The right people show up and enjoy the activities you’ve carefully planned — from icebreakers to ideation to prototyping, the energy is high, and everyone leaves feeling happy. But months later, the product roadmap is unchanged, and it’s as if the sprint never happened. What went wrong?
But months later, the product roadmap is unchanged, and it’s as if the sprint never happened. What went wrong?
The Design Process looks so straightforward on paper. One method that’s in vogue these days is the five-day Sprint from Google Ventures, which breaks a week into general phases:
- Defining your problem alongside company experts
- Sketching ideas
- Storyboarding and prototyping solutions
- Running interviews with customers
Depending on the ‘recipe’ you follow, it has anywhere from three to ten steps that bring you through phases of diverging and converging so you can ‘design the right thing’ before you ‘design the thing right.’ [side note: I was unable to find the origin of this phrase, and would love to give it proper citation if anyone out there knows where it originated!] But anyone who’s followed those steps in the real world knows that it’s not so simple.
A recipe for chocolate cake might give you a list of ingredients, the baking temperature, and seven steps. But anyone who’s ever tried making a cake from scratch knows that it actually requires dozens of extra steps that aren’t written down; you’re just expected to know them. It might say to add three eggs, but it won’t tell you how to crack them; or how to hold the whisk as you’re beating them into the batter; or how to choose the best eggs at the store. None of these nuances are captured in the official instructions, yet they’re an important part of the cake’s success.
When you look at the recipe for a good design process, it’s just a rough guide. The true magic of design only comes to life in the hands of an experienced person who knows how to adapt it and improvise based on the conditions and available ingredients. Just as we wouldn’t expect a home cook to run a Michelin-starred restaurant after reading a few cookbooks and taking a weekend course, we shouldn’t expect a novice designer to run a successful sprint after reading a book or taking a single workshop. Building these skills takes time and practice. When something goes wrong, it takes expertise to identify the missing ingredients and get the process back on track.
Building these skills takes time and practice.
There are many ways one can make a delicious chocolate cake, but there are many more ways to make a disgusting one. The same is true with design: there are plenty of ways to succeed, but many more ways to just waste people’s time.
It’s common for people to run design sprints at their company by following instructions from online, or from a book. We all know that it’s difficult to capture a secret family recipe in writing–sometimes because Aunt Ethel intentionally left out a step, but other times because instructions like “season to taste” or “add flour until it’s the right consistency” leave room for interpretation. Instructions for design sprints are like an old family recipe, except for something that’s a lot more complex and politically fraught than a casserole or batch of soup. Yet, somehow, people still expect a high rate of success in bringing innovation to their team when following a simple set of instructions.
Instructions for design sprints are like an old family recipe, except for something that’s a lot more complex and politically fraught than a casserole or batch of soup.
There is no perfect design sprint, but there are ways to help your team run a successful one. I don’t pretend to know all of the answers, but both at the Stanford d.school, and during more than a decade designing in industry, I’ve found a few secret ingredients that are often omitted from the official guides to running a design sprint. I’m sharing them here in hopes they can bring success to your own sprints.
Only take the time you need
Some guides recommend dedicating five full days to a sprint, with each day focused on a different part of the process. While that may work for some teams, I’ve personally had better luck with one-day workshops. This requires a very strict timekeeper to keep the day moving, but the benefit is that it’s much easier to have people clear their schedules for a single day than it is for an entire week.
If you have people flying long distances to join, you may want to extend the sprint to two or three days, but don’t feel like you need to dedicate an entire week to a problem that only needs a few hours. And, on the flip side, there are rare times when your team may need a few weeks or a few months to tackle major vision projects. For some problems, you can also consider a series of half-day or full-day workshops spanning across weeks or months, giving you a chance to prototype and test in between. The punchline is, use as much time as your problem needs, but no more.
Call it whatever makes sense for your organization
Even in the most enlightened companies, you may still run into people who are skeptical of the term Design Sprint, and the baggage that the term carries. I’ve found that branding it as a Workshop or Brainstorm can make some skeptics more receptive to the activity, so feel free to get creative with naming. Are Retreats or Offsites big at your company? Then go with that. Or make up your own term that will be palatable to your colleagues.
Schedules are like rules: They’re meant to be broken
I always create a detailed schedule for my sprints, which sets expectations for the work we’ll be doing, and alleviates concerns for attendees who want to know what you’ll be doing with so much of their time. In the back of my mind, I know that sprint schedules are just a rough guide. In my experience, the most productive workshops are the ones that go completely off the rails and take you in directions you never could have anticipated from the outset. Abandoning your plans means that the team is truly engaging with the problem space, and has found a fruitful nugget of an idea to work on. If the sprint unfolds exactly as scheduled, that might mean you didn’t actually need a design sprint to develop your ideas, or that you’re over-constraining your team’s creativity. It’s okay to let loose and go with the flow, as long as that flow is taking you in a good direction.
Bring in an expert
Just like athletes have coaches, or engaged couples hire wedding planners, it can be worth hiring an expert to guide your team through a Design Sprint. If you’re at a large company, you might be able to find an internal Sprint Master willing to lend their expertise to your project. For smaller companies, you can likely find a consultant, or even a design firm, that can guide you through the Design Thinking process. Even though I’m comfortable doing things myself, I still love the luxury of having someone else join the team to help lead a sprint. Not only does that take the pressure off of me during the actual sprint, allowing me to focus and contribute to the ideation, it also brings a fresh perspective to the project that you might not have because you’re so close to it.
You can never have too many snacks
This one is pretty self-explanatory. Make sure to stock up on snacks. Either run to a grocery store if you’re on a tight budget, or look into food delivery or catering if that’s an option for your company. Well-fed participants are productive participants.
Peel Post-its like a pro
Small details matter. Have you ever noticed that your Post-its won’t lie flat against the wall? It’s probably due to your technique in tearing them off the pad. Try pulling across instead of up, and you’ll find that your wall of Post-its is easier to read.
The sprint is the easy part
Participating in a design sprint requires a lot of energy, but the true work comes in the marathon that spans before and after. In preparing for a sprint, I’ve found it’s helpful to spend weeks, or even months, tracking down the right data and research studies to understand the problem space, socializing the sprint with stakeholders (i.e. people with decision-making power in the company), and inviting the right people to participate. By the time everyone is in the room, you’ll have what you need to scope the problem you’re working on, and define what success looks like for the team.
In the past, I’ve gotten criticism from sprint participants who loved coming and sharing ideas, but never received any follow-up. So these days, I always block off a full day on my calendar to write up what we did, usually in the form of a slide deck. This deck shows participants that their ideas have been captured in an accessible way, and is helpful in sharing the sprint outcomes with the same stakeholders you met with ahead of time. If your memory is anything like mine, it’s also a great way to avoid forgetting all of the incredible ideas your team generated.
Designate a scribe
Writing up an entire sprint in a day would be a huge pain if I didn’t have notes and photos to reference. I have found it helpful to find someone on the team–either an active participant or just an observer–who is in charge of taking notes throughout the day and capturing photos of the process. If you already have a deck for the day with a schedule and content, it’s easy to put these two things together and have a good outline for your summary deck. I’ve never seen a sprint that’s over-documented, so don’t hold back in taking photos and writing notes.
Keep your expectations realistic
Sprints are great for getting teams aligned around a goal, and finding creative ways to look at old problems. While you might have an “aha!” moment or two, there’s only so much that can be accomplished in a sprint setting. I’m still working on one project where we sprinted for three days, and have subsequently been refining the idea for nearly a year. The sprint was crucial in creating the vision, but that work was just the tip of the iceberg. If you’re working in a startup or a small company, you might be able to take ideas from a sprint directly to production. But for folks in a large corporation, have patience and be prepared for serious legwork after the sprint.
Ideas need not be wild to be innovative
One of IDEO’s seven brainstorming rules is “Encourage wild ideas.” This is helpful advice for getting people’s creative juices flowing, especially when you’re working with folks who don’t brainstorm on a regular basis. It’s important not to self-sensor before sharing ideas, because those ideas might spark ideas in a teammate, or might even be more feasible than you initially thought.
While bold thinking is admirable, it’s risky to leave a sprint with a set of ideas that are uniformly “wild.” This means ideas that are complex and ambitious, requiring months or years to make progress on. In my experience, it’s best to have a blend of low-risk projects that can be realized without major changes to company strategy or roadmap, medium-risk projects that either require more time, or overcoming some type of challenge like complex engineering, and high-risk projects that involve a long time horizon, and will require a change in company strategy and staffing. Just like it’s good to diversify financial investments, it’s also good to diversify product investments.
It’s fun to propose ambitious, sexy projects that will completely change the way your company operates, and nobody enters into a design sprint hoping to make incremental changes. What’s important is that you figure out bite-sized ways to test out hypotheses and incrementally build toward the wild vision your uninhibited brainstorming has yielded. Smaller projects can also be an easier sell to company decision-makers, since it requires less investment of time and resources. As you prove wins with smaller projects, you’ll be able to gain trust and make a business case for the longer-term, higher-risk aspects of your ideas.
I’ve tried to capture some of the lessons I’ve learned the hard way about how to run a successful Design Sprint. Every company and team are unique, so what’s worked for me might not work for you, but hopefully there are some useful words of advice that will help you and your team be more successful with this process.
