Operational Risk Management Platform

Objective

One of the top three banks in the world was looking for a better way to measure operational risk across all of the organization’s departments. They reached out to us to help them identify areas of improvement in their current platform and to come up with an upgraded method on calculating operational risk across the firm’s departments.

Problem

The firm was limited in identifying risk trends across different departments because there was no functionality in analyzing all the departments’ statuses of all risks over time. The company also realized that different departments were facing the same risk types, yet they were unable to connect these across. Therefore, it was almost impossible to accurately determine the cost and significance that an exposed risk could have on the firm.

My Involvement

I worked in this project for a year and 3 months, specifically in the reporting and analytical stream. I, along with another UX designer, worked with the client continuously to guide and establish requirements for the reporting framework. We did over 30 user testing sessions to test functionalities, business requirements, accessibility and navigation, and presented our mockups to top management within the firm.

Control Managers

Control Managers are in charge of setting the right controls to mitigate risks. One of the most important tasks for these users is to determine whether a control is applicable and efficient against a risk. They are also responsible for managing these controls when they are not performing as expected.

Business Owners

Business owners are responsible of ensuring a healthy risk exposure for the line of business they own. They oversee Control Managers and tend to focus on the overall business risk exposure instead of the control setups against risks. They are responsible of reporting their current businesses’ risk exposure to higher management.

This application is for +10,000 users, all located in different areas of the world. Our stakeholders chose the most relevant users that volunteered to help improve the platform. We had the luxury to run user testings with 6 different groups of users, 3 sessions per week. We also had a weekly call with the main stakeholders to keep them updated on what was being worked on.

On the Lab49 side, we had weekly prioritization calls where we established deadlines for each task. We ran weekly design critics where a designer presented a design in order to receive feedback. We used these sessions to establish navigation patterns, color application, button styles and anything that was used across the streams to provide a clean, consistent application.

We did most of our sketches on whiteboards to brainstorm different ideas and concepts, as well as to iterate on them with our Product Owners. Once we had something that worked, we went to building the mockups and eventually test it with users.

Process Risk Profile - Filtering & Drill-down

The purpose of this page is to inform the user (most likely a Control Manager) about their risk health for a particular process within a business. Before the implementation of this page, users were complaining about not being able to understand the relationship between elements (that is, how risks were being mitigated), and failing to localize the problems when a risk was exposed (heightened).

For this page, I designed visualizations to summarize the data underneath a process so that the user could easily understand the overall health of the process. Given the amount of data that a user might encounter, I created a filtering functionality that allowed them to exclude irrelevant items from their focus.

For a user to understand the relationship between items and identify where the problem for a particular risk was, I created a drill-down modal that enabled a user to navigate down the chain of a risk setup. This effectively saved big amounts of time to users to locate problems and solve them.

Process Risk Profile - Impacted Areas

A process’s elements can be “borrowed”, or “copied” to other processes within the business.

For example, if User A owns Risk 1, and three different people have copied Risk 1 to their own processes, these three users are relying on User A’s management for Risk 1. User A user can view who relies on Risk 1 by clicking on the toggle “Impacted Areas” .

The firm strictly requires users to know whether their risk setups are impacting other parts of the firm. By this, they can ensure users act responsibly when making any changes, as well as informing users how much weight their elements carry across the firm.

Trigger Actions Dashboard

A “trigger” is a functionality in the platform that acts as an alert. A trigger breaches when the current value goes beyond or below the set thresholds. Once a trigger breaches, users get notified right away so that they can take action.

The Trigger Actions Dashboard helps users to view all existing triggers in one place. They can view these by what they are set against, by their status, severity, or by business. This enables users to prioritize their workload and to easily understand whether the trigger setup is accurate and efficient.