The Brief

Network analytics is complicated and highly specialized. Setting up an alerting policy to be informed when specific events occur within a network can be intimidating given the terminology and the number of settings that can be configured.

The goal of this design is to simplify creating alerting policy templates as much as possible without sacrificing the customization options for power users to construct their own templates.

The design will also showcase how a team might respond to and interact with an alert once it has been triggered.

Policy Listing

This is a typical table view for alert policies. Standard table features like search, filtering, and sorting are present. Many different types of information from the policy could be displayed in the table, but the most relevant data is who gets informed when the policy is triggered (the notification policy) and what happens after that (the mitigation strategy).

The general layout for the application is meant to emulate an IDE with multiple tabs. Network infrastructure is complicated and being able to quickly cross-reference different components is extremely useful. The application is responsive and could also be split into a dual-pane view when needed.

Policy Categories

Previous iterations of the application had thrust the user directly into the alert policy template creation form, which could feature up to over 100 form fields depending on which options are selected. Users found this overwhelming and the form was the source of many support requests.

Here, top level categories are presented instead as a first step, allowing the user select the type of policy they want to create. On selection, they will be given further options to drill down into their desired function. At any point, advanced users can click on the Custom Policy button to make their own template from scratch.

Policy Selection

Once the user has drilled down to their desired level of specificity, they will be able to select a pre-made alert policy template that handles most of the technical configuration.

Special care must be made in the descriptions of each template so that there is no ambiguity about what the template is doing.

Pre-Made Templates

When the user creates a new policy from a pre-made template, the bulk of the policy's form is hidden and only the fields that are relevant for the user to customize are shown. This design allows for 100+ form fields to be condensed down to a more manageable 5-10 depending on the template.

While the fields are hidden by default, a summary of all values appears on the right so that the user will have no surprises regarding the policy's functionality. This will also allow novice users to gradually learn which settings do what.

At any time, the user may click on the advanced mode button to view the full form. Once a template is saved in advanced mode, however, it will remain in advanced mode thereafter; this simplified view will no longer be available.

Custom Templates

Advanced mode and custom templates both show the full alert policy form. Previous versions of the form had featured all the form fields on the same screen, but here they have been broken up into steps to make the form more digestible.

This first step mainly deals with the policy's metadata.

As with the simpler template form, the summary remains on the side. Because the form is broken into multiple steps, it can be used as a reference. The location of the save button at the bottom of the summary also encourages the user to review before saving.

Data Selection

The second step involves selecting the devices the policy will use, the metrics that will be tracked, and how incoming data will be compared to historical data to detect statistical anomalies.

While not pictured in this mockup, depending on which selection are made, additional fields may become visible.

Alert Thresholds

Once the data has been select, the alert policy requires thresholds to be set. The thresholds determine when an alert is triggered based on conditions which can compare incoming data to a historical baseline or when a static condition is met.

Then, when the threshold is met, the notification and mitigation policies determine what is done once the alert is triggered.

Multiple thresholds can be set per policy. Again, while not pictured, there are hidden fields that will become visible depending on selections made.

Alerting Dashboard

The alerting dashboard is designed so that the system status is apparent at a glance. The 3 cards above the regular table layout each display the most pertinent information.

The table itself has the usual sorting and filtering features and the columns are meant to display the current person responsible for responding and the severity and status of the alert.

The manual alert button would allow a user to manually create an alert instance that does not correspond to an existing policy as there may be situations that occur outside what has already been setup.

Alert Instance

Each individual alert instance will feature the relevant data graphed over time. The graph itself is interactive and has a scrubber below to more narrowly select a segment of data.

The red and yellow lines on the graph represent the threshold values specified from the alert policy and the triangles mark when that threshold was triggered.

While the graph above only shows the top data points, the table in the data tab below shows a full summary with additional information.

Alert Timeline

The timeline tab allows the user team to respond to the alert in a centralized location. System events like thresholds being triggered, notifications being sent, and mitigations being applied are mapped together with comments from the team on a chronological timeline.

The timeline is an essential feature that gives immediate visibility to the alert's status and helps organize a response. It can also be used for forensic analysis after the alert has been resolved.