Alerts Queue

The alerts queue was a feature I worked on as part of GE’s Asset Performance Management team. This feature was one of the very first that we built in the APM product, so I was designing very nearly from scratch, which presented a lot of opportunities.

The Challenge

My task was to create an interface for the management and processing of alerts. These alerts were indicators of potential issues with industrial equipment, and were generated by analytics based on data from those assets. The users whose job it was to process these alerts needed to be able to triage them, see time series and asset data, make notes, and then close each alert, or pass it on to a specialist.

Research

The first step in the design process was to research the role for which I was designing. In this case, my team was able to visit the monitoring and diagnostic (M&D) center of our primary customer. While there, I shadowed several users as they walked me through their day-to-day workflows, and conducted user interviews to learn more about their use cases and pain points.

After the visit, the information I collected was combined with that of other designers to produce a set of personas and a comprehensive journey map of the M&D process. These artifacts would be referenced often by me and other designers when working on features for our product over the next several years.

MD Center.jpg

During my research, I focused primarily on the “Analyst” persona, as they were the ones tasked with managing and processing alerts. A few key things I learned about their role were:

  • Analysts generally triage alerts by looking for the most recent or most severe alert in their queue.

  • Alerts must be processed within 20 - 40 minutes. Trips (mechanical failures) must be processed even faster.

  • Analysts go back and forth between several different tools.

Workflow.png

After the site visit was over, I made sure to stay in contact with the users I met. Having access to these users to quickly test hypotheses or clarify use cases would prove invaluable over the course the project.

Initial Design

Based on the research I had done, I set out to create a set of screens that would enable the workflow of the Analyst persona. Due to the Analysts’ need to move quickly from one alert to the next, I opted to create an inbox style screen, similar to an email application.

This would allow the analysts to quickly see what alerts were in their queue, and select one to work on. Sorting options could be accessed at the top of the list. Alert details were shown on the right, and analysts could open attached analysis views in new tabs. Functionality for categorizing the alert and creating a case were available on the same screen, which meant analysts could quickly process an alert and move on to the next one.

Inbox.png

I also designed functionality for filtering alerts in the queue. Analysts could build and save their own filters, allowing them to customize their view. This would be useful for users who only dealt with certain types of issues, or were only responsible for certain customers or sites.

Filters.png

During the design process, I was often in contact with the users from the M&D center. They were able to give me feedback on the design direction, and ensure were addressing their needs.

When the design was in a good place, and prototypes had been vetted by users, I created a set of detailed specs and supported our development teams during the implementation.

User Feedback

After an extensive design process, and the implementation of many different functionalities, including the alerts queue, our users finally got their hands on functional software. Of course, thanks to our continuous development process, this wasn’t the end of the road. We still had a significant backlog of feature requests and enhancements, and I was eager to learn what improvements could be made to our user experience.

So, after our users had had some time to learn the ins and outs of the software, I was happy to receive some feedback. Each user had different suggestions, but there were a few themes that emerged as I spoke with them. Our users wanted to:

  • See more alerts on screen.

  • See more info about each alert. (Before clicking into it.)

  • Have better tools for finding past alerts.

  • See charts at full width. (This wasn’t directly applicable to the Alerts workflow at the time, but we were considering adding charts to the Alert Details view, so it was something we wanted to keep in mind.)

With these items in mind, I set out to make some revisions to the Alerts UX.

Revised Design

Based on the feedback I had received from our users, I concluded that the inbox layout was not optimal for the use cases we were trying to enable. Instead, I pivoted to a list and detail pattern, where one page would display a list of alerts, and a separate page would display an individual alert when the user drills in.

This approach had several advantages, and addressed all of the issues our users had brought up. It allowed for more alerts to be displayed at once. The table columns allowed for much more info about each alert to be shown, as opposed to what would fit in a small inbox tile. The table format also allowed for more intuitive interactions for sorting, filtering, and eventually searching.

Additionally, this list view was extremely scalable. As new alert metadata fields were added in the future, we could simply add columns to the table, and users could customize the table by selecting which columns they wanted to see.

Grid View.png

On the alerts details page, we also had the advantage of more screen real estate. Many of the features in our backlog would involve adding additional UI elements to this page, so the additional space was welcome. This also meant that when we eventually added charts, they would be able to utilize the full width of the screen, something our users were very vocal about.

Details.png

Of course, even after these changes were implemented, the alerts functionality and design continued to evolve. But it was at this point, that I had arrived at a core layout and workflow that our users were happy with, and that was flexible and robust enough to handle the features that would be coming down the pipeline.