Client
Trade Ledger Pty Ltd
Date
2023
Team
Matthew Carpenter, Lilian Chia, Brandon Grenier, Adam Joffe, Saf Sargent, Stefan Schmidt, Matthew Stibbard, Gagan Shrestha and Harry Wilson
UX and UI — Lending as a service
The new world, or Project Phoenix as it was known internally, would look to rebuild the Trade Ledger platform in an opinionated way, and extend the product to offer a comprehensive in-life management solution, the first of its kind in on the market.
Providing a tenant agnostic experience for business longevity and platform extensibility was key. This meant that Phoenix was approached without customer dictation and embraced new tooling and infrastructure to ensure success.
Design problem
When Trade Ledger was first established, it set out to streamline the traditionally lengthy, paper-based, multi-system origination process. As the lending landscape evolved, market investment shifted toward improving the in-life management stage of the lending lifecycle. We recognised that this was the natural next step for Trade Ledger to help lenders unlock the full potential of the working-capital market.
Over time, our product offering became increasingly difficult to maintain and extend. The codebase had grown unwieldy, the infrastructure became rigid, and the user interface and experience had become convoluted. In addition, the accumulation of tenant-specific configurations made the platform progressively more restrictive, and managing feature flags became increasingly challenging.
Primary objectives
Because this was a large-scale initiative, we anticipated a substantial number of objectives—many of which evolved as the project matured. However, our primary objectives included:
- Building a tenant-agnostic, opinionated product
- Delivering entity-management capabilities with full create, read, update, and delete functionality across both UI and API
- Reducing entity duplication and improving reusability
- Introducing collateral-management capabilities, enabling create, read, update, and delete actions for collateral linked to an entity for use within applications and facilities (UI and API)
- Implementing in-life management features extensible across all credit products, including functionality such as availability calculations, drawdowns, payments, repayments, multi-entity borrowing, and variations
- Creating role-specific dashboards for tailored user experiences
- Enhancing settings and configurability, allowing customers to align parameters with internal business practices, risk policies, and operational needs
- Improving role-based access control (RBAC)
- Strengthening audit-logging capabilities
- Enhancing integration experiences, including SSO, MFA, public registries, Google Places, e-signature, document generation, credit reporting, and cloud-accounting connectors
- Improving assessment-engine functionality and configuration
- Designing reusable UI patterns for viewing, editing, and deleting data (developed in parallel with the Design System)
Setting the foundation (Data Model)
Prior to beginning any design work, we assessed the current platform’s data model to gain clarity and direction on how we should lay the foundation for Phoenix. Through this investigation, we determined that the existing data model and its implementation were highly restrictive, rigid, difficult to extend, and shaped heavily by HSBC, Trade Ledger’s first customer, as well as various tenant-specific configurations.
As a result, we chose to start fresh and build a new data model that would address these gaps, resolve the issues we uncovered, and provide the flexibility needed to scale the product for years to come. Over the course of a month, we conducted multiple workshops to establish a robust data model and define key milestones. This process equipped the design team with clear guiding principles and informed the data structures required for different entity types, including people, trusts, businesses, and companies.
Information architecture
Alongside the development of the data model, we understood that our platform would eventually need to reach feature parity, and this redesign created the perfect opportunity to restructure our information architecture (IA) and resolve long-standing navigation issues.
Our first step was to map the existing IA to gain a clearer understanding of how the platform had evolved and the extent to which customer influence—particularly from HSBC—had shaped its structure. Using these insights as a foundation, we began reorganising the IA by moving, merging, renaming, and repurposing pages, sections, and subsections to improve clarity, consistency, and overall purpose.
Persona development
To better empathise with our users, we developed a set of personas that brought our end users to life and served as valuable reference tools for the business. These personas helped the team maintain a user-centred perspective as we refined the data model, planned milestones, and built out the UI.
Although we created several personas, we focused primarily on three due to their roles and involvement across the lending lifecycle:
- Relationship Manager (RM) / Business Development Manager (BDM)
- Operations Manager
- Risk Manager
User journeys
We were fortunate to work closely with Barclays, a new customer, to gain a deeper understanding of their existing in-life management practices. Through these workshops and from historical consultancy assets, we translated their processes into the ideal user journeys we envisioned for our in-life management solution.
These journeys covered all core functionalities, including drawdowns, collateral management, financial syncing, and more.
User stories
Concurrently with the user journeys, we began to create user stories, using a behaviour driven development framework to really empathise with the users and reduce requirement-build gap between technical and non-technical audiences. An example of this is;
As a Lender, I want to have the ability to update the details of a Company
Scenario:
A Lender can Add or Edit specific detail within a company profile as they have received updated information
Given a Lender is signed in and has navigated to a Company profile
Then the Lender can add or edit details within a Company profile
When the Lender clicks on the add or edit CTA
Then the associated information is rendered in an edit state
And the Lender can fill in or edit information
When the Lender clicks on the save CTA
Then the Lender receives a toast notification to inform them of their action
And the page is redirected to a view state
A whole new world
With the foundational work in a matured state and the Phoenix Design System in a stable condition, we had everything we needed to begin designing the new platform. Throughout the process, we remained mindful of the delicate balance between optimising the product for scalability and tenant-agnostic use, while still preserving the positive experiences and behaviours that existing customers had developed with the current platform.
Hallway testing
As we explored various design options, it became increasingly challenging to determine the most effective approach for navigation and interaction patterns. To gain clarity, we sought support from the wider team and conducted hallway testing with three different design iterations. These sessions involved eight participants from both within and outside of Product and Engineering. Each participant was asked to complete two scenarios, allowing us to observe how they interacted with the prototypes and listen to their real-time verbal feedback.
After the sessions, we collated and analysed all feedback. The insights gathered guided our navigation decisions and helped solidify key user-experience patterns.
Validating with tenants
After updating our designs based on the hallway testing, we arranged sessions with both existing and prospective customers to validate our approach. Although we were able to present the prototypes to only three customers, the feedback was positive, and concerns about our direction and handling of in-life management were minimal. The primary areas of feedback centred on jargon, configurability, and implementation timelines.
Documentation
As we continued to evolve and validate the designs, we recognised the importance of documenting major design iterations and explaining the rationale behind key decisions. This practice not only strengthened our design discipline but also provided a valuable resource for the broader business. These documents helped articulate our thinking clearly and served as effective discussion points with other functions of the business, helping us further refine and advance the product.
Next steps..
So what are my next steps?
- Continuous validation, continuous iteration and continuous documentation of designs
- Refinement of the design system when encountering component flaws
- Expanding out our stories and writing out behaviour driven development (BDD) acceptance criteria
- Work closely with front-end engineers to develop and test components
- Work closely with front-end engineers to develop templates, behavioural patterns and pages for staging environments
