Risk Management

Project Overview

As a product designer, I fixed the current risk flow and added an updated risk model to the platform. The platform provides a risk management tool in OT security (operational technology) and provides organizations that need a centralized and comprehensive view of cyber risk aligned with business priorities and industry regulations to ensure safe, productive, and reliable operations.

Problem Statement

The risk model was improved, affecting the platform's user interface.

There are a number of other issues that we want to address as well:

Having trouble resolving issues, the user wasn't sure how to proceed when finding risk
To understand the risk, the user had to look at multiple factors
There was a misunderstanding of the risk terminology
The meaning of risk wasn't clear
Risk scores weren't clear
The organization did not know what level of risk was acceptable

Research Process

Due to the technical nature of this project, I first needed to understand what we mean by a 'Risk' and the changes being made.
To understand what information can be helpful for the user, I also needed to understand what can be confusing since it can be very abstract.

Competitor Analysis

I have reviewed how competitors present risk in their systems: how they calculate it, display risk score, how (and if) they explain it,
what colors they use, and in what context they present it. There is a clear trend among competitors to use three colors and add score ranges;
based on context, more or less information is given about the risk.

User Research

There are several people whom I have spoken with, including colleagues, product managers, engineers who built the risk model,
and the research team who developed it. I have also spoken with the delivery and sales teams about their experiences and what
needs to be clarified for the customers. Upon reviewing the system, I found that there were some broken flows regarding fixing alerts.
They needed to check 3 screens to determine risk, and they weren’t sure what to fix first.

Map the key user flow

To understand what development time and effort will be involved, it was crucial to define what new views we would like to add and
what might need to be slightly modified. Since all pages in the system represented the ‘big picture’ of risk, the change in the risk model
affected them all in some way. By defining the flows of each possibility, I could see what changes would be needed.

Assets page - all pages related to asset management
Cases - task manager, when alerts can be resolved
Vulnerability - presenting possible security gaps

Persona

To ensure consistency in the customer experience, I used the more detailed personas I created in the past.
Each persona has a different role and responsibilities; the SOC analyst needs to know what needs to be fixed immediately,
while the operation manager makes a plan for the long run, delegating tasks and planning tasks.

Flows

Two main flows can be identified. In a simplified way, I refer to these two main flows:

What needs to be done now (high risk)
What needs to be done now (high risk)
What can be done later (medium-low risk)

In both use cases tasks must be opened and managed, the operational manager places more emphasis on impact (money) and the SOC on security.

Design

Explanation of the risk - added to the asset
Prioritizing the tasks: adding tolerable/attainable risk score
Automatically filter: filter the most urgent alerts in the alerts table
Risk colors and scores: changing the colors to make them more distinctive, alerts table view with a risk score, adding a range score to each risk level.
Work plan wireframes: help the operations manager plan his year, it was planned to add the Work Plan view in which he could manage tasks focusing on business impact. This is a separate feature plan.