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.
What I did
Requirements gatheringDesign research
Interactive prototype (Axure)
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.
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 application—only 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.)
Such as software patches and KB articles
Such as changes made to a system
Such as expired licenses
Such as threat reports and vulnerabilities found
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.
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 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 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.
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.
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.
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.
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 severity—as 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! ✌