Alerts Aggregation
with Data Visualization

Problems

One of the main features of the product is to generate alerts for a user when there are potential malicious Bots or Dos, DDoS attacks. In the previous stage, this feature was generating too many alerts that a user was flooded with them. Therefore unmanageable amount of information just became a noise to a user.

Forty2-alertPanel

This image is showing that this dashboard generated 322 total alerts. This number changes depends on the user’s web traffic.

 

It’s also showing that the alerts are from 6 months back, which also defeated the purpose of urgency of alerts. This happened due to the massive amounts of alerts that a user no longer can take care of them.

 

After analyzing the details of the problem, several goals that need to be achieved became more clear.

Goal

– Reduce the number of alerts.

– Provide a way for a user to figure out the prioritization to take actions on alerts.

Approach to come up with solutions

When I work on prototyping for possible solutions, I focus on the problems, what are the exact and specific problems that are triggering the issues. And then, the solution of how to improve or how to solve that specific problem comes out more tailored to the specific problem. Understanding the problems specifically is the first very important step for design.

 

In this example, there were several problems that are significant because they were causing usability issues.

 

1. Problem: Too many alerts – Solution: Aggregate alerts

 

How to aggregate the massive amount of alerts? That was the first and the most important task to figure out in this process. The existing interface was already providing a way to aggregate alerts by IP address. However it was still generating too many alerts and it was not sufficient especially the case of DDoS attacks coming from many different IP addresses and the system can’t aggregate alerts.

 

The fact that the existing interface showing 6 months-old alerts was a problem but it gave me some direction. The aggregation was not taking consideration of “time” perspective.

 

Hypothesis: By having timeline base information, a system can aggregate the alerts within the window of time that a user sees/specifies. By aggregating with time in addition to IP addresses would reduce the number of alerts generated by the system.

 

 

2. Problem: Prioritization of alerts – Solution: Have a way to compare alerts

 

Prioritization can be enabled only by comparison with other elements and the characteristics of its own within the whole entity. For example, in order to prioritize a specific alert over others, a user needs a way to compare the specific alert with other alerts and with entire aspect.

 

In this case, because the system generates malicious bots traffic as alerts, the alerts needed to be compared with other alerts and other network traffic. In order to achieve the aspect of comparison, I designed the interface to display the data visualization.

 

Hypothesis: The visual representation of data will provide a quick access and judgement ability for a user to compare the information.

Alert-aggregation-prototype

Alert aggregation prototype design that tried to reflect the thoughts described above.

Achievement

Data visualization for alert aggregation provided a great starting point for data scientists to come up with some algorithm and I initiated multiple discussions with data science team to further enhances the alert aggregation design.

Artboard 10

Alert aggregation timeline view

forty2-new-alert-list

Alert summary and lists of aggregated alerts view

Further improvements for the future

These are the lists of thoughts for further improvements.

 

Validate how much percentage of the alerts got reduced

This interface design came up with the hypothesis of different approach to aggregation would reduce the number of alerts generated by the system. However the actual data that shows if our hypothesis is right or wrong is not available yet. It would be great to validate if our approach to the aggregation actually helped the system to be more usable for users.

 

Redundant messaging within the alert list

Because we have only couple of alert types, the same alert message appears over and over. This redundant information does not serve the value for a user. Maybe categorizing the alerts under the type of the alert is another layer of aggregation we can consider in the future.

 

Horizontal list vs. Vertical list

Original design was displaying the alerts horizontally. Horizontal scroll was limiting the alerts to be compared side by side. It is more suitable for comparison of block information like Netflix movie thumbnail. If a user has to look at the detail text, like IP addresses, numbers of alerts generated for this IP address and so on, the eyes have to move different places to compare the same category of information because it is not aligned.

 

Therefore I presented vertical list of alerts, however, we received some feedback that some users prefer horizontal scroll over vertical. This is very interesting and curious investigation for me as a designer. In the real interface, we implemented the horizontal list that is same as before alert aggregation happened, due to the fact that till the investigation tells us the more clear conclusion, we better not change interface drastically so a user doesn’t have to face the complete new experience that might require some learning.