Enhancing Operator Visibility in Hybrid Cloud Console

Author: Ethan Kim | Last edit: July 08, 2024 | Design type: Alerting, Operators | Product area: Hybrid Cloud Console, OpenShift Cluster Manager, Managed Infrastructure
Overview
Goal, Effort, User Outcomes, Impact
UX Goal
Many managed infrastructure users make use of Operators and add-ons to compliment their workloads. However, we haven't conveyed this relationship to them well. We’d like to create a better communication plan to increase awareness of what operator capabilities are available in Hybrid Cloud Console.

Effort
We’d like to expose a few strategically selected Operators at the most effective areas, including the cluster detail page, the OCM Overview page, and the search results allowing external sites, making it easier for users to get started with Operators after creating a managed cluster.

Impact
Operators are one of the main ways to add values by easing the operational complexity. Customers who don’t know what Operators are available or why they should use a particular one can now be better informed.

Design Details
Understanding Problems
Looking at a few statistics including Amplitude and Let’s Do the Numbers, we realized that many managed infra users utilize Operators. It is hard to find any OpenShift customer who doesn’t use Operators on their clusters. Most Operators, other than a few default (automatically deployed) Operators, such as Deployment Validation Operator and Observability Operator, need to be manually installed by users.

However, although we have a few external links for specific Operators on the OCM Overview page, the click-through rates are pretty low - the hotter the feature (closer to red), the more it is used by users. We also noticed a usability issue on this page. Many users click on the white stripes to access the “Recommended Content,” instead of clicking on “Learn more.”

Also on the Overview detail page, we don’t have much traffic other than on the intentional CTAs above the fold.

The search inputs for the last 7 months were also reviewed. There are inquiries made on Operators, Operator Hub, and related keywords (service mesh, virtualization, etc.). However, we don’t provide any desirable results - they all result in dead-ends saying “No results found,” because we intentionally don’t surface external links at all in Hybrid Cloud Console.



Some of the search results provide the wrong destinations.

Many field folks agreed on this - the current experiences are not so favorable. Basically not so totally broken but not ideal.

Understanding Personas
The users who create managed clusters are administrators like Adi and Henry. It would be nice if they know about necessary Operators at the moment of creating a cluster because they can install them right after cluster creation. However, this flow is not embedded in the current experience.

Defining Goals
We set up 3 phased goals and we’d like to increase the visibility (awareness) of Operators at the point of creating a managed cluster as the first.

Defining Scope
There are about 500 operators for OpenShift 4.16. For this effort, we wanted to surface 5 Operators as a test drive, based on usage data and strategic priorities.
- Advanced Cluster Security for Kubernetes
- Red Hat OpenShift AI
- Red Hat OpenShift GitOps
- Red Hat OpenShift Pipelines
- Red Hat OpenShift Service Mesh
Exploring Experiences
We started the design explorations by asking a few basic questions. The first one was why we don’t allow external sites on the search results in Hybrid Cloud Console.

We also looked into the Hybrid Cloud Console navigation due to the high usage by users.

Two approaches were examined within the navigation:
- Adding a section dedicated to Operators
- Distributing Operators to individual sections as we do it for Advanced Cluster Security and OpenShift AI

We also explored a way we use “specific titles” on the “Learning Resources,” as the current page is too generic to trigger user engagement.

Learning User Behaviors
From Hotjar, another analytic tool, we realized many users are spending so much time in the wizard. Especially at the end.

Users stick around the cluster detail page, where is the end of the cluster creation process.

Short-Term Proposals
We wanted to determine what solutions would be suitable for immediacy and effectiveness.
- What can we do right away without dealing with many obstacles?
- What would be the most effective way to increase visibility?
Three design ideas were proposed based.
1. An alert component
When a user clicks on the “Create cluster” button, they land on the cluster detail page. At the top, we will clearly indicate:
- It will take time to create a cluster.
- Users can go anywhere else in the meantime.
- Here are a few Operators that they want to check out because they can help their operations.

This page is the perfect timing for users to learn about Operators. Because that’s actually one of the next steps users will do after creating a cluster (as a part of the Day 2 operations).

The good thing about this experience is that, in order to check on the cluster creation status, users will have to come to this page over and over. It means it has lots of potential that users would check out this component.

2. "Cardified" Overview Page
From the Hotjar analytics, we realized many people are visiting the OCM Overview page to create a cluster. A simple cardified approach is worth being explored. In this way, we can have better indication as well as easy maintenance.

On the customer side, it is convenient to see the contents rather than understanding the visual differences. Of course, they are going to experience less usability issues.

3. Search results with external sites
When do users use search? When they get stuck while browsing or they just know what they are looking for. We need to provide a way to satisfy those use cases, especially the second one. For example, when users search for “cicd,” we should display “gitops” or “pipelines” instead of “No results found.” Yes, let’s allow external links.

Measuring the Effort
Design Validation
We dedicated some time for design validation with field folks. Lots of positive feedback was received. We also picked up some concerns and we are going to address them to the final design or future iterations.

Success metrics
How are we going to measure success? Quantitatively, we could measure how many users actually use the components we are going to introduce. We are planning to set up usability tests to see how fast they get to know about Operators and measure if users perceive these components are helpful, as the field folks did.
The ultimate question is if this leads to the Operator installation increase. Maybe it is a more fair question for the second goal we started working on - easy installation.
