Scroll Top

Google Design Sprint

Google Design Sprint (GDS) is a methodology based on modern design thinking that focuses on rapid iterations, an immersive experience, accelerated collaboration, and decisive decision making. GDS is a part of our “fail fast, recover fast” culture that increases the value of digital products by providing exceptional user experiences and a faster time to market while minimizing quality, schedule, and security risks through early discovery, collaborative ideation, and open thinking. GDS is executed over a 5 day work week since planning and coordination are easier due to the structured days and the commitment of participants.

0Day Zero: Preparations

Our Product Owner and Scrum Master prepare for GDS activities.

  • Setting the Stage: The PO draws an Epic or Feature from the Product Backlog. The Scrum Master sets aside the time, prepares the tools, validates that everyone has access, and coordinates with senior leadership to verify that the selected team, experts, and other stakeholders will be available during the week of GDS. For many projects, we use Jira to manage our work, Confluence to store our artifacts, GitHub as our repository, and, recently, Sympli to manage the interactions between designers and developers for rapid, accurate, and clear hand-offs.
  • Building the Team: In consultation, the Scrum Master, PO, and PM decides on the appropriate combination of skill sets, domain experience, functional expertise, and diversity of perspectives that are needed to accomplish the design tasks.

1Day One: Framing the Problem

We begin on Monday by mapping out the problem and picking an important feature or functionality on which to focus. The PO holds a kickoff meeting, and the Scrum Master conducts the Sprint Planning ceremony with the collective team.

  • Problem Statement: We describe the scope, scale, and purpose of the feature or functionality and frame the problem by defining the challenge, setting long-term goals, and understanding key user groups and stakeholders.
  • How Might We: We develop “How Might We” questions to expand our open thinking and begin our ideation sessions. Using this format, we realize that suggestions are possible as we simultaneously allow ourselves the creative freedom to explore primary and secondary ideas. As necessary, we engage experts to further explain key concepts, challenges, or opportunities.
  • User Experience: We employ UX research methods to identify user goals, needs, behaviors, motivations, frustrations, and pain points. Our UX Researcher develops artifacts such as primary persona, customer journey, and empath map. As needed, we conduct additional interviews or perform a card sorting activity for clarity.
  • User Story Decomposition: We structure the scope of work with user stories that focus on actual user needs. The user stories are broken down into manageable work that reflect user insights.

2Day Two: Solutions

On Tuesday, we are reviewing existing solutions and then sketching competing designs.

  • Lightning Demos: We examine solutions that are internal to our team or company as well leaders in the space. We walk through the existing functionality in order to understand how people understand and solve the problem today. Our goal is to become knowledgeable about the issues and begin to come up with new solutions.
  • The Four-Step Sketch: While brainstorming harnesses the creativity of the more vocal members of the team, it can be detrimental to the overall process, especially in groups where diversity is prized. We use brainwriting to allow individuals to work on their own ideas for specific amount of time. Using the Crazy 8s techniques, we ask each team member to jot down their own notes and create eight fast and simple designs based on their perspectives and experiences. Afterwards, we share those ideas and discuss them as a group.
  • Recruit Testers: Our Scrum Master and UX Researcher select the users that test the high-fidelity prototype on Friday. Ideally, we recruit testers from an existing pool of qualified candidates from the target audience.

3Day Three: Design

By Wednesday, the team is making difficult decisions and turning our ideas into a testable hypothesis.

  • Sticky Decision: After generating multiple ideas, we select a winnable idea through a silent vote. As the Decider, the PO is a supervoter and is able to select three designs. The Scrum Master stores all non-winning designs in our document repository.
  • Storyboards: The winning design is expanded upon by our team. Led by our UI Designer, we create a visual design based on information and insights documented in our UX artifacts.
  • Prototyping Prep: Our Developer begins to pull together the technical elements needed for the high-fidelity prototype. Ideally, the environment has been set up, the tools have been loaded, and the Developer is familiar with the technical stack. For instance, we selected a Developer with React experience when doing rapid development for a design prototype for a large Federal web site.

4Day Four: Prototype

We develop a high-fidelity prototype on Thursday that allows us to visualize the designs in action.

  • Prototyping: The Developer continues to develop the high-fidelity prototype. Ideally, the PO has constrained the scope to a single feature or piece of functionality that can be rapidly developed in a structured framework. The prototype is developed to allow users to click on the links to travel to other pages, but no data, non-functional elements, or system-level interfaces are developed.
  • Design Refinements: As necessary, the UI Designer collaborates with the Developer for any necessary design refinements. The PO adjudicates as necessary.
  • Test Prep: The UX Researcher prepares for the user testing with activities such as scheduling, finalizing interview questions, and preparing the space.

5Day Five: User Testing

On Friday, we conduct user testing of the high-fidelity prototype, perform interviews, and analyze our results.

  • User Testing: The UX Researcher, with assistance from members of the team, conducts the user testing according to the test plan. The team collects the results and analyzes them against the design, problem statement, and earlier assumptions. The team prepares for and attends the final sprint ceremonies, including the Sprint Demo to the PM/COR and the internal Sprint Retrospective.

Building the User Experience

GDS eliminates obsessive overthinking and analysis paralysis. Teams who adopt this methodology are user-focused and deliver rapid releases. GDS works very well with SAFe, DevSecOps, and Continuous Delivery to create a highly-charged value stream. Contact us to learn more about how GDS can super charge your environment.