* 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 Demo - RWA

This is the design 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 the mobile view, we retained all functions and designed an additional compare mode:

Feature Demo - Liquidity

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

When users click on a calculation, the details are loaded dynamically to current page, showing the internal parameters and outcome visualization.

For mobile view, we optimized the condensed table layout by using a card-view design:

Challenge - Business Consistency

One of the biggest challenges is consistency among different features. These features are from different business units, and originally 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 keep as much consistency as possible, and also let different users still use their features intuitively.

We spent lots of effort to align the detailed UX design with key stakeholders from different business units, and also retain the difference when necessary. We seek a balance between product consistency and usability.

Challenge - Access Entitlement

With highly sensitive data in place, user access entitlement becomes a critical process. The bank has a large multiple hierarchy organizational structure, and every user should only be able to access the relevant information within the system. We developed a generic access control solution for all features, and ensured the information disclosure feedback is clear and friendly to each user.

We designed distinct UI for all user access permission scenarios. The screens below show different displays of the same page for users with different access permissions.

After clicking a link of any product page, user without access to the system will be directed to the login screen:

Left is the login screen. Right is the feedback for unregistered users attempting to log in.

After completing the registration and got the basic approval, user can log in the system.

Each section in the system menu has an independent access control. If the access permission of current section hasn't been granted in the registration process, user will see a step-by-step guide to apply the access for corresponding content:

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.

Below is the approval process for a user access request involving data across different regions/entities, business units, and function groups:

This may lead to a situation that some split requests are approved whereas others remain pending. Below is an example that an access application got approved partially (some region hasn't approved yet or has rejected), therefore user can access the feature but data from some entity is not available.

There was an alternative design for the above case: we only show the regions that user has access to, and hide those user cannot access. This results in fewer options for user to select in UI.

Our opinions on this topic began to diverge. The way we resolved this design conflict is: we invited all key stakeholders to discuss in one meeting, where we presented the pros and cons of both designs. We listened to our key customers' suggestions and aligned on using the version that shows all options. The reasons are:

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

Below is 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, user will be able to view all the content in the page:

Design System

We built the design system based on the bank's global design guidelines, and introduced some UI style innovations, such as the glassmorphism visual effect and light/dark mode switch.

We have the ambition to fully support dark mode from the very beginning. 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.