My Role
Product Design
Stakeholder Management
Prototyping
Design System
The team
Designers
Software Engineers
Product Owners
Business Analysts
Subject Matter Experts
Timeframe
Oct 2023 - Present
Context
In the first half of 2024, businesses contributed 46% of the bank's profits, with 65% of that amount stemming from loans. Nearly half of these loans were Relationship Manager (RM)-serviced and applied for through the bank’s loan origination system.
As part of a bank-wide initiative to modernize its enterprise systems, the loan origination system emerged as a prime candidate—not only due to its age but, more importantly, because of the significant profits generated by RM-serviced business loans.
A new department and product team was formed for this project. Most notably, some of the bank's Relationship Managers joined as Product Owners.
Impact
As a UX designer, I was involved in improving the credit journey and designing new features for the system from its secondary research phases through to implementation.
I chaired meetings with credit approvers, risk portfolio management, ESG and relationship managers to gather requirements and seek alignment on design solutions.
Research
At the onset of the project, the team spoke to RMs to find out about the problems they were currently facing.
Disparate files and tools
RMs needed to use different applications and sift through the bank's intranet to generate documents, keep track of approval statuses, and apply for loans.
Cumbersome manual paperwork and processes
Forms often included irrelevant information and information had to be filled repeatedly across different forms.
These problems were apparent when looking at the time spent by RMs processing and reporting (56%), time that could otherwise be spent on servicing their customers and growing the bank's portfolio.
41%
Servicing & Growing Portfolio
56%
Processing & Reporting
Opportunities
The team identified several opportunities where we could reduce processing and reporting times. We used these as guiding principles for the platform's design.
01
How might we reduce the time spent on navigating through different systems to find the correct files and tools to use?
RMs should be able to complete the loan application within 1 system. This way, the creation, attachment and approval of documents can be easily tracked.
02
How might we increase the efficiency of paperwork and improve data quality?
Display only relevant inputs in all forms and documents, and cascade the same data across the system.
03
How might we streamline the approval and reporting processes?
Automate the approval process by suggesting appropriate levels of approval based on the application details and maintaining an audit log on the platform.
User Journey
(Credit Application Process)
01
Plan
I learn about my client’s financing needs
02
Prepare
I put together a Credit Application
03
Review
I discuss my submission with my approvers
04
Approval
I obtain approval
Parts of the credit journey I worked on.
05
Implement
I follow up on tasks to get my line implemented
06
Monitor
I monitor and track my client’s credit conditions
Financial Spreading
Previously, financial spreading was conducted on a separate system from loan applications. The documents were then attached as evidence to demonstrate the financial health of borrowers.
Modernising the loan orignation system meant we could use the opportunity to develop the financial spreading module in the new loan orignination system (LOS) itself.
I first explored the previous platform and spoke with POs and platform owners — Risk Portfolio Management (RPM). I wanted to find out the existing features, how they worked, and any improvements we could make to the experience.
Calculate projected values for financials
Financial Projections
The existing system featured adjacent tables — one for controlling projection parameters and one to display the calculated figures. Users found that it was difficult to identify which financial items they were applying projections for.
Initially, I proposed that the projection controls be housed in a modal in order to simplify the interface and bring focus to the calculated financial figures.
However, we received feedback that it was too disruptive to the general workflow. I redesigned it as a side panel instead to preserve interactivity and increase content density.
Customisable figures for analysis
Key Financials
I found that as part of their analysis, RMs often present key financial figures in a summarised table. These financial figures are either standard financial figures found in statements (Cash), or are a function of standard financial figures (EBITDA Margin).
I designed a key financials tab for RMs to present these key financial figures. I worked closely with our RM/PO to find out commonly used derived figures we could include as presets.
Building on this concept, I designed a custom formula function that enables RMs to add their own formulas beyond those provided by the system. We determined that simple mathematical operators would be sufficient, as the required formulas were not overly complex.
Obligor Grade (OG) Scorecards
In scorecards, RMs answer a series of qualitative and quantitative questions to obtain a score. These scores are used to quantify the potential risks of disbursing a loan based on the company’s standing, which are then evaluated and approved by credit approvers.
Similarly, scorecards were housed in the same system as financial spreading. The team looked to develop and integrate this module in the new LOS.
Research
Identifying Usage Patterns
Before designing, I wanted to find out the usage patterns and goals for users of this module, and how stakeholders evaluated these scorecards.
I worked with another designer and spoke to RMs, Approvers and platform owners to learn about their workflow in the current system.
01
Changes are few and targeted
When scoring existing borrowers for subsequent credit applications, answers for most questions stay the same.
02
Discretionary tweaking
RMs will use their discretion to adjust answers for more favourable scores within reason.
03
Score comparisons
In addition to current answers and scores, Approvers are also interested in what has changed from previous scorecards.
I first read through the module's User Requirement Specifications provided by previous platform owners (RPM) to understand the scoring system and the types of inputs needed.
I drafted a page template and structure and tested these with the various models together with RPM to identify any edge cases.
I designed the scorecard with Relationship Managers (RMs) and Approvers in mind, aiming to create a page that is both succinct and easily glanceable. At the same time, it offers sufficient detail for users who need to conduct a more in-depth analysis.
Challenges
Complex domain knowledge required
The credit journey contains many inter-dependent workflows and complex details about loans, which was new to me.
I actively worked with team members from other squads to identify cross-module dependencies and ensure design consistency.
Stakeholder management
The system and its associated modules will be used by stakeholders from multiple business units of the bank, each with their own viewpoints and business needs.
To ensure that design solutions were effective and robust for users and the business, I worked closely with product owners (ex relationship managers) to gather and distill key insights from discussions with the various stakeholders.
Design system constraints
We had to work with an inherited design system which contained outdated components and components not suited for a data heavy platform.
To tackle this, the design team conducted a platform audit and worked with the wider team to improve and update components.
