The art of the design sprint

There’s a new process that’s been kicking around the Guardian’s digital department over the last few months - the design sprint. Developed by Google Ventures and immortalised in the book by Jake Knapp, the design sprint is “a five-day process for answering critical business questions through design, prototyping and testing ideas with customers.”

My team has run four design sprints over the last few months to help us tackle the problem we’re trying to solve: getting less frequent visitors to form a lasting Guardian habit. Getting started with this new method was a challenge, however, and we’ve had to tweak it to make it work for us. Here are the three biggest things we’ve learned.

You don’t need to follow all the rules - a design sprint can be flexible

Jake Knapp’s book has been a hugely valuable resource for our team. It maps out, in minute detail, the steps needed to run a successful design sprint: gathering the participants together for the week and ensuring they’re free from other responsibilities; setting aside a space for the team to work together in for the week; and hour-by-hour activities to get from kicking off on Monday morning to wrapping up on Friday afternoon.

But really, a design sprint boils down to the following parts:

1. Framing the problem to solve
2. Generating ideas for solving the problem
3. Deciding what to prototype
4. Creating prototypes
5. Testing prototypes with users
6. Analysing the test findings

And as long as you can cram each of these parts into a week, however you can, you have a design sprint. (Of sorts, anyway.)

When my newly-formed team ran our first design sprint back in April, we already had a problem to solve, and lots of ideas for how to solve it. Some core members of the team also had other commitments that needed attention, and we didn’t have a space set aside to work in.

So we didn’t even attempt to officially call it a ‘design sprint’, or clear everyone’s calendars for official design sprint activities for the week. We simply set ourselves a deadline that we couldn’t back out of: we recruited some Guardian users to come into the UX lab on Thursday and Friday, so that those of us who were free would have no choice but to prototype something.

Then we improvised. We got together around a spare whiteboard in the corner of the office to decide what to prototype, and broke into two prototyping teams, with team members working at their desks. If people had other work on, that was fine, as long as our prototypes were ready by the deadline. Sure enough, we got it done, and ended the week with the whole team in the UX lab, watching their creations being tested and analysing the results.

Prototypes don’t need to be perfect, and you can make them in all sorts of ways

During a design sprint, the team creates prototypes designed to answer key questions with users at the end of the week. The prototypes need to do a good enough job of bringing the idea to life that you get useful feedback--but because it’s a sprint, you only have a day or two to get them done.

This means you need to get creative. Our whole team has been involved in prototyping, and because we’re not all designers, everyone has just had to use whatever method they’re most comfortable with for mocking up ideas quickly. So we’ve gone beyond the usual design and prototyping tools like Sketch, Marvel and Invision. We’ve had an editor create prototypes using the Guardian’s content management system, and a QA bring an idea to life via Keynote. Engineers have mocked up screens from scratch in HTML and CSS, and tweaked existing templates to hack together something almost working. A product manager has used Balsamiq, a wireframing tool.

Rather than prototyping a complicated user flow every time, we’ve also worked to cut down our prototypes to the minimum needed to bring the idea to life and answer our key questions. Sometimes our prototypes have consisted of a single screen showing an ad for a new feature. In our most recent design sprint, rather than prototype a whole user flow for a new app idea, we mocked up how it would look in the app store.

Our prototypes haven’t all been perfectly polished. They’ve rarely contained pixel-perfect design, or followed the Guardian’s brand and style guidelines, for example. But that’s okay for a design sprint. As long as each prototype communicates an idea clearly, you’ll learn a lot from it, and if users don’t respond well to it, it’s much easier to throw it away than a prototype you’ve spent ages on.

Most of all, it’s been valuable to have the whole team be able to gain experience of prototyping--I’d take this over perfectly-polished prototypes any day.

It’s okay to make a bunch of prototypes

Google’s design sprint method sees the team create one or two prototypes over the course of a week. But it was always going to be difficult for our team to limit ourselves to one or two. When we ran our first design sprint, we were at the ‘go wide’ stage, with lots of big ideas for solving the problem. So rather than honing in on one or two ideas, we were interested in getting feedback on lots of big ideas quickly to find the ones worth pursuing.

Plus, with so many great ideas floating around, and so many members of the team excited to be involved in prototyping, it seemed a shame to limit our prototype output to just one or two.

We ended up with four prototypes to show users at the end of our first design sprint; in subsequent sprints, we’ve shown as many as six. At first, we were worried about overwhelming users by showing them too many prototypes in one session. But it’s worked out fine. Our prototypes have generally been simple enough that they’ve been easy to show people--for the most part, users haven’t seemed overwhelmed, and we’ve gotten genuine reactions.

Best of all, we’ve learned way more than we would have otherwise. After each of our design sprints, we’ve had a better sense of which ideas to take forward into live tests on the Guardian site or app--and sometimes the best thing to take forward hasn’t been one single prototype, but the best bits of a few different prototypes.