Through a research-centric process, I was able to design an experience for VM Service that gives Admins confidence and control over their resources, while empowering developers with autonomy and flexibility to self-service — ultimately providing both with the modern tools needed to build powerful applications in vSphere.
Feb 2020 - Aug 2020
Lead Designer - user research, end-to-end design process, aligning with business strategy, & implementation support.
Product Manager, Architect, Engineering Manager, UI Lead, & Product Designer (me).
VMware's biggest product, vSphere, lacked a self-service model, and our customers were moving to other cloud providers. To meet the modern market, we had to create a way for developers to self-service.
Developers care about building apps quickly, and IT Admins care about resource quotas and limits.
How do I design for both personas' success?
Developers have the freedom to self-service as much as they'd like to - within resource and size boundaries set up by the IT admin. Admins can now enable developer servicing in 3 steps, saving them time and money.
These VMware users will no longer have to look to external cloud providers for self-servicing functionality. VM Service is a premier product with enhanced functionality that provides a huge incentive for customers to upgrade their licenses, providing VMware with massive business value.
The Cloud landscape is growing rapidly, and users now have more options than ever before. To win new customers and avoid churn, VMware has to modernize its most well-known product: vSphere. A part of this move to modernization includes enabling developer self-servicing.
Companies that use vSphere aim to deliver apps quickly to increase their revenue and customer satisfaction. However, the app development process is significantly slower due to delays in VM provisioning. Moving to a new cloud provider is costly, and the company’s IT team is looking for better alternatives.
Admins will typically have a handful of different templates that cover major use cases for their developers. Once they get a ticket request, they start off with that base template and tweak certain configurations to save time.
🔑 With this knowledge, I knew we could build the VM Service to fit VI Admin's current mental models with "Golden Templates" translating to VM Classes in VM Service.
With the cloud landscape constantly advancing every day, consumers have a multitude of options to choose from when creating VMs. A notable force in developer self-servicing is Amazon Web Services Elastic Compute Cloud (EC2).
The process is streamlined even further through optimizations, such as a selection of a "memory-optimized" or "compute-optimized" VM, which then dictates later configuration settings.
🔑 To compete with the best of the public cloud offerings, we knew we had to make developer self-servicing as quick and easy as possible.
After creating a deep understanding of the problem space and user needs through research, I created an end-to-end user story. Below are a few key slides from the End to End Journey. This presentation proved to be a valuable resource for a shared vision as we socialized it with different stakeholders and teams through feature development. It then became a template for future feature-level story work on the design team.
I take an iterative and open approach to design, involving my quad team from the get-go and sharing high-level concepts, wireframes, and inviting them to share feedback as we move through the design process. I believe everyone shares ownership in the overall experience.
Our cross-functional group met on a weekly basis. During this time, the team gave me feedback on the feasibility of designs based on time and technical constraints.
This feature took 4 solid, distinct rounds of iteration. These iterations included different workflow entry points, experimentation with different object structures, and reflected the changing business priorities.
For descoped flows, I make sure to document these through the design phase on Figma and Confluence so they can be picked up and prioritized for the next release.
1. Quality > Quantity.
There were many advanced configuration options we could have added to the feature. Quick time to value and ease of use were prioritized in the experience, with all of the advanced configurations slated for later releases.
Configuration was limited to the most basic, fundamental options. Creating a VM in vSphere is traditionally a long, complex task that our users have just become used to, but I wanted this experience to showcase the quick and effective model we are working towards.
2. Quick-Start Options
For first-time users, knowing which classes their developers might need can seem like a daunting task. There is a set of 20 default VM Classes that encapsulate a variety of sizes and use cases that they can modify or delete.
The experience is designed to strike a fine balance between developer autonomy and admin control.
To give IT Admins fine-tuned control, VM Classes and Images live within virtual resource boundaries called Namespaces. Developers are added to Namespaces where they can then self-service VMs.
The Namespace already has a fixed limit of CPU, Memory, and Storage, and no matter how many VMs a developer creates, they cannot exceed the Namespace limit.
Now that developers could self-service VMs from their Command Line Interface, I needed to find a way to distinguish a developer-created VM from the rest of the VMs created by IT Admins.
Once the VM is selected, we now show a "developer managed" pill along with details on the VM class, image, and resource boundary the VM was created with (highlighted sections in image).
This allows IT Admins to closely monitor new VMs that pop up into their environment and understand the metrics around which VM templates are being utilized the most.
Once the design direction had been solidified, I met with users again to validate the flow and see if the solution fit their needs. The feature was met with lots of excitement. Suggestions for additional configuration features in VM Service matched our roadmap of what we were planning to deliver next.
Examples included:
I built strong relationships with my PM and my developer during this process through honest communication and vested interest from all of us throughout all parts of the project, regardless of our function. So my PM and developer shared a lot of great UX improvements during the design process, and during the development process, I worked very closely with my developer to close some small UX/UI improvements on screens that he was working on anyway. These small changes could make a big impact.
Developers were also involved in our weekly cross-functional syncs from the initiation of the project, so implementation was smooth. During this process, I helped the UI team refine details biweekly through UI reviews of screenshots and live environments. Items such as copy, spacing, and interaction details are refined during this stage. API discussions were also being held periodically during design reviews so that Backend and UI teams could identify and prioritize different flows that needed to be built.
As the Backend Engineering team works on the implementation of this feature, new error scenarios are discovered, beyond what we solved for in the mockups. As these come up, I work with the Backend team to create useful error handling that guide the user towards remediation.
I was invited to a PM planning meeting where there were fundamentally different ideas about the future direction of VM service. I requested time to research and bring back a data-backed UX suggestion.
VMware has now caught up to the modern cloud by offering self-servicing on its largest and most well-known product. We will maintain current customers and win new ones by providing cloud-like consumption experiences.
Customers save significant time and money as they don't have to completely overhaul their virtual infrastructure and transition from VMware to a new cloud provider. Development teams gain more autonomy, and IT Admins save time by automating repetitive tasks.
This project required careful consideration of all the needs we were fulfilling - the business (VMware), the customer (CTO/CIOs in companies), and our end-users (Developers & IT Admins). Our one solution needed to come together to cohesively for all.
Since VM Service was also the first service on vSphere, there was a lot to learn about our user’s expectations and the way they were solving these problems today. User insights were instrumental in helping our team make tough decisions. I included our team in some research sessions and shared quotes and video snippets of the sessions to help build a research-focused culture.