OPORTUN • 2025
Optimizing a loan servicing platform for adoption
TIMELINE
2 months
ROLE
Product Designer
TEAM
Design Manager
Product Managers
Developers
OVERVIEW
Oportun is a fintech company focused on serving individuals with limited or no credit history.
They offer personal loans, credit cards, and a savings app, serving a current user base of 2.2 million across 41 states in U.S.
NASDAQ:OPRT
PROBLEM
Operational costs are rising due to heavy reliance on support calls.
Even though Oportun has a web and mobile app to self-serve, most of its ~800k active loan members still rely heavily on customer support calls accounting to about ~116k calls monthly.
…and this reliance contributes to increasing delinquency.
Members reach out to support during moments of uncertainty around payments, balances, or offer eligibility. When the product doesn’t clearly answer these questions, confusion leads to delayed decisions, missed payments, and increased delinquency risk. Shifting the behavior toward self-service requires building trust through transparency, clarity, and ease of use.
OUTCOME
Impact 1 month post launch!
↑ 395%
Feature discoverability
↑ 64%
App logins
↓ 29%
Customer calls
↑ 26.19%
Payment conversion
SOLUTION
Here are some of the core flows
The project began with an ambiguous scope that later expanded significantly. But we delivered a user-focused design that surfaced essential information contextually and in an easy-to-digest way.
Contextual payment widget
Members can access current loan information with a single click from the home page, with relevant details displayed based on the user's loan lifecycle stage.
Leading with transparency
Members can access current loan information with a single click from the home page, with relevant details displayed based on the user's loan lifecycle stage.
Easy access to payment receipts
Members can access current loan information with a single click from the home page, with relevant details displayed based on the user's loan lifecycle stage.
INITIAL OBSERVATIONS
The data shows that members primarily call about payments and loan information.
The PM shared data from the internal tool and shared why members call so and what % call for what reason.
But why Online Servicing? Why not other touch points?
Members reach out to support during moments of uncertainty around payments, balances, or offer eligibility. Additionally, we also tried to scope it down further to mobile web to start with due to the following reasons below:
Users preferred to go mobile first on Online Servicing web
Members reach out to support during moments of uncertainty around payments, balances, or offer eligibility. Additionally, we also tried to scope it down further to mobile web to start with due to the following reasons below:
Active users
Most of the app logins were recorded to be from mobile web.
Outdated designs
Web designs were not up to date with the latest design system.
Transition codebase
Switching from Python to JS, for sharing repo and consistency.
GOALS
Help users find important information
User goal
Reduce overhead costs and build trust
Business goal
Help users pay their bill on time
User goal
Reduce delinquency
Business goal
Make taking loans a smooth experience
User goal
Retain good users and repeat customers
Business goal
DESIGN PROCESS
Working my way down, thinking from a high level structure…
The PM shared data from the internal tool and shared why members call so and what % call for what reason.
Finding areas of improvement in the current experience and tried to be 'transparency forward' during the iterations.
Members reach out to support during moments of uncertainty around payments, balances, or offer eligibility. When the product doesn’t clearly answer these questions, confusion leads to delayed.
BEFORE
Multiple clicks to get to the payment screen and even then, the payable amount is inconsistent.
AFTER
Single click to get to the payment screen and the payable amount is clear and consistent across.
BEFORE
Important loan information are static and buried deep in the experience with no clear understanding of complex jargons and numbers.
AFTER
Loan information are upfront with understanding of complex jargons with easy breakdown of numbers with real-time updates.
BEFORE
Receipts that users downloaded before were static PDFs that was filled with jargons.
AFTER
Current receipts are easy to understand and broken down into contextual sections.
Mapping out all users states
I mapped out the user journey from start to finish, considering all possible user states that could impact loan and payment details. I focused on identifying relevant information to display at a glance and how it would vary across different user states. For example, a member who has missed a payment would likely want to see if any late fees have been applied and how they are calculated.
I did the same for the loan details section too, except the mapping there was different.
Finally, I joined all the pieces together to arrive at the key screens
I mapped out the user journey from start to finish, considering all possible user states that could impact loan and payment details. I focused on identifying relevant information to display at a glance and how it would vary across different user states. For example, a member who has missed a payment would likely want to see if any late fees have been applied and how they are calculated.
Rounds of reviews with stakeholders
Members reach out to support during moments of uncertainty around payments, balances, or offer eligibility. When the product doesn’t clearly answer these questions, confusion leads to delayed.
DESIGNing WITH CONSTRAINTS
Incorporating stakeholder feedback and making design iterations
The PM shared data from the internal tool and shared why members call so and what % call for what reason.
Despite a mobile web layout, a bottom navigation was added to meet guardrails.
But due to the bottom navigation, the information architecture got simplified.
Removing the quick actions as the bottom navigation made it feel redundant.
Several fields has to be removed due to the absence of events and API data limitations.
Members reach out to support during moments of uncertainty around payments, balances, or offer eligibility. When the product doesn’t clearly answer these questions, confusion leads to delayed.
QA & TESTING
I tested multiple simulated user accounts in staging and evaluated design specifications across various mobile screen sizes to be sure.
The PM shared data from the internal tool and shared why members call so and what % call for what reason.
We launched the new version to 15% of the user base to test the waters…
There were a few issues that needed to be fixed before the big release.
The PM shared data from the internal tool and shared why members call so and what % call for what reason.
Renewal sign-ups are low
Renewal is a card on the top of the fold.
Hardship CTRs dropped
Making sure the hardship cards remain visible in the first fold.
FINAL DESIGN
What we finally shipped to 2.2 million users!
REFLECTION
My key takeaways and learnings!
Outdated designs
App was outdated and not updated with latest design system.
Active users
Most of the app logins were recorded to be from the web app.
How would I do differently now with AI?
