Scaled systems for SaaS and PaaS

As the founder and horizontal UX Manager of Google Cloud’s Page-Level Components program, I stepped in to solve a critical hyper-growth bottleneck where siloed, redundant feature development was outpacing UX capacity and fragmenting the console experience. To drive design standardization at scale, I built and led the multidisciplinary UX team that designed Google Cloud’s first unified page-level Angular design subsystem. Under my leadership, this ‘grab-and-go’ system turned horizontal complexity into an operational velocity engine that saved 85 person-years of net productivity and became the de facto standard, now used across 192 adopting projects.

The challenge

Hyper-growth outpacing UX capacity

As hundreds of GCP designers, researchers and writers scaled to support 150+ products, the team could not scale in lock-step with engineering growth — and that gap became the bottleneck.

The legacy of siloed console development

• —An ease-of-use deficit. With dozens of teams each building custom, one-off features, organizational complexity bled straight into the interface. Fragmented patterns created wayfinding bottlenecks for customers and confusing inconsistencies across the platform.
• —Designer silos and repetitive toil. Designers worked in isolation, reacting to endless feature requests instead of tackling end-to-end journeys, and spent their days on low-impact implementation work.

The solution

Establish focus

Inspired by the modular components work I led with the Storage UX team, GCP's UX director created a new Page-Level Components team. She tapped me to lead this team. I shaped the team's vision and OKRs around two crisp focus areas: creating patterns and streamlining the most common user journeys. To align priorities across Google Cloud’s broader infrastructure, I designed and facilitated three strategy workshops with 30 cross-functional leaders and practitioners.

I authored, socialized and secured cross-functional buy-in for a unified three-year Page-Level Components strategy, then split the program into two specialized sub-teams so each had a distinct mandate and its own measure of success.

Fund the work

The three-year strategy would require a larger team. To close the resource deficit I pitched the business value of the cross-cutting team directly to GCP leadership. Proving that horizontal standardization would cut our cost to serve while raising user trust earned nine net-new roles to fund and staff the new cross-cutting UX organization.

The metrics program

I designed the measurement system before the patterns had shipped. I negotiated input from more than a dozen core infrastructure and platform leaders and authored a framework that answered two questions at once: are GCP engineering teams' most important work getting faster, and is it getting cheaper for Googlers to build a high-quality page. 

Adoption became the multiplier. Our baseline diary study showed that each Page-Level Component saved design and engineering ~2 months of work. Component adoption was tracked to measure the effectiveness of our overall program. 

Now the standard. Rather than publishing a fork or an isolated library, we embedded Page-Level Components directly into Google’s core Cloud Design System spec, making them the official cloud-wide standard.

The outcomes

Productivity and engineering velocity

• —De facto standards. Within four years of launch, Page-Level Components are now the de facto tool for product teams building new pages in the console. 
• —Two months saved per insert. Squads that adopted the templates cut an average of two months from their development cycles, redirecting constrained resources back to business-differentiating work.
• —85 person years saved.  With 192 adopting teams, Page-Level Components have saved 85 years of designer, researcher, and engineer time. 

• —The accessibility gate, unblocked. Standardizing page-level patterns cleared Google Accessibility and Readiness reviews that had cost teams weeks of manual fixes.