The Story
Zingbox was acquired by Palo Alto Networks in Sept, 2019
I joined Zingbox as a UX designer intern in 2018. When working for Zingbox and Palo Alto Networks , my job was around rebuilding IoT Guardian to deliver intuitive user experience with elegant user interface.
What is IoT Guardian?
IoT Guardian is an Internet of Things (IoT) security platform. It uses AI and machine learning technologies to help organizations discover, identify, secure, and optimize connected devices. It continuously monitors and learns real-time behaviors of their devices and protect them.
Time to Refresh Alerts Experience
Role
-
Security Engineer
-
IT Admin
Goal
Secure IoT devices, guarantee devices’ normal operations
Use Cases
-
Check out what alerts happen, what devices are impacted.
-
Look at alert details to learn more about what happens
-
Take actions to deal with alerts
-
Resolve alerts
What is Alerts?
As a core feature of IoT guardian, an alert will raise up if any abnormal behaviors happen to a device in the protected network. One of the security engineer's or IT admin's dalily routine is go to the Alerts page and check out if there's any alert need their attention, if yes, they will take further actions either at our platform or other workflow product they're using to deal with the issue.
Since we were under the transition from old UI to new UI, it was the time to redesign this page as a whole and provide better usabilities. I led this project and it was implemented after I left Palo Alto Networks.
Usability to be improved
Challenge 1 - How to simplify Alerts table?
The old Alerts table had a 2-level structure. It made interactions complicated here and decreased the efficiency of discovering alert information.
Parent row - Showing the alert name and alert summary
Child row - Showing impacted devices. Click on child row to enter alert detail page
Current table structure doesn't make sense
Which means users will only see one row / one device when they expand most of the alerts. If that's the case, why we keep users expanding and collapsing rows all the time?
70% of alerts only happen to one device in one day
Many of our users didn’t notice that the child row was clickable and they can get more alert information after clicking it.
‘Is there an Alert Detail page? I never saw it before!’
Reframe the problem - Design for discoverability
With these two user issues, the problem I need to solve here was not just simplifying the table structure, but also design for better discoverability. After brainstorm and ideation, I had 2 ideas.
Idea 1: Left-right structure
Pros:
-
No expanding and collapsing for single alert.
-
70% of cases are taken good care of.
Cons:
-
Impacted devices are still hidden if the alert happens to multiple.
-
The table structure is complicated, especially after expanding the row. Users are easy to get lost.
-
‘View details’ button is far away from users' attention.
Idea 2: Flat structure
Pros:
-
Simple structure, easy for scanning
-
Works well in 70% of cases
-
Get rid of expanding and collapsing.
Cons:
-
Hard to notice that an alert happens to multiple devices, but users can still locate it by sorting the table.
3. Design Decision - Flat Alerts Table
-
Alerts are sorted by detected time by default
-
View the snapshot of alert detail in a popover when hovering on the alert name.
-
Click alert name to get into Alert Detail Page.
Challenge 2 - Clean up table toolbar
With the new table structure ready, my next challenge was cleaning up the table toolbar.
Toolbar in old Alerts Table
Besides 7 exsiting actions, 3 new actions will be introduced this time. Some actions are targeted to alert itself and others are targeted to impact device.
Action targets to Alert
Assign
Add Notes
Resolve
Download
Send To ... (3rd part integrations)
Change Status (new)
Copy Alert Information (new)
Action targets to Impacted Devices
Quarantine via ...(3rd party Integrations)
Release quarantine from ...
Vulnerability Scan (new)
Assumption 1 - Group actions by the action targets: alerts or devices
In the old toolbar, actions were mixed together, it could be confused to users what action was doing what. Grouping them by the action targets might be more clear easier to find.
Assumption 2 - Users should take more action on alerts
Considering it's the table for alerts, users should focus more on alerts than devices. So alert actions should have higher priority. So I took out some important alert actions making them independent buttons and group other actions into the 'More' button.
However, in fact...
To validate my assumptions, I asked for permission to login into our real customs' production and found out that
90%
of customers have never assigned alerts or sent alerts to other systems since they started using our platform.
30%
of customers marked alerts as resolved very often.
Decision - Group and sort actions by frequency of use
From the data I got above, I realized that users didn't use our platform as the workflow system to deal with alerts. However, they marked alerts as resolved probably because that they wanted to achieve resolved alerts and focused on actives ones.
Based on the usage, I put 'Resovle' as the first button. 'Download' also had a higher priority because according to PMs knowledge, we knew users downloaded alerts documation and sent to their coworkers very often.
Final Mocks
Alerts Table
Before
After
Table Toolbar
Before
After
