How Rootstrap Taught The Google Opus Team Design Sprints

  • clients

    Google Opus

  • duration

    1 week

  • team

    1 Design Director

    1 Designer

the client

Google Opus

They wanted to transform both business processes and software systems with a new product suite called Opus that would make work more efficient and agile.

the challenges



Find innovative ways of transforming both processes and tooling, to allow operations teams to meet team work order goals.



Create a product suite that boosts overall happiness and operation teams’ productivity

Rootstrap was brought on by the team to support
a design sprint for the new product suite.


In early 2018, certain Google datacenter teams determined that switching to a queue-based execution model would improve the work efficiency and throughput rates of build project work.

They were also using software tools to gather relevant information for the same project, which showed that software systems were another area for potential growth.

    Creating a new product

    The Google Opus team wanted to create a new product suite that would:

    • Maximize work throughput
    • Accelerate onboarding of new products into datacenters
    • Guide all operations teams towards the most important work on the floor
    • Orchestrate work between teams
    • Maximize utilization of people
    • Minimize the number of task-specific tools

    With so many moving parts, the team decided this was the perfect candidate for a design sprint. That’s when they reached out to Rootstrap.


    before the sprint

    Rootstrap team members worked with Google Opus to define their goals and consider possible deliverables.

    While a traditional design sprint would be five days, due to scheduling constraints they had only two days. The goal was to rapidly generate actionable ideas that could be completed in a more leisurely timeframe afterwards.


    day one

    On day one, the team dove into lightning talks to better understand the product goals, the design evolution of the existing software tools, current user journeys, pain points, and technological opportunities. They selected the main personas for this project and mapped the user journeys from start to finish. From there, they further narrowed the main target area for the sprint and moved into sketching.


    day two

    Day two was dedicated to expanding each participant’s ideas into presentable solution sketches that they would share with the rest of the team. The group discussed each sketch and highlighted the best features, ultimately voting on the best solution to prototype.

    Next, the team broke
    into two groups,

    one to create a final storyboard of the winning solution sketch, and another to discuss the technical feasibility of the winning solution and solutions to any of the technical challenges they identified.


    During the final discussion of the sprint, Opus needed to test the new solutions they had developed to gather feedback from their core users and understand how to truly improve their daily workflow.

    Through the initial brainstorming, it became clear that internal communications and processes within the Google Opus team needed to be codified. Solutions included the introduction of collaboration tools, documentation, and a set engagement model.

    At the end of the Sprint, the
    Opus team felt they had a clear vision and action steps for the coming year in just two days.

    The team began user testing and iterating
    on their solution from the Sprint. They also used the defined foundation to expand into
    the greater requirements of the full
    Opus product suite.