vSphere Configuration Profiles
Making large-scale configuration management effortless.
.png)
Overview
vSphere Configuration Profiles (VCP) is a cluster-level configuration management tool that enables VI admins to define and apply a consistent configuration across all hosts in a cluster. It provides built-in compliance checks to detect and fix configuration drift—all within the vSphere Client. This ensures a more reliable, scalable, and error-resistant setup process for the VI admins. Read more about it here.
Role
Lead Product Designer:
User Research, Interaction, Visual design, Prototyping & Testing
Timeline
January 2025 - July 2025
What is a desired state configuration?
VCP's desired state configuration includes general, storage, networking, security, and solutions settings. It is captured in a JSON configuration document.
The JSON document has the following schema:
-
Host-override: This optional section contains a list of hosts identified by their BIOS UUIDs and settings applicable to those hosts.
-
Profile: This section contains settings that apply to all hosts in a cluster.
-
Host-Specific: This is an optional section that contains settings that must be configured per host. For example: static network configuration, hostname, and so on.
Analyzing Workflow Complexity and Functional Scope
VCP is a technically complex system that allows users to manage configurations in several ways: by importing a JSON file, using a reference host, or creating a new configuration from scratch. The system supports both Day 0 (initial setup) and Day 2 (ongoing maintenance) workflows, enabling users to import or update a desired state and detect any drift between the desired state and actual host configurations. To deeply understand the workflows and technical constraints, I participated in hands-on labs and collaborated closely with engineers and stakeholders to map out the existing system behavior.
Where Users Struggled
Based on feedback from PMs and user session recordings, we uncovered several core issues:
1. Confusing Schema Structure
-
Users’ mental model expected the UI to mirror the JSON schema, with separate sections for profile settings, overrides, and host-specific values. Instead, all appeared under one “settings” section, making it hard to navigate and understand configuration relationships.
2. Host-Specific Settings — Hard to Find and Manage
-
Buried deep within configurations, unlike the clearly separated JSON structure, breaking the user’s mental model.
-
Manual entry required for up to 96 hosts after importing from a reference host, making the process slow and error-prone.
-
No support for bulk CSV import or quick extraction of host-specific settings, whereas many users maintain this data in CSV format.
3. Override-Related Challenges
-
When enabling VCP, the system automatically created overrides for existing host settings, preventing the new desired state from taking effect—which doesn’t align with what users expect the system to do.
-
Overrides had to be deleted one by one per host, making management repetitive and time-consuming.
-
No option to carry forward specific overrides (e.g., keeping the firewall disabled for certain hosts) during Day 2 updates, limiting user flexibility.
Brainstorming and Initial Design
I set up bi-weekly meetings with the triad to brainstorm and explore design solutions that addressed user pain points while aligning with business goals and technical constraints.
Our initial design focused on giving users more control—letting them choose whether to create overrides from existing host settings when enabling VCP (Day 0), and whether to carry over existing overrides when applying a new desired state during Day 2 operations.
During design reviews, two main concerns emerged:
-
Risk of breaking the environment: The IT Architect worried that letting users enable VCP with any desired state could compromise stability. We agreed to delay this option until further research with large-scale customers was done.
-
Ambiguity around “overrides”: The term had different meanings in each context—
-
Day 0: Automatically preserved host settings, even when a new desired state was applied.
-
Day 2: Intentional, user-created exceptions users might want to retain.
Using the same label for both created confusion about what exactly would be preserved and when.
-
Bringing It All Together & Sign-Off
After surfacing these concerns, the team aligned on a few key realities: this was a short, fast release, and we needed more time to deeply understand how users approach desired state workflows—especially during Day 0 setup. This raised an important question: what improvements can we introduce now that won’t conflict with future changes, but will remain valuable and complementary regardless of how the workflows evolve?
From user recordings, we saw recurring friction in managing overrides and host-specific settings—pain points that would persist even as workflows evolved. In this second design phase, I focused on delivering improvements that added clarity and scalability while maintaining consistency with the Clarity Design System, ensuring accessibility and alignment with established product patterns.
As part of my process, I led end-to-end design ownership for this release—driving communication across teams, facilitating design reviews, and ensuring alignment before final sign-off. I reviewed the designs with the IX copy team and the Accessibility team, incorporated their feedback, and then presented the final solutions to the triad (PM, Dev, and Design leads) for sign-off, marking the designs as complete and ready for development.
Key improvements included:
-
Unified visibility: Surface overrides and host-specific settings more clearly in the UI, matching the separation users expect from JSON.
-
Bulk management: Enable create, update, and delete actions across multiple hosts at once.
-
CSV import: Support bulk upload of host-specific settings using existing CSV files.
-
Data extraction: Allow users to isolate and export host-specific settings directly from the UI.
Before: Overrides and host-specific settings were difficult to find and manage, requiring manual deletion per host and per setting.
New Design: Overrides and host-specific settings are surfaced, matching JSON document structure
New Design: Introduced CRUD actions in bulk, CSV import and data export for easier overrides and host-specific settings management.
Trade-Offs and Next Steps
Like most development projects, we faced a few trade-offs due to time and engineering constraints. I took the lead in evaluating the impact of each and prioritizing what would bring the most value in the current release while planning for long-term improvements:
-
Filtering complexity: Users needed advanced cross-filtering to easily narrow down large data sets. The Clarity design team had just released a new advanced filter component that fit our needs perfectly, but engineering bandwidth didn’t allow for full implementation. I proposed shipping a simplified single-column filter as an interim solution, ensuring users still had basic filtering capabilities. I documented the advanced version as UX debt and added it to the backlog for a future release.
-
Edit vs. Delete actions: With limited capacity, we couldn’t deliver both. I made the call to prioritize Delete, as it solved a critical pain point, while Edit was deferred since it already existed in the settings view. I tracked this as UX debt for the next release to maintain visibility.
-
Enablement flow (Day 0): Although this flow is crucial for adoption, the IT architect’s concerns required more research before redesigning. I marked this as top UX debt and first priority for the next cycle, ensuring it would be revisited with proper validation.
Next Steps:
-
Conduct user research on the enablement flow and explore improvements.
-
Validate designs through usability testing.
-
Collaborate with engineering to design and test the advanced filter experience.
-
Revisit the Edit functionality for inclusion in the next release.
Challenges and Learnings
This project presented several challenges: aligning perspectives across disciplines, managing design trade-offs under tight timelines, and balancing user needs with technical feasibility. One area of tension was the enablement flow, where design and engineering had different views on how much guidance users should receive versus how much control the system should retain. Usability data revealed a gap between the system’s data model and the user’s mental model, underscoring the need for a more intuitive, self-guided experience without compromising security or stability.
As the sole designer, I facilitated alignment across teams, led prioritization discussions, and made strategic decisions on which improvements to deliver immediately and which to defer as UX debt. This experience reinforced the importance of design leadership through influence—balancing user empathy, technical constraints, and business priorities while using data, user insights, and mental-model alignment to drive clarity and consensus in complex enterprise environments.