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 sought to address the traditionally lengthy, paper-based, multi-system origination process. As the lending landscape evolved, the market shifted their energy and money to focus on enhancing the in-life management portion of the lending lifecycle. We understood that this was the next step Trade Ledger needed to take in order to help lenders unlock the working capital market.
Our current product offering also in its current state became unsuitable to maintain and extend. The codebase had become unwieldy, infrastructure rigid, and its user interface and experience, convoluted. Additionally, the numerous tenant-specific configurations made the platform increasingly restrictive and the management of these feature flags difficult to maintain.
Primary objectives
As this was a mammoth project, there would be a huge amount of objectives we'd want to achieve, with some of these changing as the project matures. However, the primary objectives included;
- Tenant agnostic and opinionated approach
- Entity management capabilities, allowing the ability to create, read, update and delete entities (UI and API solution)
- Reduce entity duplication on platform and allow for reusability
- Collateral management capabilities, allowing the ability to create, read, update and delete collateral against an entity to be used in an application or facility (UI and API solution)
- Introduce in-life management capabilities, extensible for all types of credit products, including functionalities such as availability calculation, drawdowns, payments, repayments, multi-entity borrowing and variations
- Providing role specific dashboards for a catered experience
- Enhancing settings to provide customers with configurable parameters to align with internal lender business practices, risks and needs
- Enhancing role based access control (RBAC) capabilities
- Enhancing audit logging capabilities
- Enhancing integration experiences, such as SSO, MFA, public registries, google places, e-signature, document generation, credit reporting and cloud accounting packages
- Enhancing assessment engine functionality and configuration
- Design reusable patterns of experiences for viewing, editing and deleting data from the UI (this was established alongside the Design System work)
Setting the foundation (Data Model)
Prior to any design work, we first assessed the state of our current platform's data model to obtain insight and guidance in re-evaluating how we should begin laying the foundation for Phoenix. Through this investigation, we concluded that the current platforms data model and implementation was extremely restrictive and over the course of it time, rigid and difficult to extend due to the architecture being heavily influenced by HSBC, Trade Ledger's first customer as well as other tenant specific configurations.
As a result, we decided to start fresh and implement a new data model that would address the gaps we had, fix the problems we uncovered and be flexible enough to scale the product for years to come. We ran multiple workshops over the course of a month to first establish a robust data model and plan for each key milestone we wanted to achieve. This armed design in setting up some guiding principles, and guided us on the data structure we would need to capture against various entities (people, trust, business and company).
Information architecture
Alongside the development of the data model, we undertstood that at some point, our platform needed to reach parity and this redesign gave us the opportunity to restructure our information architecture (IA) and in turn solve for the issues we faced with navigation.
The first step at tackling this task was mapping out the current IA to gain a better understanding around how we structured our current platform and the influence our customers, especially HSBC, had as it matured. Using this as the foundation, we began restructuring the IA, moving, merging, renaming or repurposing pages, sections or subsections to be better organised and have a clearly defined purpose.
Persona development
To really empathise with our users, we created a number of personas, bringing to life our end users and serve as a valuable tool for the business. These personas enabled us to reference and aid the team in empathising with our users as we continued to mature our data model, plan out our milestones and build out the UI.
Out of all the personas we did develop, we specifically focused on three primary personas due to their roles nad involvement in the lending lifecycle. These three personas were;
- Relationship Manager (RM) / Business Development Manager (BDM)
- Operations Manager
- Risk Manager
User journeys
We were fortunate enough to be able to work with Barclays, a new customer, to understand their existing business practices for in-life management. Through these workshops and also some historical consultancy assets, we were able to translate these into the most ideal user journeys that we envisaged for our in-life management solution.
These journeys addressed all core functionalities such as drawdowns, collateral management, financial syncing, etc.
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 rendrred 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 all the foundational work matured and the Phoenix Design System in a stable condition, we had all the tools in place to begin designing the new platform. A constant thought that resonated throughout design was the fine balancing act of optimising the product for scalability and tenant-agnostic usage, but also appreciating the good experiences and behaviours exiting customers would have established with our current platform.
Hallway testing
As we explored various design options it became challenging for us to nail down an approach for navigation and patterns of interaction, so we sought the help of the wider team and conducted hallway testing with three different design iterations. These hallway tests were conducted with 8 participants, both inside and outside of Product and Engineering. We requested each participant to complete two scenarios, allowing us to observe how they interacted with the prototypes, and their verbal responses to their experiences.
From these sessions, we collated and analysed all the feedback and the insights captured from this drove the decision for our navigation and solidified some of our user experience patterns.
Validating with tenants
Once we updated our designs from the hallway tests, we requested to set up some time with customers, existing and prospective, to validate the approach. Though we were only able to showcase our prototypes to three customers, the feedback provided was overall positive and there were very minimal concerns with our approach and how we addressed in-life management. The only major feedback and concern was around jargon, configurability and timelines for implementation.
Documentation
As we continued to evolve and validate the designs, we knew we had to document major design iterations and provide insight on how and why we made certain decisions. This was not only good habit for us in design, but also a fantastic resource for the business and all our employees to consume. These documents helped verbalise our thinking served as a good discussion point with other functions of the business to continue to evolve our 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
