Design Sprints at Cancer Research UK

Giulia Merlo
Cancer Research UK Tech Team Blog
4 min readJan 3, 2019

--

Photo by Braden Collum on Unsplash

Finding new, faster and more user-centric ways of working to help us beat cancer sooner is a core purpose of our team here at Cancer Research UK. For a while now, but more intensely so in the last few months, one of the tools we’ve been using to achieve that are Design Sprints. So what are Design Sprints, and how can you use them in your organisation? Design sprints come from Google, where design partner Jake Knapp started running them in 2010 with teams like Chrome, Google Search and Google X. Then in 2012 he brought them to Google Ventures — an important note, as Google Ventures doesn’t just deal with software companies, but with a variety of organisations. Here is Jake’s definition of a design sprint:

“The sprint is a five-day process for answering critical business questions through design, prototyping, and testing ideas with customers. It’s a “greatest-hits” of business strategy, innovation, behavioral science, design, and more — packed into a step-by-step process that any team can use.”*

Sounds brilliant, right? But in practical terms… what does it mean?

In a nutshell: during a Design Sprint, a group of people from your organisation come together for 5 days, in a room, to try and solve a problem or answer a question. By the end of those 5 days, they will have come up with a potential solution, sketched it, built it — and what’s best, they will have tested it with real users. Any team can try out a Design Sprint, and no challenge is too big to answer. To get started, here’s what you’ll need…

  • Design Sprint best practice says that your team should be made up of 7 people or fewer. You can stretch this a bit, but we did find that smaller teams were more effective. One of these people will be your Decider — someone who can move things along by making an executive decision when the group can’t. This role should be played by your problem or idea’s stakeholder. This ensures that whatever solution you end up building, they’re confidently bought into it. Another person will be your Facilitator. This role requires a lot of energy, to keep the team motivated and on track throughout the week. If you have someone in your team who has some experience of Agile ways of working, this role might suit them well since they’ll be familiar with some of the activities that will happen in the Sprint — but it’s not essential. As for the other team members, who you need depends partly on the problem you are trying to solve. In our Sprints, we try to always have a UXer, a ‘technical’ expert (for example, someone who knows your CMS, if you’re working on a website-based idea), someone with content and message strengths, and someone who brings a marketing/commercial point of view. At Cancer Research UK, we mostly self-organise our Sprints: it’s a brilliant opportunity to let teams organise around the work! Remember: the strength of the Design Sprint comes from having a varied group of people working together for a short but intensive period of time. The wider the range of points of view you can bring in, the better! You might not all agree at the start of the Sprint, but you will have reached a consensus by the end of it (you will — I promise!).
  • A Design Sprint takes 5 consecutive days. This may feel like a big commitment, but if you consider how much you will get done in those 5 days (and how long it might otherwise take to get there), it’s hugely productive. And after all, if your team can’t dedicate 5 days to this idea, is it really an idea you believe in? Once you get more familiar with the structure of Design Sprint, you might find you want to shorten the process to 4 or even 3 days — but if it’s your first try, we found it better to stick to the 5 days. You’ll also need a room, with lots of whiteboards, post-its, and sharpies. Try to use the same room each day if you can.
  • What type of question can you try to answer in a Design Sprint? According to Jake Knapp, the bigger the challenge, the better the Sprint. For example, we’ve used Design Sprints to find out the viability of a new product, review the roadmap of an existing one, kick-off a new marketing campaign or bring a fresh perspective on a problem when we were stuck. Design Sprints can be used for all of these questions — and more.

If you want to get started with doing Design Sprints, my advice would be to simply start! Many of us here at Cancer Research UK didn’t have any experience of facilitating a Design Sprint: we read the Sprint book (see footnote below), talked about it as a team, and then we just went for it. It might seem a bit daunting to dedicate a week to something you’ve never tried before, but what you will learn from designing, prototyping and testing an idea with real users in a week is so valuable, that it will be worth the initial discomfort.

And if you do decide to give Design Sprints a try, or if you already use them in your charity — we’d love to hear how you use them!

*Jake Knapp with John Zeratski & Braden Kowitz, Sprint: How to solve big problems and test new ideas in just five days, Bantam Press, 2016.

Originally published at crukdigitalteam.blogspot.com on January 3, 2019.

--

--

Giulia Merlo
Cancer Research UK Tech Team Blog

Head of User Research & Design @citizensadvice | Formerly of CRUK | Co-Chair of BIMA Charities Council | Feminist, European, passionate about pizza & Beyonce