The excitement that comes with your teams’ new ideas can often be lost as team members debate options and strategies. In this stage, costs tend to pile up and team productivity can be lost. Utilizing a Google Design Sprint framework can help your company reduce the risks associated with bringing new projects into the market. A well-executed Design Sprint is a methodical, time-constrained process that allows teams to visualize ideas and create and test prototypes without wasting unnecessary hours, funds, or manpower. During a sprint, companies can create and reliably test software design options in a matter of days, as opposed to several weeks or months.
In a nutshell, Google’s sprint process is a five-day process that allows users to quickly identify the challenges the software team needs to solve.
Here’s what it looks like:
Day 1: Understanding
The first day is dedicated to understanding a problem and focusing on a desired end goal. The sprint is a backward-mapping process; the team should begin with the goal in mind and work backwards to determine the steps to take to meet the goal. Throughout Day 1, team members should explore the design opportunity, voice questions or concerns about possible difficulties in meeting the goal, and map out a series of 5-15 steps that would occur to meet the objective. Part of the day should be spent conferring with experts who will explore “How we might’s” – the ways in which progress might be made and pitfalls might be overcome.
An important person on your Google sprint team will be the “decider.” On Day 1, choose a team member to fill this role. The “decider” is someone who will make tough decisions when the team is stalled or at an impasse. This team member will allow the sprint to continue in a timely fashion.
Day 2: Diverging
The day is dedicated to exploring possible solutions to the problem targeted on day one. The team should begin by examining existing and potential solutions while also reviewing their pros and cons. Competitors’ ideas are excellent starting points. At this part of the process, all ideas are fair game, no matter their perceived feasibility.
Team members should take part in brief, 3-minute presentations to share existing or potential solutions to the problem posed in Day 1. During presentations, team members are encouraged to produce sketches to depict possible solutions. The ideas presented – not the artistry – carry importance.
In the afternoon of Day 2, the team members should complete the Google sprint’s “Four-Step Sketch” process. In this process, members are asked to:
- Gather notes from discussed and displayed information
- Formulate several potential solutions
- Create eight, one-minute sketches of potential solutions
- Create a three-panel storyboard illustrating the solution process
During Day 2, team members should also consider potential customers who might be prototype testers on Day 5 of the sprint. You might wish to ask consumers new to your software, or consumers who might benefit from the product you are proposing. A minimum of five, maximum of 10 testers should be secured. Consider who would best meet your research needs then design a questionnaire to help sort and filter applicants. Consider where to post your screening questionnaire; for example, in a Google Form to customers or on an employment-seeking platform.
Day 3: Converging
Day 2 should have provided your team with a host of potential solutions. During Day 3, your team will examine each potential solution, and narrow the possibilities down to those that offer the very best ideas.
Display all of the sketches from Day 2 and have team members take a silent gallery walk while selecting their favorites. Team members may do this by placing stickers or sticky-notes beside sketches they favor. Use this silent feedback to divide winning ideas from those that may have potential at a later time. Focus the team on the winning ideas and decide whether several of them might be merged into one prototype to address the problem.
As a team, create a storyboard that illustrates the creation of the proposed prototype. Again, ideas are important and artistic talent is not. Have team members add just enough detail to have their ideas understood.
If team members get mired down in details or become overwhelmed by possibilities, remember to lean on the “Decider” team member to keep up the pace in the sprint. Trust this individual to make the best decision possible and move on.
Day 4: Prototype
On Day 4, team members will bring Day 3’s storyboard to life. Team members will use Day 4 to divide and conquer the prototype creation. To help move the process along, members may be assigned roles in which they gather resources, complete writing tasks, or physically make the prototype.
Prototype creation should be pragmatic and should focus on including what is necessary. All team members should review the prototype to check for errors and to ensure that it accurately represents the team’s ideas. In addition, the team members who will conduct the interviews should be familiar with the prototype.
Interviewers should take time on Day 4 to create a script to be used with prototype testers. The interview should contain five basic parts:
- A welcome where the tester is made to feel comfortable small talk that evolves to information about the prototype
- Introduction of the physical prototype
- Time for the tester to explore and determine how to use the prototype (supported by interviewer questions as needed to help guide the tester)
- Debriefing, where the customer answers questions about his or her experience with the prototype
Finally, on Day 4, testers should be reminded of their participation in the Day 5 prototype testing. In addition, any thank you gifts/gift cards to be shared with testers should be secured.
Day 5: Testing Day!
A testing area should be readied prior to your testers’ arrivals. You may wish to have a testing room equipped with video capability, so that the sprint team members can watch testers’ reactions in real-time. The testing room should be comfortable and clean, with minimal distractions.
The interviewer should lead the interview, following the script. Whenever possible, open-ended questions should be used to encourage tester response.
As interviews are conducted, sprint team members should watch and take notes in real-time. Notes can be made on sticky notes, and these may be posted in a grid or table that organizes data from each tester’s experience. Team members should have discussions about observations – quotes from the interview, tester’s actions, etc., – but notes should remain factual and objective.
At the end of the day, sprint team members should debrief and summarize what was observed throughout the day. What patterns emerged? Were any problems identified? What worked, and what did not? All information gleaned can become fodder for further research. With each successive sprint, a prototype can be sharpened to better meet the needs of consumers.
Google Design Sprint: Key Takeaways
At their core, the main purpose of design sprints is to align stakeholder expectations with the goal of the sprint at an early stage, and not lose sight of them throughout the rapid-fire process. As such, it is crucial to adopt a collaborative and user-centric approach to explore the most viable solutions.
Although the 5-Day Google Design Sprint has been proven to be an effective model for rapid product testing, it is a relatively new concept that may take a little getting used to. Don’t worry if your team struggles to keep pace with the 5-day framework. Expect a learning curve as everyone in your team becomes familiar with the process. Properly applied, a Google Design Sprint can save your team time and money while providing targeted solutions to consumer problems.
Ready to innovate faster than before? Tell us all about your project.
