VMware Cloud - Service Integration

Outcome-focused workflows to unified the cloud product

Context
VMware has been known for is virtualization technology for over decade. In recent years, the company has undertaken a significant business transformation—from a perpetual license model to subscription-based model (SaaS). Over time, VMware have transitioned multiple products and service to the cloud to establish VMware as a multi-cloud infrastructure provider.
Duration
Jan 2023- Dec 2023
Team
Designer, PM, Software Engineer
Concept Analogy

With more than 400k customers, vSphere customers are central to any offering VMware build. Overtime, VMware have built multiple products around it, each serving a unique use case. As VMware transitions to a subscription-based model for product sales, the leadership devised a bundling strategy to simplify customer experience.

What does a bundling strategy mean? Basically, VMware combines selected services with vSphere and offers them as bundled packages. Depending on the particular bundle a user subscribes to, specific services are unlocked for consumption.
‍




If we draw an analogy of the foundation platform of VMware, vSphere, as the Big Mac at McDonald’s. For all the 2nd and 3rd party services, you can imagine it as coke, fries, coffee or donut. The subscription model is akin to offering complete meal bundles rather than letting customers to select individual food items. By providing services bundled together, customers receive a more comprehensive experience, extracting greater value from vSphere and augmenting their cloud capabilities.

Emerging Problem

Looking at the current integrated service page, Besides the visual problems like service cards are not aligned, all the services are sharing the same service pool no matter the activation status. After the subscription model is introduced, more complexity will be added. And my mission is to renovate the experience to align with the emerging requirements stemming from the subscription model.

Challenge
When analyzing the end-to-end user flow from learning, exploring to purchasing and consuming, I soon discovered that the biggest challenge for me as well as our user, is that there are two distinct personas with varied requirements when working on the services.

Normally, the person who purchased the services and subscription (Cloud Architect) and the person who consume the service (Cloud Admin) are not the same person.
‍
And the problem we need to solve is now distilled and diverged to:
Solution for
Cloud Admin
To expedite service consumption, I initially considered dividing the services into two categories: "Activated" services and those "Available for Activation." This would ensure that the services ready for immediate use are the most prominently displayed for users. Furthermore, I included a side filter for categorizing services based on whether they are included in a subscription, and an outcome-based categorization to help make selection with focus.

I quickly made the prototypes and conducted unmoderated usability testing. 8 results were received in just one week. To my surprise, all users easily identified and comprehended the tab used to separate service statuses, validating the success of this approach in clarifying service status.
After I reviewed the design with leadership as well as the PM team. Two valid points they raised made me re-evaluate the necessity of the side filter.
‍
1. We only have around 10 services currently, which may not justify the development effort required for adding outcome-based categorization.
2. The “Type” filter might risk burying some of the additional purchase options, and we don’t want impede any potential purchase or constraining users' cloud capabilities.

After iterating on the feedback, a more organized structure for categorizing services is in place. This structure enables users to effortlessly access both bundled services and a-la-carte service purchases, ensuring a more versatile experience.
‍

Solution for
Cloud Architect
Now, let's consider the role of the Cloud Architect, whose primary responsibility lies in the management of subscription and services throughout the organization, as opposed to directly using these services. They require a holistic, organizational-level perspective on the integrated services. As the integrated services are currently accessible only through specific deployments, after the discussion with PM team, we decided to create a dedicated page that serves as a centralized hub for all these services.

Being the initial point of focus, the content showcased on the service card should be cater to the Cloud Architect. So instead of detailed service descriptions, we now provide concise service overviews. Additionally, a 'Manage Service' option is introduced, empowering the Cloud Architect with the ability to perform bulk management tasks.
‍
Since a service that is activated on one deployment doesn’t mean it is activated on all others, the services on the org view is categorized as “My services” which means they’re included in subscription or activated somewhere, and “More services” which display other possibilities to enhance the cloud.

Considering that Cloud Architect would make the activation decision for the entire organization, we replaced the current one-click activation with a comprehensive onboarding process. Within this process, a bulk selection feature is seamlessly integrated, which empowers the Cloud Architect to activate a specific service either for the entire organization or selected deployments
‍
UI Refinement
Aside from the larger story, let’s spotlight some design refinements I made to improve the overall product usability.
‍
#1 Service Card
Service card is set to a unified size to ensure a consistent look, all the overflow content will be wrapped and users can access the full description of each service through the Learn More button. The "Active" pill is removed to avoid redundant information display as we have the tab to indicate the activation status.
‍#2 Stepper
The activation flow was originally designed using a stepper component, a common element used across VMware products for multi-step processes. However, we found that this approach didn't make the most efficient use of vertical space. The stepper tended to become overly elongated, especially when the content within it was extensive. Additionally, it wasn't an ideal solution for nesting a table within another table-like component. As a result, we took a fresh approach and redesigned the activation flow, opting for a side menu to address these concerns.
‍
Takeaways

01. Embrace the everchanging requirements. I have wondered that why our priorities are always changing. One day our focus is on the launchpad, the next day it shifts to services, and next week it shifts to Org view. This shifting landscape can be a bit challenging to keep up with. However, over time, I've come to understand that in the realm of live and active products, change is the only constant. I've learned to embrace this ever-evolving nature and adapt to it effectively.

02. Analogy is a powerful tool when learning the domain knowledge. When the subscription model was initially introduced, I found it somewhat challenging to fully grasp its implications. It was the fast food analogy that my design leader shared that truly made a difference. This analogy equipped me with the clarity and confidence I needed for effective design.