Security team receives alerts for anomalies on content

Identify user / business needs

People in the CISO role (Chief Information Security Officer) care for one thing above else to protect the organization assets from getting on the wrong hands or destroyed. However, if something were to happen, it's vital to alert them about potential risks and present accurate and valuable information with urgency.

Product definition

The main goal is to reach the CISO with urgency to present the relevant information and to enable the option to share this alert, knowing that the mobile device is the one that people check more often and even has ways to push notifications, so we could asume the CISO would look into it shortly.

Brainstorming

There was a long brainstorming process early on, when determining the alert behavior, however when the project reached the mobile implementation it was more or less defined already.

The implementation of the alerts on the mobile app is an extension of a feature I collaborated with before; the information displayed was the result from ongoing discussions with stakeholders about the meaning of risk in an enviroment such as the Kiteworks platform.

The mobile design had to adapt a new view that would only be available for some types of users; fortunatelly, the primary mobile navigation had been recently simplified, so this wasn't a problem.

User research

Based on the hypothesis, the team met with internal and external stakeholders, such as the CEO and other excecutives, as well as some customers that shown interest in these types of tools before; the goal early on was to get insights into their motivations, expectations and later on to validate versions of the prototype.

Problem / Solution validation

The primary question we had was the types of risks that they were aware of and how they would like to get notified. Then, the questions were more about the alert we had in mind to qualify its merit according to this user.

Once we had an initial prototype a cycle of quick critique sessions with different and relevant stakeholders took place to evolve the design to its final state.

Team alignment

I served as the link between the team working on the AI to detect alerts and the teams working on the mobile apps. Meeting regularly with both teams helped everyone to be on the same page.

The spec documentation and the prototype help bring everything and everyone together, giving everyone access to the design and the ability to ask questions and make comments.

Explorations

To streamline the information to the user and allow her to act on that information, we thought about adding a button to share. However, after testing with internal stakeholders, we discovered that the user needs to see the alert's full details before deciding to share.

Idea of expand push notification for options, to see details or share alert.

When capturing the details that the alert needed to contain, including the metadata, it was clear that some repetition could be avoided. We also got feedback about a better display of the location to understand where the alert was triggered.

Idea of full alert details including the files that triggered the alert.

This design shows a dedicated text search field to narrow down search results to create the tools for the user to find alerts quickly. It turns out that after some testing with internal stakeholders, we realized that the number of warnings was going to be small and the frequency sparse, so a single search filter was enough.

Idea of search and filter alerts.

Iterations

The idea of filtering as an end goal was correct, so we explored ways to simplify the ability to see the query and the filters without the clutter of the three text boxes. We did not investigate further, given that more alerts would take time to develop and nothing complicated would be needed at that moment.

Iteration on the search alerts interaction.

When thinking about the options for each alert in the context of risk management, we explored the type of actions that the CISO would want to take on the user who triggered the alerts; however, given that the level of confidence can't be determined on the alerts, we decided not to expand on these ideas for the moment.

Iteration on the alert actions' menu.

This iteration was designed to test the option of not investing in any search, filter, or sort capabilities; however, given that the engineering effort was small and the number of alerts was expected to be low, this iteration was discarded.

Iteration of a version without any search, filter or sort capabilities.

To explore ideas around the central metaphor of alerts, one idea early on was to enable a snooze option assuming the system would somehow insist on it if the behavior continued. Together with the AI team, we determined that creating too much noise may reduce the confidence of the CISO, therefore increasing the possibility of turning off the alerts altogether.

The tab's name was initially "Alerts". However, we discovered that some people assumed that all alert notifications would be located there. Given that the new view was only available for the CISO, the final name for this version was "CISO".

Iteration of swipe to see option to snooze alert.

Final solution

The following is a click-throug of a rough prototype to show the push notification interaction.

Apart from the push notification, we also used the count on the badge to show the number of unread alerts to let the user know that there is something unread ready for her to see.

Final design of badge count on app icon referring to unread alerts.

The final design is a list of alerts ordered by more recent on the top; each item on the list has some details and a signal to indicate if unread. The shortcut to mark as unread is to give quick access in the case of a false alarm; in the contrary case, and the alert is accurate, the shortcut to share the info is helpful.

Final design of list of alerts and swipe actions.

Given that the data was very consistent for this version, the search box could filter by name or location by directly typing; the only filter needed was to show or hide archived alerts. The results had the exact indication of unread if applied and the actions' menu to access any function available. This pattern on the search results is the same used on other views of the mobile UI.

Final design for search alerts.

The alert menu included the options to mark or unmark as unread to manage items similarly to email messages on the Mail tab, archive alerts for false positives, share the details using 3rd party apps, or the built-in Mail function. This same menu is available from the Alert details page.

Final design of alert actions' menu.

The alert's details page showed all there is to know about the alert and offered all the available actions mentioned before. The idea is to present enough clear information for the CISO to determine if the alert represents a valid risk, and, if that's the case, please get in touch and share the details about the alert.

Final design of the alert full details page.

Success metrics

The feature itself had a crucial success metric that affected UX, but it was out of my control, the relevancy of the alert, the fact that the information expressed the signal, and ignored the noise.

The design had the same success metrics as other projects, to be intuitive, helpful, and most importantly, to ship on time.

Learnings

I learned about alerts from the perspective of UX and AI patterns, such as the signal-to-noise ratio or the push notification.

As a team, we were able to release the first of its kind and validate the idea of the offer to CISOs; this helped start many conversations with current customers about the types of alerts specific organizations might be interested in.

Future iterations

Other alerts for different behaviors followed and are expected to continue to be added using the same framework to manage, consume and share the alert details.