Implementing design sprints into a continuous release cycle

As an advocate of research-driven design, having the opportunity to facilitate design sprints and explore product solutions in interdisciplinary teams is a dream come true. However, making this work in a continuous development cycle, delivering client products to market on a bi-weekly basis, can be a challenge.

The advantages of running a design sprint are undeniable. Understanding customer needs allows you to make strategic design decisions and prioritise product opportunities based on the value you’ll deliver. Assessing the validity of product concepts with users at an early stage helps to eliminate concepts that aren’t working, reducing risk and increasing your confidence in the product. Working in interdisciplinary teams with a collaborative approach to design helps to improve team dynamics — happy teams deliver products faster and more effectively.

In just five days, you can deep-dive into customer needs, generate an expanse of product ideas and have concepts prototyped and tested with users. But with the team working towards bi-weekly releases to market, it’s difficult to avoid the feeling of separation between the two working modes. It’s important to find the right balance between running regular design sprints and getting product updates to market sooner.

How often should you run design sprints?

A high frequency of design sprints can result in an overwhelming backlog of work for the product team. Being flexible with your sprint planning allows dedicated time for design, development, testing and preparation for release. This allows you to stay focussed on getting the latest update to market, avoiding the pressure of a looming backlog. As you approach feature releases, you can start planning the next incentive.

When is a prototype ready for implementation?

It can be a good idea to produce two comparable prototypes during a design sprint, which you can then test with users to see which one performs better. Once you’re confident you’ve validated your design decisions then the prototype is ready to be implemented.

How should you avoid development delays?

To avoid delays to development, a staggered implementation with two task types can be effective: low-fidelity and styling. A low-fidelity ticket could be started immediately, based on the prototype(s) from the design sprint and a styling ticket could come later, giving designers time to focus on the intricacies of interaction.

How do you ensure design consistency across feature teams?

If designers are split across interdisciplinary feature teams, it’s easy to generate design inconsistencies. An agreed style guide can be a huge help, as well as regular design reviews. Including design review as a stage in your workflow can help to ensure you’re staying aligned.

How do you prevent risky releases?

Even when you’re confident in the product, you never really know how it will perform until it’s in the hands of real users. One useful way to avoid minimise risk is to start with a pilot release to a small percentage of users. This allows you to validate your hypotheses on a larger scale and make refinements before pushing the rollout more widely.

Can design sprints and implementation be combined more effectively?

Taking all this into account, it can still be difficult to shake that uncomfortable feeling that design sprints fall dangerously close to the waterfall method — completing the design thinking phase before the implementation begins. I can’t help but wonder if it was possible to bring the design and implementation cycles closer in some way, whether that might be more effective overall?

Design sprints are a collection of highly-effective research and design thinking techniques that can be used independently for each stage: understand and define, diverge (or ideate) and decide, prototype and validate, design, implement & release.

Separating each of the steps into tasks allows you to work more organically, from initial research through to release, while keeping dedicated team time for ideation and prototyping. This can help you to retain focus on a bi-weekly release but still benefit from research and design thinking methods.

It’s tough to find the right balance between dedicated collaborative design time and a sharp focus on the release, but in my experience, the closer and more organically we work across disciplines, the more effective we can be.

Originally published at https://blog.novoda.com on May 11, 2017.