Endpoint Security Dashboard Notifications
Endpoint Security
Dashboard Notifications

Designing notifications that let security admins tackle what's important to them and their responsibilities.

Notifications are nothing new in the digital world, from mobile devices to the tickers on the bottom of the screen when watching the news. In 2016, I worked on a few features for one of Dell's endpoint security and encryption offerings. My main tasks as a Visual/Interaction Designer involved refining and optimizing the patterns used in the legacy (former) console when or after they were implemented in the more more applications.

One of these applications was a security management console IT admins used to manage the security of many other computers. This application was Dell Data Protection Enterprise, or DDPE for short. DDPE provided a way for security admins to centrally manage the compliance, encryption, and threat protection of remote devices, also referred to as endpoints. An endpoint is any remote computing device that communicates within a network with other computing devices. This means an endpoint could be a: desktop, laptop, phone, modem, and who knows, even a drone. If it's a computing device that communicates within a network with other computing devices, it's an endpoint.

At the time, DDPE was being transitioned from a Microsoft Silverlight based console, to HTML, using frameworks like AngularJS and HighCharts to speed up development. The legacy console never had a notion of notifications or an up-to-date feed that communicated to users various happenings regarding their console and the endpoints they manage. 

My goal was to design efficient dashboard notifications within the given constraints, that could serve as a sold foundation for the first implementation of notifications for the application.

My role
Interaction Designer
Visual Designer

What I did
Requirements gathering
Design research
Interactive prototype (Axure)
Design Specs

1. Notifications are Subjective
"A sports fan may jump out of their seat when they see that their team won a championship, while a non-sports-fan would overlook that kind of news." How might we design notifications to suit specialists and generalists who may care about specific types of events? One IT admin's idea of something low in priority could be high to another IT admin. 

2. Priority Severity
Priority and severity may seem similar, but they're two different things. Priority is the order of importance and severity is how serious and risky

I had a few hypothesis before designing. I figured notifications would be subjective, with a notification's importance varying depending on the IT user's routines and responsibilities. I had these challenges in mind, when designing the notifications to be implemented in this application for the first time.

2 months for research, design, and testing.

Proposed design had to leverage available code assets.
Only minor styling was achievable.

Visual Design
Colors and various styling was based on a UI language (Clarity) that was also used in other products.

Initially, notifications would not be "globally accessible" from anywhere in the applicationonly the dashboard.​​​​​​​

A few of the requirements were...
- Display the type, priority and date at a glance.
- View more details of the  notification along with download links and online references when applicable.
- Dismiss notifications. (Dismiss was the term used instead of delete or remove because the notifications remained in the database even when dismissed, because they could still be retrieved through other means, such as in Compliance Reporter.)​​​​​​​
The Scope

Product Updates
Such as software patches and KB articles

Configuration Changes
Such as changes made to a system

License Notification
Such as expired licenses

Such as threat reports and vulnerabilities found

Knowledge Base
Informational and insightful articles

In addition, these notifications supported external and internal alerting. This meant notifications received may be from external sources from third-party apps (Managed by a dedicated Dell DevOps team) Third-party apps could utilize DDPE's API to create an integration for sending and receive alerts.
.Color and icon explorations for notification severities and types.
Design Research
Notifications can easily be overwhelming to the point where users overlook important events. Seeing the type of notification coupled with its criticality provides an idea of how users could prioritize tasks.
I pulled inspiration from common mental models for organization and how we separate informational and critical data using color, symbols, etc.
I also checked out how other systems management and endpoint security applications handled security. Most of them provided very high level metadata regarding notifications and then guided users to a dedicated page to where they can jump straight to the root of the problem. 

However, this kind of model wouldn't work because what was scoped for this effort was viewing and managing notifications from the dashboard.
I pulled inspiration from various sources around the idea of organizing and visually representing different messages.
Design Explorations
I exercised how the widget's design could be repurposed as a global pattern in the future, as well as embedded on the dashboard, which is what was scoped for the first release.
Ways of viewing severity
Multiple ways were considered when designing for severity. One way that stood out to me was by showing degrees, instead of a specific color. For example, four red circles completely filled in would signify more severe than just one or two red circles filled in.

Many of Dell's enterprise applications showed a list of alerts and notifications without any visual context as to the type of alert. Which was alerting to me.
Notifications Need Context
Notifications without context to the type of notification was too ambiguous, compared to with context. (or a "cue" as I called it)
The Proposed Design
Developing a completely new UI pattern was not feasible for the first release, so I utilized the data grid (table) that was already used in other areas of the application. In many ways, this makes sense, as the future plans at the time was to evolve this pattern to be a dedicated page for viewing and managing notifications.
Some design specs highlighting some of the features.
I created a high-fidelity prototype using Axure to serve as a more realistic representation of the widget's workflows. This served as double-whammy. This not only helped with user testing but also specified the design design direction for development.
Flagging notifications and then filtering by flagged.
Interaction for viewing notification details.
Additional Flows
One user-story involved providing a way for users to opt into receive notifications when the feature became available.
Another story was a way for users to manage the severity and type of notifications they'd like to receive. And they could manage internal and external notifications to be sent via e-mail alerts.
Icon Explorations
Notification details screen.
Searching for specific notifications.
Corner case showing an empty state for notifications found based on filter applied.
I worked closely with one of our usability engineers to define the objectives and tasks for a survey and usability test. We wanted to better understand the mental model users had concerning notifications and check for any usability and knowledge gaps for the proposed features. We recruited 14 potential users who were a mix of generalists and specialists. Some focused more on niche things such as networking and databases, while others who worked in smaller organizations had a wider focus spanning many things. 

For the usability test, we tasked participants surrounding two core features. One was Notification Management: which included flagging, filtering, dismissing and undoing notifications; and another was Viewing Notifications: which included the ability to decipher notification types and severityas well as ability to find resources such as KB articles and downloads.)

Over 90% of users used notifications to carry out responsibilities that were specific and unique to their job and over 80% of participants had no issues performing the tasks asked of them. Most users also felt the term severity made more sense when determining how critical events were, instead of priority.
Post Dashboard Notifications
I also provided a look into how notifications could be managed at a more granular level. Things is usually done on a dedicated page, which I dubbed Notification Center. It would basically behave as a dedicated page for notification management, settings, and even things like data analytics.
This was the first project at Dell I worked on from beginning to end. I remember falling in love with the power of Axure and its ability to quickly make low and high fidelity interactive prototypes. (However, it is easy to get carried away)

There will always be compromises in design. This is especially true in the digital world, where the frequency of change is high in order to adapt to users' needs and the market.

It was important for me to zoom in and out, to understand how notifications could add value to IT users focused on endpoint security. I always had scale in mind. I wanted I designed to easily evolve to more granular notifications and management, while retaining a familiar look and feel for users. Notifications only on the dashboard was a compromise, but if the design satisfies the needs of the product and users' motivations, it's a win. 

It was cool to help set the foundation of notifications to be implemented in this application for the first time, as well as related products that had to surface divergent types of severities of notifications.

Thank you! ✌
Endpoint Security Dashboard Notifications

Endpoint Security Dashboard Notifications

Designing dashboard notifications for an endpoint security application, providing IT admins a way to tend to what's important to them and their r Read More