* All data and terms are mock or from public resources.

The Treasury Center centralizes a bank's core financial resources, including capital, funding, liquidity and balance sheet. It provides data-driven insights and helps decision making.

Duration 2024 - 2025

Background

As a bank with more than a hundred years history, data are stored in multiple places and with inconsistent structure. We target to centralize all these important financial data from different legacy tools and platforms into one single place, and to build a standardized, modern and powerful Treasury Center.

The Treasury Center provides access to all key treasury and financial metrics and analytics. With consistent data and report format, it helps bank senior managers and treasury specialist have a more comprehensive, accurate business insight and drive better decision making.

When developing this product, I collaborated with another talented UX designer to deliver designs, align with stakeholders, and oversee the implementation progress in a team of around 100 engineers, with fast-paced iteration.

Design Process

Design Goals

• Users still using legacy tools (like Excel) should feel instantly familiar with the UI
• Use cases (scenario, calculation and report) from different business domain should have highly consistent design

Most features are from existing tools and platforms. Before the design work, we set up interview sessions with internal key customers and users, to understand the pain points in their previous use experience. Below is our typical UX design process with deliverables in each stage:

There are usually several rounds of discussions until the final alignment. In the end, we have our key customers/users sign off on the detailed design, before handing over to the development team.

Feature - RWA

These are the design screens of a quick calculation tool for RWA (Risk-Weighted Asset):

To support strategic pre-trade planning, this tool provides an efficient way to calculate what the RWA would be under specific circumstances.

Users can save each calculation result, and compare details between different scenarios:

In mobile view, most functions are retained and an additional comparison mode is added:

Feature - Liquidity

This is a complex multi-model calculation feature for liquidity metrics:

After clicking on a calculation, users can view the calculation details, including the internal parameters and visualization of the results.

In mobile view, the condensed table layout is optimized to a card-view design:

Challenge - Consistency

One of the biggest challenges is the consistency from business side.

Some features serve similar purpose, but work in different ways, since they are originally from different business units and designed by different teams.

For instance, Treasury Center provides powerful model calculation capacity which most business units can leverage. They all share a similar user journey: get the data, calculate, then view result, which helps analyze the past and forecast the future. However, users from different business units are familiar with various process in their legacy tools and use slightly different terminology.

Our target is to maintain as much consistency as possible while ensuring that users can still interact with features intuitively.

We spent significant effort to align the detailed UX design with key stakeholders across different business units, while also retained the differences when necessary. We believe it's important to seek a balance between product consistency and usability.

Challenge - Entitlement

With highly sensitive data involved, user access entitlement becomes a critical process. The bank has a large multi-hierarchical organizational structure, and each user should only access information relevant to their role within the system. Moreover, the access control solution needs to be generic enough to apply to all features in the system.

To address this complex challenge, we designed a multi-level access entitlement structure. It supports distinct UIs for users with different access permissions, ensuring proper information disclosure while delivering clear, user-friendly feedback.

The screens below show different displays of the same page for users with different access permissions.

In Level 0 scenario, users are prompted to register:

After completing the registration process via the link, user can log in the system.

In Level 1 scenario, users will see a step-by-step guide:

Each section in the system menu has an independent access control. If the access to current section hasn't been granted during registration, this guide helps users apply for access to corresponding section.

After user completes an access application, the request may be split and sent to different regions/entities, business units, and function groups for approval, depending on the application scope. Because the feature and data involved may be managed by different admins.

This leads to a highly complicated situation with numerous possible combinations.

Below is the approval process for a request involving data across different regions/entities, along with an example diagram illustrating the relevant admins from business units and function groups:

These are edge cases that some split requests are approved while others remain pending or rejected. This leads to a situation that the access application receives partial approval. As a result, users can access the feature, but data from certain regions or entities remains unavailable.

The Level 2 scenario below illustrates this situation:

An alternative design was considered for above screen: only show the regions options that user can access and hide those the inaccessible ones. This approach would result in fewer selection options in the UI.

However, our team held differing views on this approach. To resolve this design conflict, we held a meeting with key stakeholders, where we presented the pros and cons of both designs. We also listened to our key customers' suggestions and aligned on the version that displays all options. The reasons are:

• Our key users are senior bank managers, who usually view data across all regions. If they lack access to certain regions, we should provide a way to request access rather than hiding those regions entirely.
• Region visibility is not sensitive information. Hiding certain regions may cause misunderstandings, such as the impression that the system is unable or limited to fetch data from those areas.

The Level 3 scenario below, shows a further example that user has access to the data in the region, but not all business units or function groups have approved the request:

When the permission is fully granted, users will be able to view all the content in the page:

For certain features, Level 2 and Level 3 users need to request additional Read or Read/Write permissions.

Managing this entitlement complexity presented the project's greatest challenge; however, we have achieved significant success in overcoming it.

Design System

We built the design system based on the bank's global design guidelines, and introduced some UI style innovation, such as the glassmorphism visual effect.

We aimed to fully support dark mode from the very beginning. Users can switch between light mode and dark mode at any time.

Below are some examples from the design system:

UI components in light mode and dark mode

Glass material UI panel

In light mode, we chose a photo of the city where most teammates are located as the background image. While in dark mode, we followed the same concept but used a photo of the city where our leaders are located.