LoanLab is an internal tool created for new and existing customers to set-up different scenarios of a borrower behavior (e.g missing a payment after due date) and compare the results. All the functions were created to visualize the API.
Context
Canopy Servicing is an API first Lending company. While customers know about lending and the life cycle of a loan, they have confusion about Canopy’s core system (API) and can’t understand the why of the end results on an statement.
The product was proposed to be the bridge between engineers, product owners and customer success, to test and agree on the system behavior.
My Role
Product Designer
Responsibilities
Wireframes
Meetings conductor
Final designs
Microinteractions
Product Iteration
Team Members
Technical Product Manager
1 FE and 3 BE engineers
Head of Design
Final Product Journey
Collaborating with PM on the product journey.
With research we discovered some common user understanding needs, these will shape the product journey:
Surface product configuration API endpoints: For new customers to know how can we support their lending program.
Account History: See all the actions in chronological order.
Behavior of account on each cycle: divide visibility by statement end date.
During the discovery phase I defined the “segment” of potential users, the ones with the need of understanding the system to help their customers and make their lending programs grow.
User Journeys
As a Product Owner, I want to check how my lending program will function with real user behavior to improve our offers.
As an Internal Customer Success Team, we want to replicate scenarios with anomalies coming from our customers to identify better solutions.
As an Operational Manager, I want to replicate the journey of some delinquent customers to identify patterns and preventive measures.
First Proposal
The first approach was to lead the user to set-up the account configuration and then create the action inside each cycle (e.g. month), mainly to support a backend limitation of rolling time.
Another agreement was to standardize terms, use more friendly descriptions and to keep the product familiar with the core platform, so we shared the same design system and paradigms.
Account timeline
The core component was a Ledger/Timeline where users could see the actions they added + triggered actions based on the system behavior with chronological order. They could also see the date and time they are visualizing the account.
To don’t saturate the platform with words, I decided to use icons and tooltips to let the user know what each line on the timeline meant and to provide feedback.
Changes based on feedback
After some showcases with internal stakeholders, I realized the first part was confusing; the user didn't understand what actions were and what would happen after. We simplified the workflow by showing the screen they were familiar with (a customer's account) and then leading them to create the actions.
What happened next
Daily active product owners, customer representatives, and engineers.
31 hrs usage weekly for testing account behaviors scenarios.
The product scaled to create test case scenarios and translate them to Postman to run QA testing.