Redesigning the IBM Storage Ceph Dashboard

Overview

IBM Storage Ceph's dashboard exposed a lot of technical information, but it didn't always help administrators understand what needed attention. New users struggled to interpret the system's health, while experienced administrators often turned to CLI tools and external monitoring dashboards to get the detail they needed.

Custom grafana dashboard built by admin to monitor ceph cluster.

I led the UX redesign to bring health, capacity, and performance into a clearer, more cohesive monitoring experience - one that could serve both new and experienced administrators without compromising the depth of a complex storage platform.

Problem

IBM Storage Ceph Console - Overview dashboard (Before)

The dashboard showed the data, but not always what mattered.

Storage administrators rely on the dashboard to understand the state of their cluster, spot potential problems, and monitor resource consumption. But the existing experience made it difficult to turn technical information into a clear picture of system health.

New administrators encountered dense metrics and unfamiliar terminology without enough context to understand what required attention. Experienced administrators needed more comprehensive monitoring information and often switched between the dashboard, CLI tools, and custom Grafana or Prometheus setups.

This created two problems:

01

For new users

Understanding the cluster required more technical knowledge than the dashboard should demand.

02

For experienced users

Getting a complete view of the system often meant leaving the dashboard and piecing information together from different tools.

The opportunity wasn't simply to make the dashboard cleaner. It was to make the information easier to interpret, prioritize, and act on.

Why the existing experience fell short

01

Too much technical information, not enough context

The dashboard exposed detailed cluster information, but users still had to interpret what the numbers and statuses meant for the overall health of their storage environment.

02

Health information was difficult to piece together

Warnings and incidents could originate from different parts of the system. Presenting them without a sufficiently clear distinction made it harder to understand the overall condition of the cluster and identify the issues that deserved attention first.

03

Monitoring was fragmented

Administrators who needed a more complete view of performance and resource consumption often relied on CLI commands or external monitoring tools. The dashboard wasn't consistently serving as their starting point for understanding the system.

Design opportunity

The solution couldn't simply be a visual refresh or a direct UI wrapper around existing technical information. The dashboard needed to help administrators answer three questions quickly:

01

Is my cluster healthy?

Understand its current state and identify issues that need attention.

02

Am I using my resources effectively?

Understand consumption, capacity trends, and potential constraints.

03

Where should I look next?

Move from a high-level overview to relevant service and component details.

I used these questions to guide the dashboard's information hierarchy and interaction model.

Research and discovery

Understanding the gaps in the existing experience

I used a mixed-methods research approach combining quantitative community data (Ceph community engagement surveys) with qualitative stakeholder studies — 6 stakeholder interviews conducted across roles like IBM tech support engineers, forum moderators, and field specialists; the people who step in during high-severity system outages.

These inputs helped me examine the problem from different perspectives: how users interpreted the interface, where they needed more visibility, and which technical constraints would shape the redesign.

Rather than treating every requested feature as an independent problem, I looked for recurring issues in how the dashboard presented information.

3 insights shaped the redesign

01

Status alone wasn't enough

Administrators needed more than a collection of health indicators. They needed to understand the difference between a general alert and a health incident, and where to investigate when something was wrong.

02

Raw capacity figures didn't tell the whole story

Current usage was useful, but administrators also needed a better understanding of consumption trends, available capacity, and how their storage resources were being used.

03

Different users needed different levels of detail

A newcomer needed an understandable overview without being overwhelmed by technical information. An experienced administrator needed access to detailed metrics and component-level information without losing the bigger picture.

These insights led to a common design direction: make the overview easier to understand, keep related information together, and provide access to deeper detail when it was needed.

Design direction

One dashboard, three clear priorities

I organized the redesign around three priorities.

01

Make system health easier to interpret

Establish a clearer hierarchy between overall cluster health, alerts, incidents, and component status.

02

Make resource usage easier to understand

Bring storage consumption, trends, capacity projections, and performance metrics into a more coherent overview.

03

Make complexity easier to navigate

Use progressive disclosure and consistent interaction patterns to help users move from a summary to the details relevant to their task.

Alongside these priorities, I aligned the redesigned interface with IBM's Carbon Design System. This helped establish consistency with the wider IBM product ecosystem while providing a foundation for reusable patterns.

Carbon wasn't the goal in itself. The goal was to use a consistent design language to make a technically complex experience more predictable and easier to navigate.

Design Ideation

Collaborative strategy

Before sketching solutions, I gathered Product Management, Engineering, and Support teams for a alignment workshop. This anchored the team around core user needs before anyone proposed technical fixes. We structured our design direction using the Whys and Hows Framework to map user realities directly to product execution.

Heuristic evaluation & portfolio benchmarking

I conducted a comprehensive heuristic audit of the legacy product. Because the interface had been built organically by engineering teams, this audit served a dual purpose: it exposed critical UX gaps and created a technical blueprint for the IBM Carbon Design System migration.

To ensure consistency across the enterprise, we benchmarked our layouts against established, high-performing storage dashboards within the IBM portfolio, adopting proven UX patterns for the Storage Administrator persona.

Design decisions

01. From scattered status signals to a clearer picture of health

Challenge

Overlapping warnings and alerts obscured overall cluster health, making it hard to prioritize issues. Labeling Placement-groups as healthy or warning confused new users and didn’t satisfy advanced admins, who wanted broader categories for a clearer overview before details.

Design decision

Separated cluster health incidents from system alerts into a dedicated side panel. Refactored PGs information into Data resiliency to communicate data health which further categorizes placement-group states for a high-level summary.

Why this approach

Establishes a clear hierarchy so users answer "Is something wrong?" before diving into "What needs investigation?"

02. From raw storage figures to capacity awareness

Challenge

A usage figure tells administrators how much storage is consumed at a particular moment, but it doesn't explain how consumption is changing or when capacity could become a concern. The capacity card lacks actionable insights. Users can see capacity but may not know what actions to take, potentially leading to mismanagement or delays in addressing issues.

Design decision

Consolidated consumption, trends, savings, and estimates while organizing metrics by Block, File, and Object services.

Why this approach

Combines current usage with future direction so admins can forecast capacity without navigating multiple views.

03. From fragmented monitoring to a more complete overview

Challenge

Experienced administrators needed visibility into the performance of their storage services and the state of individual cluster components. The existing experience often pushed them toward CLI tools or external dashboards to gather the information they needed.

Design decision

I organized the overview to bring together the most useful monitoring signals while retaining access to more detailed information. I used information hierarchy to distinguish the overall state of the cluster from service-level performance and component details.

Why this approach

The dashboard needed to be useful as a starting point for routine monitoring without pretending to replace every specialized troubleshooting tool. A clearer overview helps administrators understand the system before deciding where to investigate further. Detailed metrics remain available for users who need them, without overwhelming everyone else.

04. From inconsistent interactions to a cohesive IBM experience

Challenge

Inconsistent UI patterns diverged from IBM standards and failed to support complex administrator workflows.

Design decision

I aligned the dashboard's visual language and interaction patterns with IBM Carbon, using consistent components, spacing, typography, and interaction conventions.

Why this approach

Standardizing components reduces cognitive load, makes interactions predictable, and scales cleanly for future features.

Solution

Bringing the experience together

The redesigned dashboard brings the three main monitoring questions into a more coherent experience:

Health: Understand the state of the cluster and identify issues that need attention.

Capacity: Understand current storage consumption, trends, and potential constraints.

Performance: Monitor service-level metrics and component status without having to assemble the entire picture from disconnected views.

The dashboard also includes upgrade notifications and clearer component and hardware status information, helping administrators monitor their environment from a more consistent starting point.

The intent was not to eliminate technical complexity. It was to organize that complexity so users could understand the overall system first and investigate further when necessary.

Outcome

User Validation & Impact

We validated the redesigned dashboard live at the Ceph Days India Event (March 2026), collecting direct feedback from active enterprise clients and community users.

I used informal, guerrilla-style testing to understand their reactions to the proposed dashboard and how they interpreted the redesigned experience. I treated the feedback as directional input to help assess the design and identify areas that might need further consideration.

01

Novice & intermediate response

Users reported a massive drop in friction. They discovered features easily and no longer felt intimidated by technical Ceph jargon.

02

Expert response

While veteran administrators noted they would still rely on the CLI for complex scripting, they highly praised the new dashboard for high-level monitoring, noting it was efficient enough to significantly reduce their reliance on custom external Grafana builds.

03

Enterprise visual cohesion

Migrating from Red Hat PatternFly components to the IBM Carbon Design System brought visual and interactive alignment across the product line. New IBM customers can now onboard into an experience that feels like a trustworthy, cohesive part of the broader enterprise storage portfolio.

The key shift: from a dashboard that exposed technical information to one designed to help administrators interpret the system and decide where to look next.

What I took away

Designing for infrastructure products isn't about hiding complexity. It's about making complexity understandable without removing the depth that experienced users depend on.

The most consequential decisions weren't about adding more information. They were about deciding what deserved attention first, how related signals should be grouped, and how users could move from an overview to the detail needed to investigate a problem.

That became the central principle behind the redesign: make the system easier to understand before asking users to manage it.