Innovation Sprints … solving big problems and testing new ideas for innovation in five days

June 15, 2018

Jake Knapp began running design sprints at Google in 2010. He worked with teams like Chrome, Google Search and Google X. In 2012, Jake brought sprints to Google Ventures and started applying the methodology to external companies.

The sprint methodology embraces story-centered design, an unconventional approach that focuses on the customer journey instead of individual features or technologies. It also takes customer research—which can typically take weeks to plan and often delivers confusing results—and figures out a way to get crystal clear results in just one day. Crucial is to start at the end, and focus on measuring results with the key metrics from each business. It’s also good to have the insights of a resident entrepreneur on the team to ensure every step made sense in the real world.

The sprint is a five-day process for answering critical business questions through design, prototyping, and testing ideas with customers. Developed at GV, it’s a “greatest hits” of business strategy, innovation, behavior science, design thinking, and more—packaged into a battle-tested process that any team can use.

Working together in a sprint, you can shortcut the endless-debate cycle and compress months of time into a single week. Instead of waiting to launch a minimal product to understand if an idea is any good, you’ll get clear data from a realistic prototype. The sprint gives you a superpower: You can fast-forward into the future to see your finished product and customer reactions, before making any expensive commitments.

Create your own “Sprint” innovation lab

On Monday, you’ll map out the problem and pick an important place to focus. On Tuesday, you’ll sketch competing solutions on paper. On Wednesday, you’ll make difficult decisions and turn your ideas into a testable hypothesis. On Thursday, you’ll hammer out a high-fidelity prototype. And on Friday, you’ll test it with real live humans.

Set the Stage

Before the sprint begins, you’ll need to have the right challenge and the right team. You’ll also need time and space to conduct your sprint.

• Checklist for Set the Stage
• Your design team needs a war room; here’s how to set one up

Monday: What’s the Problem?

Monday’s structured discussions create a path for the sprint week. In the morning, you’ll start at the end and agree to a long-term goal. Next, you’ll make a map of the challenge. In the afternoon, you’ll ask the experts at your company to share what they know. Finally, you’ll pick a target: an ambitious but manageable piece of the problem that you can solve in one week.

• Checklist for Monday

Tuesday: Sketch your ideas

After a full day of understanding the problem and choosing a target for your sprint, on Tuesday, you get to focus on solutions. The day starts with inspiration: a review of existing ideas to remix and improve. Then, in the afternoon, each person will sketch, following a four-step process that emphasizes critical thinking over artistry. You’ll also begin planning Friday’s customer test by recruiting customers that fit your target profile.

• Checklist for Tuesday

Wednesday: Choose the best

By Wednesday morning, you and your team will have a stack of solutions. That’s great, but it’s also a problem. You can’t prototype and test them all—you need one solid plan. In the morning, you’ll critique each solution, and decide which ones have the best chance of achieving your long-term goal. Then, in the afternoon, you’ll take the winning scenes from your sketches and weave them into a storyboard: a step-by-step plan for your prototype.

• Checklist for Wednesday

Thursday: Build a prototype

On Wednesday, you and your team created a storyboard. On Thursday, you’ll adopt a “fake it” philosophy to turn that storyboard into a prototype. A realistic façade is all you need to test with customers, and here’s the best part: by focusing on the customer-facing surface of your product or service, you can finish your prototype in just one day. On Thursday, you’ll also make sure everything is ready for Friday’s test by confirming the schedule, reviewing the prototype, and writing an interview script.

• Checklist for Thursday

Friday: Test with customers

Your sprint began with a big challenge, an excellent team—and not much else. By Friday, you’ve created promising solutions, chosen the best, and built a realistic prototype. That alone would make for an impressively productive week. But you’ll take it one step further as you interview customers and learn by watching them react to your prototype. This test makes the entire sprint worthwhile: At the end of the day, you’ll know how far you have to go, and you’ll know just what to do next.

• Checklist for Friday
• Interview customers and summarize findings
• The Five-Act Interview with Michael Margolis

In many ways Google Sprints are very similar to the Deep Dive methodology which was originally pioneered by design firm IDEO led by David and Tom Kelley. They continue to pursue the methodology, in particular with a user-centric focus. Most famous was their “Shopping Cart” challenge of almost 20 years, a video of which has become folklore in the innovation world.

Here’s an extract from The Guardian reviewing the Sprint methodology:

Jake Knapp’s book has been a hugely valuable resource. 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.

---

More from the blog