Increasing Config Sync adoption by 9% through strategic UX redesign
Overview
The Challenge - Google Cloud's Config Management struggled with a 2% conversion rate despite being a free, strategic feature for GKE customers. Users found the interface confusing and didn't understand the value proposition.
My Role - Lead UX Designer | Collaborated with Director of PM for Security & Config, Engineering Lead, UXR, and TPM | 6-month project
The Impact - Increased Config Sync conversion rate from 2% to 11%—a 9-point lift that transformed a strategic feature from underutilized to a driver of customer retention.
Context & Challenge
Business challenge
Config Management was designed as a strategic value-add feature for Google Kubernetes Engine (GKE) customers, included free with their standard license. Research demonstrated that when customers adopted these configuration management tools, they stayed with GKE services significantly longer—creating crucial product stickiness in a competitive cloud market.
However, despite its strategic importance and zero cost to users, the feature was failing to gain traction. The project was prioritized when I became available because leadership recognized that without intervention, their substantial investment in Config Management would deliver little to no ROI.
The problem
The Config Management section suffered from a critical conversion problem: only 2% of customers who visited the section actually adopted the tools. This abysmal rate existed despite the feature being completely free to use.
Through user research interviews, we uncovered the root cause: customers didn't understand what Config Management was or why they needed it. The term "Config Management" is ambiguous in the cloud space—it could refer to multiple different types of tools and workflows. When users landed on the page, the design failed to communicate the specific value proposition or guide them toward successful adoption.
The existing MVP design combined two separate features Config Sync and Policy Controller under one confusing umbrella, creating a muddled experience that left users unsure of what they were installing or why.
Initial Constraints & Considerations
This project came with significant organizational challenges:
01
No dedicated PM: I had no Product Manager to partner with during the critical UX discovery and definition phaseand direction
02
Resource limitations: I was the sole UX Designer supporting two separate feature teams, requiring careful time management around different release schedules
03
Conflicting stakeholder opinions: Engineering believed we should focus on command-line flows, while Product advocated for UI-first experiences
04
High leadership pressure: There was intense pressure from leadership to make these features valuable to customers quickly
05
Internal strategic disagreement: Teams had differing views on the overall Config Management strategy and direction
Success Criteria
Primary metrics
01
Increase Config Management installation rate from 6% baseline
02
Achieve steady, sustained usage of features over time
My Role & Approach
Leadership & Collaboration
As the Lead UX Designer, I took on expanded responsibilities beyond traditional UX design due to the absence of a dedicated PM. I effectively became the strategic orchestrator for the project.
Key stakeholders:
Director of PM for Security & Config
Engineering Lead Config Sync
UX Researcher
Technical Program Manager Policy Controller
How I structured the work:
Without a PM to drive alignment, I recognized early that getting buy-in would be critical to success. I proposed and facilitated a mini-workshop with the Director of PM to:
Discuss the product vision
Synthesize customer feedback and existing research
Align on Config Management's strengths and weaknesses
Define strategies for increasing customer adoption
I partnered closely with the UX Researcher to co-create a design vision that would serve as our north star and alignment tool across conflicting stakeholder perspectives.
Influencing across conflict:
Engineering and Product had fundamentally different views on the path forward—CLI vs. UI experiences. Rather than picking a side, I used customer research and prototype testing to create objective evidence that would help both groups align on what actually served users best. I walked Engineering leadership through the proposed experience, demonstrating how the UX improvements would benefit their users, ultimately securing their buy-in to decouple the backend systems.
Strategic Decisions
Decision 1: Separate the two Config Management tools
Options Considered:
Keep combined installation flow (status quo)
Create completely separate experiences
Rationale: Research showed customers were confused by the current combined flow—they didn't understand why installing security features required configuration steps, or vice versa. Separating them would make each feature more discoverable and understandable.
Trade-offs: This required significant backend decoupling work from Engineering, which was initially met with resistance. However, by demonstrating the UX superiority and walking leadership through the proposal, I secured commitment to the additional engineering investment.
Decision 3: Include Customer Success Engineering in design sessions
Rationale: Without a PM and relying on documentation to understand installation workflows, I recognized we were at a disadvantage. By including a CS Engineer who worked directly with customers and understood the technical complexities, we could design more realistic, implementable solutions.
Discovery & Research Phase
Research Methods
Given the lack of alignment between Product and Engineering stakeholders, I recognized we needed objective customer feedback to influence the path forward and break the impasse.
I proposed prototype testing to the UX Researcher, who agreed this was the right approach. I built a high-fidelity Axure prototype, and the researcher created a comprehensive study plan that combined:
User interviews to understand mental models and pain points
Task-based prototype testing to observe actual behavior and identify friction points
Participant criteria: 6-8 current or potential Config Sync users
Why this method: The dual approach would not only validate whether our proposed flow was easier to use, but also uncover specific areas for improvement through observation and conversation.
Key Insights
Insight 1: The term "Config Management" creates user confusion
Users didn't realize two distinct features existed under Config Management. The ambiguous labeling caused customers to miss features entirely or misunderstand what they were installing.
Design implication: We needed to restructure the information architecture to make each feature stand alone and be discoverable independently.
Design implication: We needed to restructure the information architecture to make each feature stand alone and be discoverable independently.
Insight 2: Zero-state designs showing feature value drive highest conversion
Leveraging research from another GKE team on dashboard effectiveness, we learned that showing users what they get when they enable a feature significantly outperformed other zero-state approaches.
Insight 3: Combined installation flows obscure feature purpose
Users didn't understand why installing a security feature required configuration steps, or vice versa. The combined flow created unnecessary cognitive load and decision fatigue.
Design implication: Decouple the installation flows to create clarity and allow each feature to communicate its unique value proposition.
Insight 4: Command-line installation creates a high barrier to experimentation
Customers who wanted to try the tool faced significant effort and technical expertise requirements. This prevented casual exploration and delayed value realization.
Design implication: Prioritize reducing friction through UI-based installation to enable faster experimentation and value discovery.
Insight 4: Command-line installation creates a high barrier to experimentation
Customers who wanted to try the tool faced significant effort and technical expertise requirements. This prevented casual exploration and delayed value realization.
Design implication: Prioritize reducing friction through UI-based installation to enable faster experimentation and value discovery.
How Insights Informed Direction
These insights validated our strategic hypothesis: customers needed to understand value quickly and adopt easily. We formed the hypothesis that by creating separate, clear feature paths with value-first messaging and simplified UI installation, we could dramatically improve conversion rates.
The research gave us the ammunition we needed to align Engineering and Product leadership around a unified vision.
Ideation & Design Exploration
Exploring Solutions
My design exploration focused on three interconnected problems:
Information Architecture: How do we make two features discoverable without confusing users?
Workflow simplification: How do we reduce installation complexity?
Value communication: How do we help users understand why they should care?
I collaborated with the UX Researcher to sketch multiple approaches, ultimately converging on a vision that we could prototype and test.
Key Design Decisions
Decision 1: Restructure Information Architecture — Create a Config Management section with two distinct features
The Decision: Separate the combined "Config Management" into two independently discoverable features within a new Config Management section.
Options Considered:
Keep the combined approach with better labeling
Create completely separate product areas
Build a Config Management hub with clear feature cards
Rationale: Research showed users didn't understand there were two features available. By giving each feature its own presence while grouping them in a logical section, we made both more findable for customers seeking configuration OR security capabilities.
Trade-offs: Required coordination across two feature teams to launch simultaneously, adding scheduling complexity. However, the UX benefits justified the coordination effort.
Decision 2: Consistent Day0 (Not installed) landing page
The Decision: Consistent not installed landing page for Config Sync and Policy Controller
Options Considered:
Cloud Design System empty-state pattern
Inert Dashboard that gives user a hint to what they get if they install the feature
Stronger value propositions
Rationale: Cloud Design system pattern conversion rate was sub optimal (2%). I thought of the "Inert" dashboard pattern which orients users better by showing the value of the features first.
Trade-offs: Breaking form the Cloud Design system use would require extra development time but I thought the extra effort was required to increase conversions.
Decision 3: Decouple installation flows despite combined backend
The Decision: Create separate installation experiences for each feature, even though the backend was shared.
Options Considered
Maintain combined installation (lower engineering effort)
Build separate frontends with combined backend (medium effort)
Fully decouple frontend and backend (highest effort)
Rationale: Users were confused by the combined flow. Separate flows eliminate this cognitive burden and allow each feature to stand on its own while increasing findability.
Trade-offs: This required Engineering to invest in backend decoupling, which was initially resisted. I built consensus by walking Engineering leadership through the UX proposal and demonstrating how the improved experience justified the technical investment. I did this by walking them throw the prototype that was created for testing and reviewing the research report.
Axure Prototype Build
We felt good were the designs landed. I began the prototype build out using Axure RP. I built a complete prototype that takes a user from Day0 (not installed) experience to Day2 (data in UI) Policy Controller.
I'm a proponent of testing using HTML + CSS as it produces a more realistic testing experience than Figma image clickthroughs. Axure also has logic and other efficiencies that really portray a realistic experience. I think this improves the quality of the feedback because users feel like they are using a live application.
View prototype (Access Code: n7RhiFDq)
Task Based Prototype Testing
Testing Approach
We conducted 6-8 prototype tests combining interviews and task-based scenarios. Users were asked to:
Install Policy Controller and Config Sync using the prototype
Understand what the feature offered
Complete installation flows
Explain their understanding of feature value
What we were trying to learn:
Did the value-first dashboard approach improve understanding?
Were the installation flow intuitive and completable?
What friction points remained?
What we learned
Positive findings:
The separated IA immediately clarified that two distinct features existed
Users consistently understood feature value from the dashboard zero stat
The simplified flow felt "much easier" and "more straightforward" than command-line approaches which would be good for learning to see how these features work
Surprises:
User said that the UI is helpful to get things started but command line would still be their choice for production environments because they have full control.
Validated assumptions:
Reducing installation complexity through UI flows enabled experimentation
Clear value propositions drove motivation to proceed with installation
Selling the Vision to Leadership
Now that we were finished with the vision and received positive findings from research we felt like we could start the discussion with leadership. Me and the UXR presented to leadership the designs and research findings. They decided that this was a strong approach and we moved forward with prioritizing the effort for the following year.
I have included the Final designs of the flow that were developed after the Vision was greenlighted.
Impact
Quantitative Results
Primary metric:
Increased Config Sync conversion rate from 2% to 11%—a 9-percentage-point lift
Timeline to impact: The conversion lift was observed within the first month after full rollout and sustained through subsequent months.
Exceeded success criteria: Not only did we increase installation rates, but we achieved steady, sustained usage growth, indicating that users who installed through the new flow were successfully activating and getting value from the features.
Qualitative Outcomes
User feedback:
Users described the new experience as "much clearer" and "way easier to get started"
Users were able to find Config Sync and Policy Controller in the IA
Business Value
Strategic impact:
Transformed a failing strategic feature into a driver of customer retention
Validated the investment in Config Management, demonstrating clear ROI
Created a replicable pattern for other GKE features struggling with adoption
Learnings & Reflections
What Worked Well
Operating without a PM forced strategic thinking: Taking on the workshop facilitation and vision creation pushed me to think more holistically about product strategy, not just execution. This experience strengthened my ability to operate at a senior/lead level.
Using research as an alignment tool: In the face of stakeholder disagreement, objective user feedback became the tiebreaker. Prototype testing gave us credible evidence to move forward decisively.
Building the right partnerships: Bringing the Customer Success Engineer into design sessions was a game-changer. It prevented costly mistakes and built Engineering buy-in early.