IBM Monitor Dashboard Design

Designing data-driven dashboards, alerts and analytics

IBM Maximo Asset Monitor is a web-based, enterprise application for maintenance and operation professionals. Monitor uses configurable dashboards to aggregate asset data and AI-powered alerts to detect anomalies (for example a broken pipe or a temperature overage). Users can leverage these insights to optimize their operational proccesses and minimize work orders.

My Role:
Product designer (specialty in Visual and UI Design)

As a visual designer on the Monitor team, my work focused on designing and standardizing new UI features/components and ensuring compliance with the Carbon Design System.

Design team members:
Mats Gothe, design team lead and researcher
Cynthia Zhang, product designer (specialty in UX Design)
Luaithrenn Dempsey, content designer

What need is this product solving?

According to a 2016 report by analyst firm Aberdeen Research, unplanned downtime can cost a company as much as

$260,000 every hour

A small disruption of normal operational processes like a piece of broken machinery could translate to huge losses for a company. If problems arise, they need to be noticed as soon as possible and addressed quickly.

Keeping in mind that time is precious, how might we design dashboards that can:

Convey complex data at a glance
Highlight operational issues quickly
Make it easy to resolve issues

Key personas

Oscar, the Application Administrator
Oscar works in an IT Organization and is responsible for administering the IoT solutions used by his line of businesses. He is installing, configuring, and maintaining solutions like Maximo Asset Monitor for the operations team.

Bryan, the Operator
Bryan is in a remote operations control center in an asset-intensive industry. He works shifts and is assigned to monitor one or more sites with control systems up to 100,000 data points each.

Ed, the Maintenance Supervisor
Ed is the supervisor that schedules maintenance tasks based on maintenance schedules, anomalies, or predictions of failure.

A bit more about the design process

Our team frequently collaborated with product management and development teams throughout our work. We'd first work with stakeholders to understand user needs and goals, then plan designs for upcoming sprints and releases. As designers, we would brainstorm, iterate, and test design solutions while continuing to align with the larger team. Once designs went into development, we would be available to developers to address technical constraints and support implementation.

dashboard marked up to show different components

My goal: Breaking down complex screens

IBM's Carbon Design system had some fledging work in charts and data visualization to draw upon, but no formal guidance on dashboard patterns. Figuring out how arrange and visualize large amounts of data was no easy task. I knew that we needed to quickly impart critical information to users who might be engaged in time-sensitive jobs. In an effort to help users be quick, proactive, and efficient, dashboards were divided into different types of dashboard cards.

Each dashboard card would be based around a certain visualization--for example, a dashboard value card would have a large value or number as it's focus. Each card type would have it's own set of rules.

Inital brainstorm: Exploring visual designs and card sizes.

Maturing the dashboard design standards

After doing some iterating and determining the different types of cards, it was time to standardize the basic card design. All dashboard cards would have the same basic anatomy: Title, Subtitle (optional), Actions, and Card body.

Cards can have fluid widths and fixed heights. Five different size options (xsmall, small, medium, large, xlarge) are available based on the amount of page columns the card spans. This allowed for great variation in card design to best fit the needs of the data.

Examples of content that can appear in a value card.

Dashboard card interaction design

Although I've discussed a lot of visual work so far, Monitor dashboards are typically not meant to be static things. If there is an issue with an operational process, it needs to be easy to understand and resolve quickly.

We also designed and implemented card actions such as zoom and pan, hover and tooltip states, changing time ranges, and submitting service request. Check out the video below to see some of these interactions.