Google Cloud Config Management
Config Management is a complimentary feature included with every GKE license. Research indicated that customers who adopted it demonstrated significantly longer retention with GKE — yet it remained critically underutilized. Only 2% of customers visiting the section installed anything. Without design intervention, the engineering investment would yield minimal ROI.
- Company
- Google Cloud, 2026
- Role
- Senior UX Designer
- Duration
- 5 months
- Team
- 1 UX researcher, 6 engineers, 0 product managers
The challenge
2% conversion on a feature tied directly to long-term retention
Two root causes emerged from user research. First, 'Config Management' is ambiguous terminology in cloud services — customers were unclear about what the product actually did. Second, two distinct tools — Config Sync and Policy Controller — were bundled into a single installation flow, creating confusion about why a security feature required configuration steps that seemed unrelated.
The organizational constraints made this harder. There was no dedicated product manager. One designer supported two separate feature teams running on different release schedules. Engineering advocated for command-line solutions while Product preferred UI-first approaches. Leadership demanded rapid results. The design work had to navigate all of this while staying grounded in what users actually needed.
How I approached it
1Alignment Workshop
Building shared direction before touching the design
Alignment Workshop
Building shared direction before touching the design
- Conducted a mini-workshop with the Director of PM to synthesize existing customer feedback, define strengths and weaknesses, and establish success criteria
- The key priority that emerged: 'quick installation and fast value realization' — lower installation barriers encourage experimentation
- Partnered with the UX Researcher to build alignment between Engineering and Product teams around a single direction before any design work began
- Invited a Customer Success Engineer into design sessions early to clarify technical complexity — a decision that prevented costly mistakes and built trust with the engineering team
2Three Design Bets
The strategic hypotheses that shaped every decision
Three Design Bets
The strategic hypotheses that shaped every decision
- Bet 1 — Separating the tools: Restructured the IA so Config Sync and Policy Controller existed independently within Config Management. Each could stand alone, be discovered separately, and communicate distinct value. This required Engineering to decouple a shared backend — justified by presenting prototype and research findings directly to Engineering leadership
- Bet 2 — Rethinking zero state: Applied a pattern from separate GKE team research — showing a working product before installation drives conversion. New flow: value-first dashboard → install → observe. Applied consistently to both tools
- Bet 3 — Consistent installation flows: Engineering requested standardized patterns across both features to reduce build effort. From a UX perspective, consistency improved predictability for users switching between tools — a rare alignment of engineering and user needs
3Prototype Development
Building for research signal, not presentation polish
Prototype Development
Building for research signal, not presentation polish
- Built the full flow in Axure RP rather than Figma — HTML-based prototypes generate better research signal because users respond differently to interactive versus static mockups
- Coverage spanned Day 0 (not installed) through Day 2 (data appearing in the UI) for Policy Controller — enough fidelity to test the full mental model, not just the install step
4Research Validation
Testing with real Config Sync customers and prospects
Research Validation
Testing with real Config Sync customers and prospects
- Conducted task-based usability tests combining interviews with prototype tasks: install Policy Controller, install Config Sync, explain each feature's purpose
- Users immediately recognized two distinct tools once the IA was separated — validating the core bet
- The value-first dashboard approach worked: users consistently grasped functionality before installation
- A surprising insight surfaced: users acknowledged the UI helps experimentation but expected production environments would require command-line access — this validated a milestone 1 focus and directly informed milestone 2 priorities
- Leadership approved full prioritization for the following year based on the designs and research findings
From the process
The solution
Clarity of purpose matters more than feature richness when driving initial adoption
The redesign rested on one structural change: separating Config Sync and Policy Controller into independent tools within Config Management, each with its own zero state, installation flow, and value proposition. Users could now understand what they were installing and why — before they installed it.
Both tools got a value-first zero state: a dashboard showing what a working installation looks like before asking users to do anything. The pattern — borrowed from research done by a separate GKE team — proved out consistently. Users grasped functionality faster and felt more confident proceeding to install.
Consistent installation flows across both tools were a practical win for engineering and a usability win for users. Predictability across the product reduced cognitive load for users switching between Config Sync and Policy Controller — two tools they would often use together.
What it delivered
- 2% → 11%
- Config Sync conversion rate9-point improvement sustained post-rollout
- 0
- Product managers on the projectDesign drove strategy, alignment, and stakeholder communication
- Approved
- Full-year engineering prioritizationLeadership committed based on designs and research findings
- Replicable
- Pattern adopted across GKEValue-first zero state became a model for other features facing similar adoption challenges
Reflection
Operating without a dedicated PM forced deeper strategic thinking than any previous project. Facilitating workshops, building a design vision, and aligning conflicting stakeholders gave me unexpected product strategy experience. What I'd repeat without hesitation: involving the Customer Success Engineer early. It prevented months of rework. Research resolved the Engineering-Product disagreement through objective evidence rather than debate — and gave leadership the confidence to make a significant engineering investment.