A field guide to design sprints

Design Sprint 1:1

Let’s start of by saying that design sprints are an integral part of my design and product process. So much so that they’ve become a useful and reliable tool to deploy in any number of scenarios (from path-finding and vision work, to tacticle product roadmapping and xfn brainstorming). They’re also highly commodified, meaning they hold a certain amount of currency that can be traded for outcomes — a trusted and ubiquitous process that yeilds solutions to problems in any kind of environment.

I’ve had the pleasure of planning, facilitating, participating, and executing countless design sprints, some more successful than others. But, full confession, I have a love / hate relationship with them…

On the one hand, I see incredible value in bringing a group of like-minded, cross-disciplinary people together in a safe space over a short period of time to solve a set of specific problems. On the other hand, I’ve come to dread the same formulaic, stress-inducing, five-day design sprint that culminates in a pile of sticky notes that represent hotly debated ideas but were born under duress in the facade of collaboration.

So, after hundreds of ponderous how-might-we’s, thousands of ideas thanks to the craziest of eights, and what seems like an infinite number of ‘visionary’ concepts, I thought I’d share some things I’ve learned along the way — what they’re good for, what they’re not so good for, common mistakes, and how to plan, facilitate, and execute a productive design sprint that delivers tangible solutions to problems.

So, what’s a Design Sprint good for?

1. Collaboration
   Design sprints are good at bringing people together for a short period of time to focus solely on a specific problem (or set of thematic problems).
2. Alignment on goals
   Design sprints are a great way to align cross-functional stakeholders towards a common goal, whether it be the direction of a new start-up, a team strategy for the next quarter, or a way to set a long term vision of an experience collectively.
3. Thinking outside the box
   Design sprints can be a useful tool for creating a safe space for people to share ideas, think outside the box, and fail fast without consequences.‍
4. Validating concepts
   Design sprints can help validate ideas and concepts quickly with real users by building prototypes to test

What’s a Design Sprint not so good for?

1. Narrow focus
   Solving problems that are too specific or too narrow, such as increasing a key company metric by a certain percentage point. While data will play a role when informing your solutions, and will most definitely be a measure of success, it shouldn’t be the driving motivation of your Sprint.
2. Ready to build specs
   Design sprints aren’t particularly useful if you’re looking to produce final product specs that engineers can deploy the following week. This kind of exectional work comes later once you have clear validation and stakeholder allignment.

Common design sprint mistakes

1. Not enough planning
   Planning will make or break your design sprint. I can’t stress this enough. Plan Plan Plan. Plan your activities day-by-day, schedule check-ins and notify stakeholders in advance, book a space (preferably outside your typical office), clear everyone’s calendar, pre-order lunches, and organize sprint material — Templates (both physical and virtual), pre-reads, agendas, playlists… Leave no stone unturned!
2. Mis aligned expectations
   Not setting clear expectations is probably one of the biggest reasons sprints fail. Expectations range from what problems to solve, the goal of the Sprint, deliverables, timeframes, which stakeholders should be included. My general rule of thumb is to align on everything as early as possible.
3. Not enough insights
   Research and data insights will play a critical role in your design sprint and will shape the solutions and output that you deliver at the end. Prepare your research and data ahead of time and provide the critical insights at the start of your Sprint or, if possible, share beforehand with the sprint pre-read, which will give sprint attendees the time and space needed to formulate their perspectives in preparation for day one.
4. Poor facilitation
   Facilitating a design sprint takes finesse, organization, and empathy. A great sprint facilitator will not only keep everyone on track time-wise, but will also aid in the synthesis of problems and ideas, and continue moving the team towards their expected outcome. While it’s not always possible, I highly recommend your sprint facilitator be someone who isn’t participating in the Sprint as a contributor or subject matter expert; that way, they can focus solely on facilitation.
5. Underestimating fidelity
   The idea that low fidelity is the best way to communicate ideas objectively or that low fidelity is a fast way to iterate may have been true five years ago. But, in the era of collaborative tools, design systems, and ubiquitous patterns, moving into a higher fidelity as soon as possible enables your team to critique more frequently, iterate faster, and inspire sooner — which IMO is something of an unspoken goal of a design sprint.

Don’t mistake motion for progress

A typical design sprint squeezes every minute out of every hour out of every day for five days straight. Sprints are full of activities, brain-storms, discussions, and coffee — lots of coffee. It’s easy to get caught up in the formula of ‘doing’ How-Might-We’s, Crazy-eights, clustering, and low fidelity prototypes. It’s easy to think that just because you’re ‘doing’ a Design Sprint, your output and success are guaranteed. It’s not. I’ve learned the hard way.

A Design sprint will provide a framework for activities, sharing of ideas, and collaboration. Still, without appropriate planning, facilitation, and, most importantly, time-to-execute, you’ll be left with even more questions than you started.

It’s important to recognize early on that your output of the process is your goal; the goal is not the process itself. The Sprint needs to bake in time to connect the process of problem-solving to something tangible. Depending on your goals, ‘something tangible’ could be anything from a strategy document, a pitch deck, a low fidelity prototype to test with customers, or a long term product vision. In any event, you’ll need time to produce a ‘thing.’

I recommend setting a clear goal with your stakeholders early on — ask yourself, what are you going to produce? What is your client going to get? This will not only set and align expectations with everyone but also give you a chance to design the Sprint to be more productive. It’ll give you and the team something to shoot for.

Bare in mind, most ideas will be shaped by the constraints and environment in which supports them. Design sprints, while formulaic by nature, need to be designed with some space for serendipity, divergence, exploration, and the opportunity to fail fast.

Hot tip…It’ll take longer than five days

The reality is, a five-day design sprint doesn’t cut it. Collaborative sprint activities can most likely happen over a five day period, but a successful sprint where ideas are iterated on, validated by users, and presented back to stakeholders, takes no less than three weeks to plan and execute well.

Here’s a simple 3 week outline that I follow for most of my sprint coordination:

Week 1 — Plan

Five days of planning which includes goal setting, alignment, approvals, organization, and logistics.

• Define a clear goal
• Define Stakeholders
• Define output (Fidelity matters)
• Define activities (based on expected output)
• Define agenda
• Define what success looks like
• Define what a fail-state looks like
• Set expectations
• Find a dedicated space
• Send a pre-read to attendees

Week 2 — Collaborative workshops

Five days of facilitating collaborative workshops (the sprint-part that most people are familiar with)

• Start with the agenda
• Show examples of what success will look like at the end of the sprint
• Share key qualitative and quantitative insights
• Align on the problems to solve
• Turn problems into questions with How Might We statements
• Diverge thinking and ideate in whatever fidelity is most fitting
• Critique the ideas, not the person
• Converge and consolidate
• Foster a safe place to share and fail openly and fail fast
• Carve out time to isolated work
• Dont be afraid to adjust the next days agenda based on current learnings

Week 3 — Execute

Allow at least five days to pull everything together from the prior weeks. This includes iterating on concepts, prototyping in higher fidelity, further validation of ideas with users, delivering keynote presentations to stakeholders, and additional follow-ups with next steps.

• Prototype (much like an image says a thousand words, a prototype will save you a thousand meetings)
• Test and validate
• Review
• Publish
• Define next steps
• Plan a post mortem

Sprints are just another tool to master

Before the advent of the Design Sprint, designers, product managers, entrepreneurs, and business owners weren’t all sitting around waiting for a magical framework that would solve all their needs.

Collaborative workshops are not new. Coming together to discuss and share ideas is not new. Iterating on a proposal, whether it be the design of a digital product, a chair, a building, a supply chain, or a social policy, is not new.

What is new, however, is that the Design Sprint has become an industry-standard tool and framework that sets a precedent for design thinking and collaboration within teams of all sizes and scale. It’s a process that can be regularly deployed and one that yields (in most cases, if done well — something I want to underscore), a clear and tangible outcome for everyone involved.