Google Sprint Pro Tips – What I Learnt from Doing a Google Sprint

If you’ve never heard of a Google Design Sprint, it’s worth checking out.  The idea comes from the people at Google Ventures and is based on a methodology for making big decisions quickly.  As employees from Google Ventures have learnt, a lot of resources, money and time can be wasted designing, testing and prototyping ideas that do not translate well when released in the market.  The idea with a Google Sprint is to reduce the amount of time and resources it takes to make these decisions and to start the process based on well-defined motives and real-life consumer feedback.

According to the Google Sprint website:

“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.”

Sprints take place over the course of one work week – 10am to 5pm every day.  This decision was made after a series of tests in which shorter and longer time periods were used, and still allows employees to check email and perform tasks in the morning.  Each day of the week is broken down into timed activities in order to get results and make decisions that will affect the rest of the week’s plans.  The people at Google Ventures have also made a recommendation that no more than 7 people be included in the Sprint.  Within the group of 7, 1 participant is deemed the “Facilitator” and is in charge of keeping the week’s activities on track. They do not participate in every activity, but rather lead the others according to the timeline and activities identified in the Sprint guide. Another participant is given the “Decision Maker” role in order to make the final decision around certain ideas.  This eliminates any issues with the team not being able to come to mutual agreement and for the best results, this person should be directly impacted by the final outcome as they ultimately have veto power.  Google Ventures recommends that the remaining participants include: a finance expert, a marketing expert, a customer expert, a design expert and a tech/logistics expert.

The Sprint process is fully outlined in the New York Times bestseller, Sprint, and includes information on what material is needed and what snacks to feed the team throughout the week in order to get the best results. Below I have summarized Blue Link ERP’s Sprint experience, but for more information and full details on how you can run a Sprint, be sure to find the book or visit their website: http://www.gv.com/sprint/.

Monday: Map out the problem and pick an area to focus. 

Day 1 starts out by setting a long-term goal that dictates the purpose of the Sprint. With this goal in mind, the next step is to create a list of questions that need to be answered in order to achieve said goal.  These steps are important as the entire Sprint process needs to align with the goal and questions.

The second part of Monday involves sketching out a map.  The map starts with a list of customers and key players and ends with the final objective of each key player.  For Blue Link the map started with users and ended with their final objective: Get Job Done.  A flowchart in-between connected users with the final objective by mapping out how users interact with our ERP system. Initially, this mapping activity seemed like an overwhelming task - how do you encompass all areas of the system in a map outlining the user experience? However, once we started working on this process it turned out to be a relatively simple task. Essentially we determined that each user of Blue Link has different reasons for using the software and then different requirements once logged in, however, the workflow for each user is the same:  find information and access screens in order to complete their tasks and get their jobs done.  This thinking led us to two simple questions:

(1) Why would a user need to open Blue Link ERP?

(2) How does a user get the information they need once they have launched the system?

We determined that the answer to the first question would depend on the user.  Someone responsible for data entry would open Blue Link in order to process a transaction, or due to a specific alert. Someone in a management position with decision making power would open Blue Link in order to respond to an inquiry or alert, or in order to perform a workflow event.  Lastly, we determined that a business owner would open Blue Link in response to an inquiry or alert. This process of mapping each interaction with the software included more detailed insights from each expert in the group.  As a team, we interviewed each participant with regards to the map we had drawn and wrote notes about additional questions and concerns we had.  The notes were imperative as we would later vote on which ones we thought were most important to address throughout the week.

The answer to the second question took a bit more thought as we determined that there are currently several ways in which a Blue Link user can get the information they need and that this specific part of the user experience could be improved upon.  Ultimately it was this specific process – how users get the information they need and access the relevant screen(s) – that we decided to focus our Sprint on.  However, in order to get the best results we also needed to choose a group of users to focus on and so taking into consideration the notes we had written, we chose to focus on the group of key players we identified as decision makers.

Pro Tip #1: Mapping out your process and the problem can seem like a daunting task, and so it is important to keep it simple.  For Blue Link, the map involved a decision maker, responding to an inquiry, alert or workflow event, navigating to the relevant screen and/or information and then taking action to get the job done. Instead of going into the details of each possible inquiry or workflow event, we kept it generic. This allowed us to focus on the actual problem without getting caught up in the details.

Tuesday: Sketch ideas and possible solutions on paper. 

For those who enjoyed arts and crafts as a kid, Tuesday is the best day.  The morning starts out by each Sprint participant quickly showcasing examples of existing products or systems they like in order to get ideas for the final prototype.   In the afternoon, each participant is then responsible for sketching out ideas based the information gathered in the morning, and always keeping in mind the goal and questions identified on Monday. Each person draws their own sketch without any collaboration with other members of the group.  The idea is to be as detailed as possible and keep each final sketch anonymous so each one can be objectively evaluated the following morning.

Pro Tip #2: When searching for examples of existing products or systems to showcase, make sure you think outside the box. The examples you show do not have to be from a similar industry or even targeted towards the same market. Remember, at this point in time, you’re trying to find big ideas so as to not limit your prototype design.

Pro Tip #3: More detailed sketches are better.  It was easy for our team members to assume certain pieces of functionality and therefore not fully illustrate them in the sketch, however, it was ultimately the more detailed sketches that became a part of the prototype. If you are not able to draw some of your ideas, include text anywhere possible in order to clearly outline the information. More detailed sketches also reduce the amount of work required Wednesday when turning sketches into a storyboard.

Wednesday: Narrow down options and make difficult decisions in order to transform ideas into a testable prototype. 

Wednesday was by far the most tiresome day as it required a lot of decision making.  First thing in the morning we evaluated each sketch, and then voted on which sketches and parts of sketches we liked best, as well as which ones we thought would best answer our Sprint questions and goal. This was also the day in which we put the facilitator to the test in order to ensure we followed the time frame set out for each activity.  We had a lot of decisions to make in only a short period of time.  In the afternoon we took our favorite parts from each sketch and expanded on the information to actually create a storyboard for what would ultimately become our prototype. This is where detailed sketches helped because we did not have to re-draw certain parts of the storyboard.

Pro Tip #4: Make sure to always focus on the specific problem and goal you have identified on Monday. It was easy to get sidetracked thinking about how other key players would prefer to get information from Blue Link and how that might differ from decision makers, but that was not the point of the Sprint.

Thursday: Design a prototype and prepare for live interviews.  

On Thursday the point is to design a workable prototype to showcase in front of customers/potential customers on Friday.  The motto of the day is “fake it until you make it” – the idea being that simple tools such as PowerPoint can be used as a quick and easy prototype tool. For Blue Link, designing the prototype in Access was just as easy as it is one of our standard development tools. Thursday is also the day set aside for designing the interview questions and setting up the interview room.

Pro Tip #5: Do not get caught up in the details of the prototype.  Not everything needs to work perfectly and not showing specific information can be just as useful as showing specific information.

Friday: Test prototype with a live audience.

Finally, Day 5 of the Sprint is designed to get real-world feedback from a live audience. Interviews are conducted in a private room by one member of the Sprint team, while the remaining members watch live from another room. The idea is that the interviewer’s focus is strictly on going through the prototype, while the remaining participants can listen, watch and take notes.

Pro Tip #6: Make sure you accurately explain the prototype and interview process to your live audience before inviting them to participate.  This ensures your audience does not have any preconceived notions about the Sprint process and their involvement.

Pro Tip #7: If necessary, make sure your audience understands that the information as part of the prototype is just an example of the information that they could be seeing.  Although the wording is important, it is also important that your audience does not get caught up over specific information being displayed if that information is a placeholder. Use generic examples wherever possible.

Final Result

When all is said and done, you are left with a working prototype and feedback from 5 people.  What now? The book states that no Sprint is a waste, even if the ultimate result is that none of your ideas will be used. Ultimately a Sprint provides you with enough information to learn, in a week, whether or not you’re on the right track with your ideas. The important part is to decide what to do next. Based on the feedback provided by your interviewees, look for patterns and key ideas.  Decide which parts worked and which didn’t.  If the Sprint has answered your questions from Monday and aligns with your goal, maybe you have enough information to begin full development, or maybe you decide to run another Sprint, or parts of a Sprint, with a different focus. Whatever you decide, make sure you take action soon – keep the momentum of the Sprint and don’t let the results go to waste. For Blue Link, we decided that the next step would be to run another sketching session based on the feedback gained from the interviews.

Visit our Resource Library