top of page
alert_app_bg.jpg

Controlling the Chaos- Alert Management App

Mobile, AIOps, B2B, Alert Management
One Sentence Job Story

When the NOC operator is not at his/her desk and can not access their laptop/desktop, they want to review and attend to alerts so they can be noticed of new alerts and be able to troubleshoot ASAP.

User Research
In order to define the target user and understand their needs so that the product is developed to create real customer value, qualitative user research was conducted involving both internal team members like sales engineers and external clients.
User Persona
 
  • Nate NOC, the NOC Operator (Target User) – Those on the front line in IT Operations environments. They respond to issues and work to quickly remediate which may involve engaging others.
​
  • Tim Tools, the Tools Administrator – Those that deploy monitoring solutions, have access to subnets, can provision virtual machines, configure thresholds, and perform any other foundational tasks that ensures the success of the other personas. 
​
  • Sam SME, the IT Infrastructure Expert  / DevOps – They want visibility into their environment health, understand dependencies. They have a deep understanding of their environments and may assist or lead in resolving complex issues.
​
  • Melissa Manager, the Managers / Exec – They want to gain visibility about what is happening and understand trends and insights about their operations environment.
User Needs 
 
  • User wanted to be noticed of the urgent/critical alert first so that they could work on the alerts based on priority.
​
  • Users wanted to perform some quick actions even before they look into alert details. (e.g. acknowledging alert)
​
  • User wanted to have their customized item(e.g. customized view) consistent with desktop product so that they can easily find what they need.
​
  • User wanted to be able to create/edit incidents so that they could better manage alerts on mobile.
High Level Picture
Bundle project high level flow - New fra
From the company and business perspective, the product structure was shifting from one big sinlge platform that provides an end-to-end solution to Bundle-based solution to increase sales motion thus better meet the market needs.
 
So I created this high-level chart to organize my thoughts and deepen my understanding of the situation. This mobile alert management app falls into Bundle 2 (Event and Incident Management).
​
The goal of this mobile app is to provide users an effortless way of tracking alerts and start troubleshooting without having to access to their desktop/laptop. 
​
Key metrics are NPS, Number of Downloads, Customer Rating and Reviews.
Project Specific Flow Map
mind map1.jpg
mind map2.jpg
I drew the feature-based flow maps and use it to better define the scope in design and be aware of the limitations ahead of time.
Wireframe
Screen Shot 2020-03-12 at 9.27.19 AM.png
wireframe.jpg
UI Design (Selected Screens)
Slice 1.jpg
Slice 2.jpg
Slice 13.jpg
Slice 5.jpg
Slice 4.jpg
Slice 8.jpg
Slice 7.jpg
Slice 9.jpg
Slice 11.jpg
Slice 10.jpg
Slice 12.jpg
Some details

#1 - Is this all there is?

Group 790.jpg

As a designer, I always try to think through all the possible interactions so I don't miss any use case for the user. Also creating the action list guide can save efforts for engineer in development. So I created this table that shows all interactions under different alert statuses and actions taken. I also include notes to explain the reasons behind it or things that need to be aware of. So that engineers have no ambiguity in developing it.

#2 - Visual exploration on Impacted Services Card design

Slice 14.jpg

For Urgent alert only, there is a piece of information that plays an import role which is "Impacted Services". So I designed a special card for this type of alert only on the alert detail page. The key challenge was to achieve highlighting the impacted services, saving space and visually appealing.

#3 - Dark mode

Slice 15.jpg

#4 - Add/adjust components in design system to adapt mobile user case

design system.png
Learnings
  • Define the problem/user needs first, everything else is secondary. When I did the user research, I found an interesting situation where the sales engineer/customer always briefly talked about the problem or even skip this part, directly jumped to recommend what needs to be changed in design. Often times, I found this process doesn't help anyone because giving solutions too quickly without defining the problem thoroughly beforehand could 1) Limits people's minds when the problem is valid; 2) In the worst scenario, it misleads the direction when the problem is not understood correctly. So what I did was avoid diving too deep on the proposed solution, and instead, ask questions around the problem to take a step back. This defining-the-problem-first approach always works and benefits for all parties involved.

​

  • Priority, priority, priority. One of the challenges in designing this mobile product is deciding what feature/info is the priority since the desktop version is so complicated and contains so many features here and there. Take designing the action sheet for the incident for example, in the desktop screen, there are 5 primary actions and 10+ secondary actions and due to legacy issues, some actions are broken or make less sense. So I took a lot of time talking to sales engineers and PM to figure out the key actions in priority order. And use this priority order to design the primary actions and fold or the other less important actions in an editing button.

bottom of page