A Practical Approach to Implementing Google’s Process

In this article, we’ll review the quick & dirty ways you can run through each stage of the GV Design Sprint without allocated time or resources. If you’re not yet familiar with the Sprint, check out this basic guide before reading.

In 2012 the GV (formerly Google Ventures) team introduced the Design Sprint, a 5-day process designed to help teams solve big problems by designing, prototyping, and testing ideas. Unfortunately, in organizations new or resistant to design sprints, convincing management to allocate the considerable time and resources needed to run a complete sprint may prove difficult. So, although GV’s 5-day process is ideal, we can still derive value by synthesizing the team’s methods to be used by designers, product managers, and others looking to use sprint methodologies in their organizations.

The GV Design Sprint is made up of five stages — map, sketch, decide, prototype, and test. This article will act as a guide to condensing these stages for website/app/software design projects.

Map & Sketch

The GV Design Sprint starts on Monday with mapping out the problem and deciding which part of it to focus on. During this stage, the team develops a common understanding through a number of methods including team and user interviews, competitive research, and analytics analysis. On Tuesday, the team participates in a number of sketching exercises in order to generate ideas.

In our practical approach to the sprint, we’ll compress these two stages from two days to two hours through what I like to call a “design kickoff” meeting. The title here is actually kind of important — I’ve found that calling it a “sketching session” has the tendency to scare off non-creatives. During this meeting, you’ll discuss the problem for the first hour and sketch ideas for the second hour. Two hours is ideal, but if you need to condense the meeting further, prioritize the sketching portion — spending either 30 minutes on the problem and one hour on sketching, or 15 minutes on the problem and 45 minutes on sketching. I’ve made the one hour meeting work, but fair warning — to do so I had to play bad cop, timeboxing activities to the second and cutting off productive discussions.

In terms of participants, while the GV Design Sprint calls for a team of seven, you’ll only need four to hold a design kickoff. The first three attendees are representatives from Product, Design, and Engineering, respectively. While the combination of a product manager, designer, and engineer is ideal, if you can’t recruit these roles you can compensate by finding people who are able to think with a department-centric mindset. The fourth attendee is more ambiguous — you may want to invite a subject matter expert, or simply a team member who’s interested in design sprints.

Design Kickoff
Time: 2 Hours

40m Problem Presentation
20m
Team Discussion
10m
Idea Sketching
20m
Solution Sketching
30m
Team Presentations

The first hour of the meeting will be used to discuss the problem and get everyone on the same page. However, instead of the team collectively conducting user interviews or auditing competitors, you’ll do this on your own beforehand and present your distilled findings to the group. I strongly recommend presenting both quantitative and qualitative metrics, but you can sometimes make due with anecdotal data if you don’t have access to analytics software or resources. I like to put together a short presentation containing the problem, metrics, and any other relevant information, like product screenshots or UX metrics. After the presentation, each person will spend 5 minutes sharing their own perspective on the problem.

During the second hour of the meeting, the team will focus on generating ideas you’ll later use to create a testable prototype. For the first 10 minutes, each person will individually organize their ideas on scratch paper. These ideas can manifest as rough notes, doodles, diagrams — they won’t be shared with anyone, so there’s no need to be too precise. Once time is up, the next 20 minutes will be spent individually sketching one or two solutions in detail, showing how a user will interact with the idea. While GV recommends sketching these solutions in a storyboard format, when designing software I’ve personally found that teams have an easier time sketching a simple screen flow instead.

Unformatted ideas (left) and screen flows (right)

For the remaining 30 minutes of the meeting, each team member will present their solutions, answering questions and soliciting feedback from the rest of the group—take thorough notes so you can remember the complexities of each solution presented. When the meeting is over and the team has disbanded, you’ll have plenty of inspiration to move forward to the next stage with.

Decide & Prototype

On Wednesday of the GV Design Sprint, the team votes on which idea to prototype and test, and collectively sketches a detailed storyboard that shows exactly how users will interact with the prototype. On Thursday, the team works together to build the functional prototype.

In our practical approach, you alone will decide how to proceed with the ideas generated during the design kickoff. You may want to prototype one solution that received a lot of positive feedback, combine different aspects from multiple solutions (usually what I end up doing), or even prototype and test two conflicting solutions against each other. If you choose to combine multiple solutions, quickly sketch a new screen flow on paper with the stitched-together ideas — it will be helpful to refer back to when building the actual prototype.

Once you have a finalized solution, you can begin the prototyping stage by writing down high-level tasks you’ll ask users to complete during their interviews. For example, if testing out an idea for a checkout flow, you may want to ask users to simply purchase the items in their shopping cart. Keep the tasks vague enough so as to not lead the user, but specific enough so you can limit the number of screens required in order to test the idea. Review your screen flow and modify if needed — you may be able to exclude one or two superfluous screens.

After the high-level tasks have been determined, sketch your screen flow once more on paper, this time in more detail. Include visual elements the user may not directly interact with but would expect to see, like top-level navigation and form components. Be sure to also include text elements like headers, labels and contextual help, but do not use placeholder text.

As you sketch each screen, think through exactly how you expect the user to interact with it, and write down specific questions to ask when he or she is doing so. Thinking back to the checkout example — before prompting the user to directly interact with the prototype, it may be helpful to ask a few questions like, “Could you tell me what you think the purpose of this screen is?” or, “Before you do anything, could you tell me what you’re going to tap/click on and what you expect to happen?” These questions, along with the high-level tasks you’ve written down, will serve as the script you’ll use when interviewing users.

When conducting interviews, I almost always get a question like, “What does this button do?” Don’t answer — instead, ask, “What do you think it does?”

Once you have a detailed sketch for each screen, you can move forward with creating a higher fidelity interactive prototype. Now, if you’re really short on time, you can use your existing screen flow as a paper prototype — but I wouldn’t recommend it. In my experience, users find it difficult to see past the obvious facade of software, and as a result tend to have more trouble completing tasks and are more restrained when providing feedback. Creating a clickable prototype using presentation software like Google Slides is a relatively easy way to fake the look and feel of an interface, creating enough of an illusion to allow users to focus on tasks given instead of the prototype itself.

While GV touts the benefits of using Keynote to prototype, I prefer Google Slides because it’s readily available and files are easier to share.

If you have digital design experience and are comfortable using Sketch (an application I highly recommend for all designers), you may be interested in Google’s material design sticker sheets for Sketch — these files include visual elements for both web and mobile layouts, including status bars, app bars, toolbars, cards, icons, and more which will allow you to quickly create a polished high fidelity prototype. Apple provides a few of these too, but they aren’t as comprehensive as Google’s.

Test

On Friday, the last day of the GV Design Sprint, the team tests the prototype by conducting five user interviews. Once the interviews are complete, the team discusses patterns they observed, documenting their findings and next steps.

If you’re trying to condense a design sprint, chances are you don’t have the time or resources to plan and conduct comprehensive user interviews. That being said, there are a few methods you can use to get relevant feedback on your prototype quickly and cheaply.

While not ideal, the fastest and most inexpensive method is to use co-workers as your interview subjects. Co-workers can be a useful source of validation if chosen objectively — try reaching out to employees outside your engineering organization, looking for those who most accurately match the characteristics of your ideal user. Another option is to use Craigslist to recruit interview subjects. This method requires your company spend about $100–$125 to post an ad and compensate the subjects, but it does provide you with less biased feedback and the ability to screen for characteristics. Here’s an example of an ad I posted:

$20 for 20-min user research interview on 4/23 (Downtown Boston)
Tech startup located in downtown Boston scheduling 20-minute user research interviews on Thursday, 4/23. Participants who complete the interviews will receive $20 Amazon gift cards. Please complete this short questionnaire: https://goo.gl/forms/baGmswSmJCbTAnXj2

Check out the Google Forms link in the ad — I redacted the form so it can be used as a base template for screening questions.

Another method I’ve had the most success with — if your company has friendly clients or partner companies with local offices, you can try reaching out to their office admins (work with your Customer Success team to facilitate) to propose a day of on-site interviews with their employees. Here’s a template I created used by CS team members to send to client contacts.

When it comes to conducting the interviews, we can pull directly from GV’s playbook even when time constrained. A minimum of five user interviews should be conducted in order to establish reliable patterns. If you can, recruit one of the design kickoff attendees to record notes while you interview the subjects. Once the interviews are complete, review these notes for patterns, documenting them in order to inform your next steps.



SOURCE