About the product
Context
Canopy offered two products at that time: the core API and a management platform for lending. To complete the full lending package, a borrower portal was needed. The opportunity came with a new customer requiring such a portal for their borrowers. The portal was designed tested along with the client.
My Role
Product Designer
Responsibilities
Wireframes
Product Journey
Iteration with stakeholders
Final Designs
Team Members
Head of Design
Customer Success
Engineers
Final Designs
Defining the core functionalities
A borrower portal essentially functions as a banking app for payments. To avoid the need to reinvent the wheel, we gathered information about additional scenarios our customers might need to cover, aligning with the information and management provided by our other products.
Some functionalities:
Opening account onboarding.
Making payments (manual or scheduled).
Recording transaction history.
Configuring user information.
Managing different payment methods.
Handling single or multiple loans for one account.
First design explorations
The initial concept for the borrower portal shared the same layout as the servicing platform but was tailored for
scalable products like an account with more than 10 loans.
This one had an easy to read layout for the users with the important information on top, the only thing that didn’t scale were the tabs.
First concept was to have access to the loans on the right, the problem is that some customers will just have 1 loan, so there would be a lot of withe space.
Mid-fidelity wireframes to present to customers
Once a more solid direction was established, I quickly developed mid-fidelity wireframes to show the potential of the borrower portal. These were presented to customers to ensure alignment with their user needs and expectations. Some sessions were conducted, incorporating feedback until confidence was gained to finalize details and enhance the designs.
Key Findings
Customers preferred using their preferred payment processors, leading to the addition of third-party integrations like Plaid.
Compliance issues required safeguarding borrower information in both software platforms. The autopay option was introduced to reduce missing payments.
Adapting the software to cover case scenarios
Now, the borrower portal needed adaptation for different lending scenarios.
I optimized the process by removing truck drivers and delivering final results through the system instead of supervisors.
Building the components
Every component was designed as a molecule, allowing for easy switching or configuring boolean properties on the frontend based on customer preferences. This flexibility made them usable as standalone widgets.
Mobile Design
Internal research indicated that most borrowers used phones to manage their accounts, prompting the design of responsive mobile screens.
White labeled for CSS custom use
The app design system was customized using CSS styles for different customers, making sure it can easily match various brand colors.z
Product Metrics
The product was successfully launched with one of the biggest customers, then it was introduced to new customers.
Used by 1200+ users In the first 3 months after launch.
+$800,000 Annual Revenue 3 deals closed because of the Borrower Portal.
Reduced lending programs launch time From 6 to 2.5 months per customer.