On the road to understanding how to build superior software and an exceptional client experience, I came across the design sprint process. Here, I’ll share my rationale and advice about using design sprints for software development.
I’ve always strived to deliver the vision my customers dream up, but it hasn’t always been easy. There is nothing worse than thinking my team has hit the mark, demoing the product, then learning that it doesn’t fully meet customer expectations. I’ve worked as a consultant for most of my career, and I’ve been up against a variety of consulting project constraints.
On the road to understanding how to build superior software and an exceptional client experience, I came across the design sprint process. Here, I’ll share my rationale and advice about using design sprints for software development.
Why do design sprints?
- Accelerated understanding of the problem
- Identification of key roadblocks
- Quickly flush out requirements
- Encourage team consensus
- Create better client and user experiences
What is a design sprint?
Google will tell you that a design sprint “is a five-day process for answering critical business questions through design, prototyping, and testing ideas with customers.” Simply put, it’s a series of exercises that validate solutions to business problems. A design sprint aims at condensing the weeks-long customer research process into a day, then allowing the team to test solutions to the problem.
Assembling your team
Define your key players, stakeholders and customers. Assign one participant to be the facilitator and another as timekeeper Keep your team size to no more than 8 to keep your solutioning focused and concise. A typical design sprint solution team may consist of:
- Product Owner
- A Business Analyst
- UI/UX designer
- 1-3 Developers
Creating an ideal environment
The design sprint builds consensus and team ownership of the product. When each member of the team “owns” the product, we short-cut endless and expensive iteration processes where developers’ tasks are being kicked back to them by the QA, product owners, and stakeholders.
- Allow the team to own the product.
- Don’t start solutioning until all requirements are gathered.
- Keep solutions simple.
- Allow failure to be ok. Better to fail now.
Choosing the right sprint schedule
If you have the time and the budget, a standard 5-day Google design sprint is the way to go. A detailed list of design sprint rituals can be found in Google’s Design Sprint Kit. Choose the activities that make sense for your needs.
If you have constraints, you can condense the design sprint process and still yield helpful results. For many features and small applications, a one-to-three-day design sprint may be all you need to flush out requirements, identify unknowns, and validate your approach.
Example: Two-day design sprint
A short design sprint schedule can be useful for building a medium/large size feature – and it’s a great compromise between budget and team resources. Remember to assign a facilitator and consider designating a timekeeper to help keep the team on track.
Final thoughts
The design sprint process will yield faster results, team cohesiveness, and lots of enjoyment. While you can be creative and tailor your schedule and activities – and remember to have fun with it – it’s important that you spend time in each design phase. It’s also normal for teams to diverge during the sketch and decide phases, so be patient. It is extremely rewarding once the team arrives at consensus on solving a problem at hand.
Bill Baker, JavaScript & AWS Lead @ DevIQ
August 2022