If you read The Agile Movement Drives Innovation then you would know about the power of Agile to help organizations master continuous change while flourishing in a world that is increasingly volatile, uncertain, complex and ambiguous.

Many organizations that embrace Agile also utilize Human-Centered Design to better understand their customer needs and design innovative products to meet and exceed those needs. These Agile organizations and teams often run into a critical situations that require a singular focus, typically involving one or more of the following:

• Developing a new product
• Adding a new important feature to an existing product
• Fixing a major problem with customer experience (CX) or user experience (UX)
• Exploring any major pivot (business, product, user, etc.)
• Speeding up the development process

These situations call for a Design Sprint, and I’ll tell you why…

 

So What’s a Design Sprint?

A Design Sprint is a five-phase framework that helps solve problems and develop new solutions through rapid ideation, prototyping, and user testing. Design Sprints help to quickly spark creativity and innovation while encouraging user-centered thinking to gain key learnings.

They are typically used for product development – but can and should be used by any department in any organization – and involve the whole Agile team (not just designers), are led by the ScrumMaster, and will interrupt the normal sprint cadence so your team isn’t distracted by working on other features too.

 

How does a Design Sprint work?

It typically lasts 1 week (Mon – Fri), where a full day is devoted to each phase. However, there’s no Design Sprint police that says you can’t extend it to 2 weeks if you have a large problem or feature that requires greater focus and exploration… or if you’re an advanced Agile team/organization who has successfully executed 20+ Design Sprints, you might be able to get it down to 3-4 days. Like Agile, Design Sprints are flexible to your team’s needs, capabilities, and experience, but I certainly don’t encourage you to rush through this process!

• UNDERSTAND: Start with the Product Manager laying out the challenge and long-term goal, and then bring in experts from other departments to provide additional insight. Next, the team will list out the questions around the challenge, and then develop a basic map of the challenge. Finally, pick an ambitious but manageable piece of the problem that you can solve in one week, and clearly outline the user, technical, and business requirements. Or if it’s a larger problem, consider a two week Design Sprint.
• IDEATE: Start by getting inspired by reviewing everything from the Understand phase. Next, discuss it as a team, brainstorm solutions, and capture all relevant notes. Then have each person sketch their own idea or solution on paper, making sure the focus is on critical thinking versus artistry. Present the solutions to the team at the end of Ideate phase. And begin recruiting customers/users that fit your target profile for testing during Validate phase.
  
• DECIDE: Review and critique all solutions that were sketched, and discuss the possibility of combining one or more solutions. Then vote and select 1-3 solutions. Develop a storyboard for each final solution, which will provide a detailed plan for your Prototype phase.
• PROTOTYPE: Your team will work together to develop a high-fidelity prototype for each of the final solutions selected, preferably a clickable mockup via InVision, but a paper mockup would also be sufficient.
• VALIDATE: Test the high-fidelity prototypes with at least 15 people from your target audience that you’ve selected in the Understand phase. I don’t recommend testing with users outside the target audience since the specific problem you’re trying to solve may have a different perspective than your target audience. At the end of the Validate phase, you’ll know if the solution is validated and what steps need to be taken next.

Once you’ve completed all phases of a Design Sprint, the output defines what to develop (or not to develop) in upcoming development sprints. And I recommend doing a Sprint Retrospective to learn from this experience to apply to future Design Sprints.

 

When NOT to use a Design Sprint

Design Sprints can solve almost any problem and develop innovative new solutions, but there are times when it won’t be effective to utilize, including:

• New features that are small & easy to build
• When there isn’t enough information known to effectively inform the solution
• When the problem is outside the scope of product (e.g. brand, service design, etc.)
• When a prototype cannot be developed in 1 day (consider a 2 week Design Sprint)

 

Conclusion

Design Sprints compress months of work into a single week (or two) and help quickly resolve internal conflicts about products and/or features. Instead of waiting to launch a minimal product or feature to understand if the idea is good, you’ll get clear actionable data from a realistic prototype.

The Design Sprint is proven to save you months of development time, enhance your product’s ROI, all while injecting turbo thrusters into the development process. With that said, the Design Sprint is just a framework, so don’t be afraid to customize it to your team’s needs, capabilities, and experience.