Trying to define what exactly your product or service should be and who it should cater to is especially tricky. In your search for an answer, you might have stumbled across the design sprint framework. Design sprint has become a go-to way of validating product ideas in a user-centered, fast, and relatively cheap manner.So, what is a design sprint? GV describes it as a five-day framework that aims to answer critical business questions through design, prototyping, and testing ideas with customers.¹ It usually consists of five phases over five days:²
If five days seems like magic to you, you’re not alone. There are proponents (here and here) and opponents (here and here) of the framework. Regardless, it has become the norm in many early-stage startups and scaleups. You can find some case studies on how Lego, the New York times, and Google teams ran their design sprints here and some things to avoid here.
In your startup, you frequently have to quickly address customer problems or pivot. Design sprints are a great way to achieve a lot, test your riskiest assumptions, and get customer feedback fast. To make the most out of your design sprints, it’s good to keep some things in mind and do the preparation beforehand.
How can you know if the design sprint will give you the answers you need? Well in general, Google Ventures suggests using sprints when the stakes are high, when there’s not enough time, or when you’re just plain stuck.³ From my experience, you’ll probably get a different level of success when you’re getting started with the framework. That depends on factors like the problem context and complexity or the team structure.Here are some cases when you might want to use design sprints:
Design sprints mainly support ideation and validation of product design problems. It’s important to carefully frame the sprint goal and to stay on track during the week. The best goals should be in line with the long term vision but workable in the short term. For example:
If you’re dealing with branding or broader service problems, you may not find all the answers within one design sprint. It may be wiser to look into other frameworks or methodologies for that.
You spend the first day of the sprint talking to your domain experts. If you don’t have much historical data or if your data is a mess, you may well end up facilitating discussions that don’t go deep enough to clearly define your goal. Make sure your team does its user and market research homework before starting a design sprint. You can’t make informed decisions during a sprint if you don’t have a basic understanding of the market and your target users. If you don’t have data and insights at hand already, doing a research sprint before a design sprint can help you prepare well and have a more meaningful outcome.
In general, you need up to seven people with diverse skills to run the sprint.⁴ You want a combination of product, sales, design, and development people to make sure you look at the problem from all angles and come up with a workable solution that makes business sense.
Take enough time to explore and sketch ideas on day two. It's important to come up with well-thought-out ideas since they will be the basis for shaping your ultimate solution.
I know, it’s tough to come up with a good prototype within less than a day. There’s no need to go into details with the prototype design, so let go of your perfectionism and cut any unnecessary efforts. You can use ready-to-use UI toolkits to build prototypes. If needed, take two days to finish the prototype. It’s better to do that than to test an incomplete prototype idea.
Don't expect to have a production-ready solution at the end of the sprint. The design sprint helps you come up with and validate ideas. If the idea works after your prototype test, you’ll need to think about how to prioritize and break it down into steps to turn it into a product. You can find some great takeaways on what comes after the sprint here.
Working on a product is a messy, non-linear process. The design sprint framework is by no means a silver bullet that you can easily apply to any product problem. It might feel awkward when trying it out for the first time, but over time you’ll see what works for you and what doesn't. You might find that you want to expand some exercises and cut others, or even come up with some frameworks on your own (who needs in-depth storyboarding anyway?).
If you’re not sure whether a design sprint will give you the answers you seek, there are other methodologies that you can apply during the product discovery process. I’d recommend looking into books such as UX Strategy or Mapping ,,experiences. You may also be interested in other sprint frameworks like the Research sprint or Three-hour brand sprint.Feeling ready to give design sprint a chance? Well, you’re lucky because you can also have remote virtual design sprints! To get started quickly, use the templates for Miro or Mural.
[2] How it Works. The Design Sprint.
[3] Zeratsky, J. Sprint: Set the Stage // GV Library. Medium.com.
[4] Ibid.Top photo credit: S. Bonneval / Unsplash.
If you're feeling generous why not spread the words on Twitter.
Have a good one!
