Red Hat OpenShift
Cluster Update UX

IMPACT AT A GLANCE

NOT BORED YET? LET'S DIG DEEPER THEN :)

1CUSTOMER CONVENIENCE VS. RED HAT EFFORTS

Offering users separate control plane and worker node updates can address maintenance time challenges, but it necessitates additional safeguards from Red Hat to ensure successful updates and prevent cluster failures. It's a balance between customer convenience and our efforts to deliver a seamless and efficient service.

To tackle this, I proposed a notification system allowing users to opt in for updates, ensuring they complete them and avoid critical failures. This system aims to enhance user accountability and provide proactive measures for a smoother and more secure update process.

2SIGNIFICANT TECHNICAL LEARNING CURVE

When I started working on cluster updates, I faced a steep learning curve with no prior knowledge. To overcome this, I dedicated extensive time to studying update documentation and relied on my product manager and engineering colleagues for valuable insights. While UX primarily focuses on improving user experiences, it's crucial to have a strong understanding of the product foundation and the underlying decision-making process.

3THE LACK OF DIRECT USER FEEDBACK

Direct feedback from actual users was difficult to obtain beyond initial feedback from the VoC department due to security and corporate red tape. As a result, the design was validated through multiple internal tests with SREs, whose responsibilities closely resemble those of the targeted personas. Since the user tests were mainly focused on technical knowledge, it is possible that there were biases as the participants were Red Hat employees. More details on this will be discussed in the user testing section.

PART 1: UPDATE STRATEGIES | FULL & PARTIAL CLUSTER UPDATES

1UNDERSTAND THE CLI WORKFLOW

To ensure a consistent user experience across both the web UI and CLI, I conducted research on how users typically their clusters using the CLI based on existing documentation. While it's true that there are numerous sub-steps involved in ensuring a successful update, this simplified version provided me with a clear understanding of the update workflow on the CLI, which enabled me to develop a workable workflow on the web UI.

Click on image to enlarge

2DEVELOP WEB UI WORKFLOW

In collaboration with a back-end engineer and a PM, I defined various use cases for update strategies and created workflows for each of them. I particularly enjoy creating workflows as they provide a bird's-eye view that allows me to understand various use cases. Moreover, my workflow designs are helpful for collaborating with other designers and developers.

Click on image to enlarge

3HI-FI DESIGNS

USE CASE 1: When everything looks good to update

Full cluster update

Partial cluster update

Click on image to enlarge

USE CASE 2: There are paused worker nodes, but users can still update

Click on image to enlarge

USE CASE 3: There are paused worker nodes, but users cannot update until paused worker nodes are resumed and done updating

Click on image to enlarge

PART 2: IMPLEMENTING CONDITIONAL UPDATES

1WHAT IS A CONDITIONAL UPDATE?

Once again, providing users with more flexibility in choosing updates that suit their needs requires additional guardrails from Red Hat. We strive to strike a balance between user autonomy and ensuring the necessary safeguards are in place to maintain the stability and security of the system.

2CONDTIONAL UPDATE AND UPGRADEABLE=FALSE

The upgradeable=false issue can hinder users from updating to specific minor versions due to a previously addressed bug associated with conditional updates. To effectively tackle this, understanding the relevant use cases through documentation or collaborating with peers is crucial. Let's shift our attention from technical terms to the user interactions necessary to proceed when encountering these use cases.

3DESIGN

WORKFLOW

I will never stop talking about how much I love creating workflows.

(Click image to enlarge)

USE CASES

PART 3: ESTABLISHING A NOTIFICATION SYSTEM

Notifications are important during cluster update to keep users informed about the progress and any issues that may arise. This helps users to take necessary actions and avoid any potential problems.

I created a notification system for cluster updates with input from PM and internal SREs. It includes severity levels and actionable CTAs while avoiding intrusiveness, using PatternFly components.

RESULTS

As of Q2 2023, the support tickets about long maintenance time during cluster update has decreased by 63% (target was 50%).

87% of click-through-rate to resume partial updates on notification and emails. This ensures less cluster failure.

As of Q1 2023, there have been very few support tickets related to conditional updates according to Red Hat VoC. It's also possible that users are opting to either select a different update version or wait for the next release..