Full confession, I have a love / hate relationship with Design Sprints.
On the one hand, I see incredible value at bringing a group of like-minded, cross-disciplinary people together in a safe space over a short period of time to focus solely on solving a specific set of problems. On the other hand, I’ve come to dread the same formulaic, stress-inducing, anxiety-ridden, five-day design sprint that culminates in a pile of sticky notes that are meant to represent hotly debated ideas but are born under duress in the facade of collaboration.
Like it or not, though, design sprints have become an integral part of the design and product process, and for a good reason too. Beyond my own occasional dissatisfaction (which ill get to in more detail later), design sprints are a useful and reliable vehicle to extract meaning derived from a rigorous and highly commodified process of problem-solving and design thinking — If done correctly.
I’ve had the pleasure of planning, facilitating, participating, and executing countless design sprints, some more successful than others. 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 iterative concepts, I thought I might share some things I’ve learned along the way — what they’re good for, what they’re not so good for, how to plan, facilitate, participate, and execute a productive design sprint.
So, what’s a Design Sprint good for?
- 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 issues)
- 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.
- 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.
What’s a Design Sprint not so good for?
- 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 tactical work comes later and doesn’t require the time and effort of a cross-functional team
- Solving problems that are too specific or 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.
Common mistakes
- 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! - 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. - 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. - 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. - 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-teasers, discussions, and coffee — lots of coffee (i recommend drinking loads of water too). 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 (along with a pile of those sticky notes I mentioned earlier).
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.
Pssst, it’ll take longer than five days
The reality is, a five-day design sprint just doesn’t cut it. Yes, collaborative sprint activities can most likely happen over five days, but a successful sprint where solutions are iterated on, validated by users, iterated on a little more, and presented back to stakeholders; takes no less than three weeks.
3 week planning guide
Below is an outline of my own personal Sprint plan which spans 3 weeks at a minimim:
Week 1 — Planning
Five days of planning which includes goal setting, alignment, approvals, organization, and logistics
- Define a clear goals
- 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
- Ideate in whatever fidelity is most fitting (i recommend moving in high fidelity as soon as possible)
- Critique the ideas, not the person
- Foster a safe place to share and fail openly
- Write daily reports and follow up items
- Inspire and encourage the team
Week 3 — Executing
Five days of executing, which includes anything from concept iteration, prototyping, further validation of ideas with users, delivering keynote presentations to stakeholders, additional check-ins, and follow-ups.
- 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
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.
As designers, this new standard of collaboration and co-creation comes with a responsibility to ensure that we’re equipped with the right knowledge and tools to not only plan and facilitate design sprints well, but connect the output of the sprint to solutions that deliver meaningful results. Being able to follow through and execute is equally just as important. Additionally, its our responsibility as designers to question the process and reinvent new standards whenever possible based on past learnings and new insights. Identify what your team or client needs, and tailor a process to suit.
•••
Im always looking for ways to improve my own process, if you have any ideas or learnings from past sprints you’ve conducted or participated in, please feel free to share them openly and honestly with me.
