Creating a revolving credit line
TEAM:
Ted Lee - Product Designer
Eula Atienza - Product Manager
Tracy Remoquillo - Engineering Lead
PROJECT STATUS
The MVP of the product was successfully rolled out May 2021 has been successfully rolled out to market.
TOOLS USED:
Figma
Miro
Notion
What is a Revolving Credit Line?
The Revolving Credit Line (RCL) is a new product that was designed to replace the existing financing portfolio of First Circle. Simply put, the RCL allows our clients to set up a credit line with First Circle that would be valid for 6 months, where they’re allowed to draw down any amount, for as many times—subject to our principal pay-down rules, by paying a subscription fee
With the proof of concept tested on a pilot batch of companies—and a lot of back and forth and trying to pin down the business requirements for the feature—the challenge for the Application Processing Team became:
“How can we adapt our existing products and infrastructure to be able to work for the Revolving Credit Line? ”
Discovery Process
To begin the process of productization of the RCL, Eula, our product manager, and I started by mapping out our existing customer journeys and identifying the key changes that needed to be made to accommodate the changes while highlighting which parts would be included in our RCL MVP.
Steps highlighted in yellow are steps existing with RCL pilot execution, while steps highlighted in orange are steps with changes for the productized MVP.
SCOPE OF the product
MVP Release:
Internal Backend (“FCC”)
Ability to create RCL within Credit Comm (currently created through the Input Engine)
Creating a loan offer for every drawdown without needing to tag a future revenue document
Creating a loan plan for every confirmed drawdown (after passing the credit check)
Lead Account Info Principal Paydown screens on the Sales tab show the customer's RCL
Automated sending of the subscription fee contract (currently done manually)
Customer Frontend (“FCA”)
Ability to drawdown funds through the customer's account
Upload future revenue documents as PO/IV and be automatically linked to the RCL
Future Releases
Internal Backend:
Creating a view of the customer's RCL in FCC
Creating a view of the customer's drawdowns in FCC
Identification of bounced/overdue checks for the Subscription Fee payment through the FCC
Automatically computing for SF and interest based on company type
Building the RCL features on a separate micro-app
Customer Backend
Uploading future revenue documents as RCL documents (not tagged as PO/IV)
Uploading bank statements, ITR, AFS
Building the RCL features on a separate micro-app
Designs
Once we had our plan in mind, we drafted some initial screens and shared across an RFC (Request for Comment) to get input from key stakeholders on our proposed changes before going ahead with more detailed design changes:
Aligning everyone on the RCL MVP Roadmap
Updating Lead Account Info
Making adjustments in the Drawdown process
Once we had gotten initial feedback, I proceeded to translate the user flows into screen flows
[FCA] Dashboard Changes
The first thing we tried to map out was to see how the customer dashboard would change once we had rolled out the RCL. We wanted to be able to map all the user states and scenarios: (1) What does it look like when the user doesn’t have an RCL? (2) What does an active, expired, locked dashboard look like? (3) How do we communicate that their RCL is nearing its expiry?
“What should the user see when interacting with the RCL?”
Going through this exercise, I realized that there were a lot of states and scenarios! To make things easier to understand, I created a visual matrix (see below) on how each component, shown in rows, would look in different scenarios, shown in columns. If they were connected on a horizontal line, then it means that it’s a component that can occur across the scenarios, otherwise, it was a mutually exclusive.
[FCA] How to Apply to RCL
The next thing we wanted to look at was the application process. The new product meant that we would be replacing our old financing models (Invoice Financing and Purchase Order Financing) and that our users would no longer need to rely on their account managers to create their loan applications and be, so we needed to review our current flows and adapt it for self-initiated, document-agnostic applications.
“How do users submit an RCL loan application?”
[FCA] How to Drawdown from an rcl
“How can the user access their RCL funds?”
For the drawdown process, we wanted to build upon the existing Amortized Loan screens, and modify them to provide better context.
In creating the different designs, we wanted to be mindful that the ability to allow the users to customize their loan amount and ensure that:
The user does not drop off from this process due to (a) information overload or (b) too many steps
The user is able to see and understand the different offers and how their loan offer changes (with respect to the critical loan plan details) as the term they selects change.
Be able to communicate a new business rule where they can choose to pay back their loan as (1) Amortized Loans, which we offer in 1-6 mos, or (2) Bullet Loans, which only have 1-3 mos terms.
We considered two approaches at the time. Solution 1 was a Step-by-Step Approach. This presents a more guided approach to loan offer acceptance, where we ask our user to select (1) Choose Loan Amount → (2) Choose Loan Loan Duration → (3) Choose Repayment Frequency, before confirming. This allowed users to be guided through the entire process, similar to what we’ve done in the past.
Solution 2 was a Dynamic Approach. Users are given a single view of their offer wherein users can play around with the three components (loan size, loan duration and repayment frequency) in a single view.
We did user tests and decided on the dynamic approach because it allowed users to be able to compare and play around with their loan offers more freely.
Next was trying to determine the order in which we asked our different options:
In Option 1, we add a new question: “Choose how you want to pay back”, which clearly communicates the decision point and makes the choice for the users visible early on.
PROS
We're able to highlight the difference between each type, which allows users to better compare and choose.
CONS
It's an additional question that adds to the mental load for our users.
There’s added logic to dynamically compute the rates shown when the user switches between loan types.
In Option 2, we simply show the Single Repayment option when the user selects 1-3 mos options.
PROS
We show all three parameters users need to select upfront, helping them make a more informed decision.
CONS
The single repayment options are tucked in and only show up when users select 1-3mos option.
[FCC] How do we create RCL Loans?
Now on to our internal tools. We wanted to be able to operationalize the process, and for the MVP, we needed to be able to capture all new pieces of information for RCL creation:
