Google

Launch Dashboard

Right_110

Project

Google Cloud has thousands of feature and product launches a year, and those launches are being tracked in 3 separate systems for engineering. The teams responsible for the marketing of these launches were relying on bits and pieces of information and tribal-knowledge to know what was coming when and who needed to do what. Launch Dashboard was created to serve as a single source of truth for all launches. This kept disparate teams informed and aware of ongoing developments and materials needed for successful launches.

Role: UX / UI, Research Facilitator

Update

Based on the audit and interviews, we completely revamped the digital system, cleaning up some difficulties from editing launches across multiple phases, to applying a set of to-dos (BOMs). Additionally, the team and I developed an improved base to build on for future iterations.

LD-before

Before

LD-after

After initial phase of improvements

User Testing & Interviews

With an improved app on hand, we started an iterative process using prototyping and testing with Google’s employees. This was done in effort to validate assumptions, confirm hypotheses, and create a culture of constant improvement around the application. We used interviews to identify the needs of additional user groups to keep more members of the organization in-the-know.

Iterations

Early testing showed that our users struggled with the card views that were proposed as part of the MVP build. The dashboard was redesigned to allow for easy sorting, searching, and filtering, and gave improved at-a-glance information. In addition, we were able to eliminate steps within the view/edit flows by giving increased information to users as part of info panels before clicking into individual launches. A history section gave managers a line of sight to who had started what and when, and identified at-risk deliverables based on timing data collected by the system from past launches.

LD-dash (1)
LD-open

Different roles value and emphasize different parts of a launch. Managers and PGMs needed to view launches and their readiness as it related to the overall calendar of launches. Individual contributors like social media managers and bloggers needed to see launches based on their assignments and the progress of their deliverables.

LD-tasks
LD-Cal

In our interviews, we also were able to identify new user types less active in the launches themselves but that still had dependencies on their progress. We created a system of settings to help users identify what launches they needed to be aware of based on existing data about incoming launches, and then allowed for those users to create custom alerts based on their own preferences.

LD-roles
LD-notifications

Conclusion

All together, we were able to create and update a successful complex tool for thousands of users that increased efficiency and user adoption.