Back

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

Treasury Center consolidates mass financial resources including capital, funding, liquidity and balance sheet in a bank. It provides insight and helps data-led decision making.

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.

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

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 session with internal key customer and user, 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 customer/user sign off on the detailed design, before handing over to the development team.

Below is the final design of a quick calculation tool for RWA (Risk-Weighted Asset):

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

User can save each calculation result, then compare the details between different scenarios:

Below is a complex multi-model calculation feature of liquidity metrics:

When user clicks a calculation, the details are loaded dynamically into current page, showing the internal parameters and the visualization of the outcome.

Design Challenge - 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.

Design Challenge - Entitlement

With highly sensitive data in place, user access entitlement becomes a critical process. The bank has a large multiple hierarchy organization structure. Every user should be able to access only the relevant information in the system. We need to work out a generic access control solution for all features, and also need to make sure the information disclosure feedback in UI is clear and friendly to each user.

Below screens are different displays of the same page for users with different access permission.

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

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 completed the access application, depends on the scope, the request may be split and sent to different different regions/entities, business units, function groups for approval. Because it may cover feature and data belonging to different admins.

Below is the approval journey and an example of feature access approval with data across different regions/entities, business units, 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 of above case: we only show the region that user has access to, and hide those user cannot access. Hence there are less options for user to select in UI.

Our opinions on this topic became to diverge. The way we resolved this design conflict is: we invited all key stakeholders to discuss in one meeting, and presented pros and cons of both design. We listened to our key customer's suggestions and aligned to use the one showing all options. The reasons are:

• Our key customers are bank senior managers, usually they view all regions' data. If they cannot access some regions, we should provide a way to help them get access, instead of hiding them.
• Region option is not a sensitive information for our users. If we hide some, it may cause misunderstanding that our system is missing or limited to fetch data from those regions.

Below is a further example that user has access to the data in the region, but not all the 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

The design language of this product needs to be compliant with the bank's global design guidelines, and we brought some new UI style innovation, like the glassmorphism visual effect and dark mode. We have the ambition to support dark mode from the very beginning.

Example of UI components in light mode and dark mode

Glass material UI panel

In light mode, we choose a photo of a city where most teammates located as the background image. While in dark mode, we use the same concept but with a photo of a city where our leaders located - London.