Google Design Sprints

https://www.youtube.com/watch?t=2&v=qvdO0G4uQgc

Google Design Sprints were originally developed at Google Ventures to help their startups move quickly from problem to idea to prototype to feedback, all in five days time. They can, however, have much broader application, in companies of every size, and in agencies, as they work with clients to iterate on new campaigns.

Google Design Sprints are based on the design thinking championed by Ideo and the Stanford d.school, but there are a few crucial differences:

• What Google calls the Diverge or Sketch phase, or what Sean Ellis calls “unbridled ideation” is not a group activity, but done by individuals, heads down, applying their own creativity
• Deciding which ideas to go with is less about voting and cooperative group think.  Instead, it recognizes that leaders have to support the eventual design, and they have to make hard calls, particularly if choosing a radical design or direction. So the facilitator is encouraged to draw out the opinion of the leader, and ensure that they’re 100% behind the idea or ideas that are prototyped and tested.

Google Design Sprint Process

There are five phases to the Google Design Sprint process.  It is also an iterative process – after you receive user feedback in the 5th phase, you are encouraged to revise the prototype and test some more. In other words, iterate on the last two phases.  At some point, you may have to go back to the beginning if your first idea is way off the mark, similar to what Eric Ries would call a pivot.

Unpack

On the first day of the Sprint, the team unpacks all of their knowledge about the problem and the space.  The team should include people from all levels and multiple functions within the organization: senior management, marketing, design, development, user support. It helps to have a facilitator from outside the organization to keep things moving and to ask both the “dumb” questions and the hard questions.

The first day should include a short presentation by senior management on the business opportunity, competitive reviews and demos by various team members, a walkthrough of the current solution to the problem, team interviews, a review of any analytics available and some decisions about what success looks like.  What actionable metrics (not vanity metrics) are going to be used to determine success?

Sketch

During sketch day, individuals work on their own (no group think) to sketch and story board potential solutions.  Everyone, from the CEO on down, is asked to come up with a detailed solution. This is done on paper rather than using wireframe tools, both because it’s quicker and because not everyone has the skills to put together wireframes.

If the problem is large, it may need to be divided into chunks, which the group either addresses sequentially, or they divide and conquer.  Google has a great eight-step process for working through this sketch process. But whether you use their process or your own, the idea is to avoid group think and to get as many detailed ideas down on paper as possible.

If you have a large group and a lot of ideas, you may want to do some voting and some structured critiques to narrow down the field to half a dozen ideas or so before the end of the second day.

Decide

This phase is called decide, and it’s true that by the end of the day you should have the decision as to which idea (or possibly ideas) you’re going to prototype, but there’s a lot more to do on this day than simply deciding on an idea. On this day, you’re also going to identify the conflicts between the various approaches for solving the problem, which should illuminate the hard choices you have to make. You also want to write down any and all assumptions you’re making: for example, of the kinds of users, assumptions about the business, assumptions about technology, etc.

You’ll also need to decide whether you’re going to prototype just one solution (known as the “best shot” approach) or prototype multiple solutions to see which one gets the greatest user acceptance (known as the “battle royale” approach).

The final output of this third day should be one or more Storyboards that walk through the user’s interaction with the prototype, step by step.  This storyboard becomes the specification for building the prototype.  It probably also makes sense to write one or more user stories (in the Scrum sense of user story), which can also serve as part of the specification.

You’re also going to start finding research participants for the fifth day and start planning the interviews for phase 5.

Prototype

The fourth day sounds crazy, in that you’re going to build a realistic prototype in just eight hours. They suggest using Keynote and keynote templates from Keynotopia to construct these interactive prototypes.  On this day, you also finalize the schedule for the research subjects and finalize the interview script.

Test

On the final day, you test the prototypes with users, anywhere from 6 – 20 users, one on one.  Everyone takes notes and records the learnings.  At the end of the day, you summarize the learnings and decide how you’re going to iterate and improve.

Google design sprints strike me as having promise to help teams break through some difficult tasks that might take months in the normal sprint cycles of Agile Marketing.  By also bringing together people from all over the company, and from many different disciplines, they seem particularly useful in addressing the entire customer experience, something that can often be difficult to do across organizational boundaries.

If you’d like to learn more, the Google design team is working on a book describing their experiences with over 100 design sprints.  It’s not out yet, but you can sign up to be notified when it’s available.