Design Sprints: How to Make Them Work for Your Company

It was one of the first hot and humid evenings of this summer’s heatwave and we were gathered at Decision Tech’s fantastic, air-conditioned offices for the Ladies that UX London June event. The theme of the evening was ‘design sprints’ — a problem-solving methodology that has exploded in popularity since Jake Knapp of Google Ventures wrote the book on it 2016. A quick show of hands revealed that around a third of the room had participated in a design sprint and a handful had facilitated one.

A design sprint is about bringing a team together to tackle a business problem over (typically) 5 days. The sprint follows 5 phases — Understand, Sketch, Decide, Prototype and Validate. It can be thought of as a compression of the user-centred design process, and requires stakeholders from across the business to be active participants. The 3 speakers on the evening’s lineup each had their own take on design sprints and how they have made them work in their teams and companies.

Customising Design Sprints

The first speaker, Sophie Mitchell, Lead UX Designer at Rated People and Founder of Ladies that UX London, introduced the audience to design sprints through a case study. She ran a customised 3 day design sprint at Rated People to tackle the problem of onboarding tradespeople (who use the Rated People platform to find work and grow their businesses). This problem had never found its place on the product roadmap, but Sophie felt it needed prioritising and tackling. When she proposed running a design sprint to stakeholders, they were keen to participate but not all could commit to the whole 5 day process. Instead, Sophie condensed the sprint into 3 days while maintaining the 5 key phases.

A design sprint is a hugely collaborative process. We learnt that it’s critical to pull together a cross-functional team, and also to invite in ‘extra experts’ and end user participants when they’re needed. The core team needs to be prepared to spend the duration of the sprint working on a problem together, with no distractions from devices or other meetings. Following the phases of the process carefully, even if working to shorter timescales, is key to making it work. Sophie suggested that the work they did in 3 days could have taken 3–4 months if carried out as part of the product roadmap. She also highlighted the importance of having a plan to implement the outputs to make sure the hard work pays off.

Lean Prototyping

The fourth phase of the sprint, Prototype, is when the design comes to life, ready for testing with users. This was the topic of the next talk of the evening by Melanie Hambarsoomian, Lead Experience Designer at MOO. Prototyping quickly and cheaply is essential during a design sprint, and Melanie shared her tips and techniques for lean prototyping.

First, it’s key to identify what you want to learn before building a prototype, and the design should be focused around this. At the same time, it’s crucial to get the test that accompanies the prototype right. This can be done by trialling the test itself, perhaps by piloting and iterating a few times, before putting the prototype in front of users.

Melanie recommended a few techniques for building prototypes, from low-fi (Google slides or paper) to more advanced (Sketch/Marvel/Invision/Axure). These all work well as they enable collaboration between the design and research team, for example Google Slides enables multiple people to edit at once and add comments. It’s also recommended that prototypes can be quickly updated, possibly even during the test, for example having a stack of extra template or post its that can replace components of a paper prototype.

Deconstructing Design Sprints

The third speaker of the evening was Carmen Brion, CX Research Lead at The Economist. In her talk, she broke down the design sprint methodology into a toolbox that can be adapted to meet the needs of the team. The design sprint is often seen as a silver bullet for solving problems, but in reality, the time and effort required to pull off a complete design sprint means it’s not feasible to deploy, and can take months of preparation. While the sprint itself might only take a week, it needs to be grounded in an understanding of the target audience, their needs and problems to solve, as well as the business objectives a solution must align with. Therefore, it can be more productive to integrate design thinking techniques into shorter workshops or a discovery/delivery dual track scrum.

My main takeaway from this event was that the design sprint methodology is a fantastic way to prioritise, tackle and (hopefully) solve a problem, but as Carmen pointed out, it is not a silver bullet and does require integration into a company’s own culture and workflow. After the 3 talks, a lively discussion, and the chance to chat more over drinks, we went out into the warm night with plenty of ideas for putting the methodology into action.

About the author

Lesley Fosh is a Senior UX Consultant at System Concepts. With a background in human-computer interaction, she enjoys using creative methods to understand people and prioritise their needs in design.