What are Design Sprints?
I did not know that, either. Until I read the book Sprint: How to solve big problems and test new ideas in just five day by Jake Knapp of Google Ventures (GV). By the way, if you happen to know me, please send me an email request and you will get one (yeah, it is 100% legal). Still, to know something and do something these are completely two different skill sets. I knew that in order to grasp the whole idea I would need to participate in one.
There it was, I was looking at a great opportunity, the workshop's agenda for Mind The Product conference in London. C. Todd Lombardo, one of the co-authors of "Design Sprint" book, was organizing a workshop and would pack the whole 5-day sprint into one single day.
I headed to London for a very intensive, hands-on session with someone, who was literaly breathing design sprints. Here are the most important takeaways.
A design sprint is a product design framework that serves to maximise the chances of making something that people want. It takes design process, the scientific method, and wraps them into an agile philosophy.
Yeap, that's right. Design meets agile and falls in love with it. That is the story here. Today it is very hard to imagine a product, an app that would not be influenced by the framework.
5 Phases of Design Sprint
Identify and clarify the problem. Understand users, their background, behavior and needs.
Explore possibilities for a solution through collaborative exercises.
Sift through the big number of potential solution to find one or two to move forward with.
Make it appear real and get it in front of your users.
Test, what you have created and interpret the results.
When to use it?
The answer is whenever you can, as this framework helps you to avoid costly mistakes and when it confirms your thesis about the product, it guides you towards better outcomes. Design sprints are the way to go at the beginning of the product (not project!), when you explore possibilities and want to test them in real life. Also when you want to spice up the product in the middle of the development i.e. find new use cases and client segments, it will fit nicely, giving you new ideas and opportunities. The last possibility is somewhat counter-intuitive, as one looks at design sprint as something very innovative. How does it play with mature product? Perfectly! Imagine you want to explore better ways to on-board clients or find ways to cross-sell to existing clients.
Not only for software!
Similar approaches have been used to ideate new idustrial designs. One of the most known examples is shopping cart by IDEO. Their team busted myths about how design gets done. In now famous deep-dive they have reimagined the shopping cart within 4 days. By constraining themselves to these extremes, designers pushed limits of creativity. Below you can see the outcome of this process.
When not to use it?
A design sprint is not a silver bullet for every case and application. The question is when shall we avoid it? Certainly when product is already well defined and validated. Another case where we should seriously think about different approaches or postponing the design sprint is lack of user/customer data. Design sprints are also not adivseable when reimplementations of existing functionalities do not push for opportunities for improvements and changes. Last but not least, if it can be implemented within a few days/hours do not waste time for full blown exploration and validation of ideas. Application of this process also requires that there is a business opportunity. If it is not there the design sprint won't be able to help as well.
Design Sprint Anti-pattern
Remember, design sprint is the beginning of the conversation about the product and not end of it. The most common design sprint anti-pattern is when the process is being used to "initiate project" (not product?!) or as "inception phase" where the "requirements" are collected.
Do I really need 5 days?
Not at all. You can apply Design Sprints in several ways:
Approach #1: Compress the time frame
If you don't have 5 days, lets make it 2 then or three. Just determine that the right stakeholders and team members are available.
Approach #2: Shorten the days
Shorting the days, can work even better with more focus and energy through your sessions.
Approach #3: Spread it out across severall weeks.
Lets make the exercises in small, doable chunks across severall weeks and avoid disruption on your team's calendar.
Approach #4: Compact the sprint in one day or apply only specific stages.
Applied strategically this can yield terrific Return On Invesment (ROI). Make sure that you can live with the trade-offs.
Approach #5: Align with you Scrum Team
You most probably work with Scrum or similar agile framework. In such case you could simply use the time-box (from 1 week to 4 weeks) that will suit your team best.
I will describe in greater detail the workshop, exercises used and overall my user experience during Mind The Product.