Loan Dashboard
Context
We had just completed the initial launch of the Loan Dashboard MVP, marking the first opportunity for our borrowers to interact with an in-app experience after submitting their loan applications.
This was a significant milestone in our journey to enhance the product experience, providing ongoing support to borrowers throughout the duration of their loan with Backflip.
This version offered a clear summary of the processing steps along with a few simple tasks. However, true to the essence of MVPs, this was just the starting point. For Version 2, we aimed to significantly enhance user value.
Gathering feedback
User Feedback
Before diving into the design of new features, I aimed to grasp how users were perceiving and engaging with our MVP. I put together a user research plan, then scheduled a week of user interviews, each lasting about 45 minutes, with participants of diverse experience levels. Users were shown a prototype illustrating various stages of the loan process. They were asked to provide their initial impressions, clarify their understanding of the information, and offer their feedback.
Once I finished all my scheduled interviews, I compiled the data in FigJam and delivered a UX Research Readout to my team to better align our understandings.
Opportunities identified
Prioritize user priorities
Timeline, loan status, and financial data should be visible at a glance
Streamline processes
Reduce friction in the draw, SOW, and form-filling experiences
Simplify app + web workflows
Maximize features for devices where users are most likely to use them
Design for clarity & accessibility
Larger fonts, cleaner layouts, and less visual clutter
Cross-Functional Internal Feedback
After collecting user feedback, my product manager and I collaborated to seek insights and suggestions from various departments within Backflip. We recognized that obtaining firsthand knowledge from those working closely with our members was crucial for identifying what would deliver the greatest value to both our users and our internal teams. We organized several brainstorming workshops with small groups of team members from different areas of the organization, including Processing, Underwriting, Sales, and Member Experience.
Opportunities identified
Improve communications
Align emails, text messages, and push notifications to notify users of loan status
Clarify process outline
Better communicate deadlines, tasks, and upcoming needs to users
Educate members
Help our members have a clear understanding of the products Backflip offers, our process, and industry insights
Pops of delight
Consider incorporating small feature additions like a closing countdown timer, processing team member bios, etc
Breaking ground
Getting up to speed
A significant portion of this project involved gaining insights into the Loan Ops team’s internal processes for handling loan applications. Until this point, our team had relied on a mix of software and integrations, some featuring intricate workflows (like HubSpot and Trustpoint), while others were quite manual (such as Notion, FileInvite, and Google Drive). One of our primary objectives for the Loan Dashboard was to automate as much as we could and consolidate all essential documents and information in one central location for easy access—HubSpot. Our engineering team would need to establish new API connections to ensure that the necessary data flowed seamlessly from the app to our processing team, and vice-versa, allowing users to receive real-time updates on their loan status.
Before we could proceed with designing the new user experience, it was crucial that we fully understood the specific challenges we were addressing, as well as the technological constraints and feasibility of our proposed solutions.
This resulted in numerous Slack messages, virtual huddles, and Zoom meetings.
Wireframes…?
Thanks to the groundwork we had established, we gained a clear insight into the challenges we needed to address and the opportunities we aimed to seize. This meant it was time for every product designer’s favorite phase: bringing ideas to life on screens!
For the sake of moving at a start-up pace, I leveraged v0.dev (an AI tool that generates React components from natural language prompts) to create an initial framework from specific prompts informed by our recent learnings and objectives.
Hot take: AI prompts are the new wireframes
Why v0.dev? The Backflip app and website are developed using React Native. Recently, I introduced a new design system for our team called Blueprint, utilizing the ShadCN library to ensure compatibility with React components. Given that v0.dev produces React components in its outputs, this gave me a head start as I began designing, as I was able to build off components that are a ~75% match to our own.
This approach enabled me to explore ideas rapidly—quicker than using pen and paper or building wireframes—by encouraging the AI to suggest different alternatives as quickly as I can think of them.
Now that I had a clear visual direction, it was time to to refine the details and finesse the nuanced user experience that AI cannot deliver.
v0.dev mockup
Design
Using the v0.dev mockup as a launching point, I began to put all the complex learnings together and finesse the details.
Each phase of the loan process has it’s own unique needs, timelines, and requirements. There were a few primary questions that we wanted our members to quickly find the answer to when visiting our app, so we designed specific components of the dashboard to answer each.
"Is my loan on track, or delayed?"
Both our user and internal research confirmed the primary need of a user visiting this dashboard: Understand if the loan is on track to close.
A large volume of our internal team’s support call time is spent updating members on the status of their loan.
Is it on track? If so, what day is it tracking to close?
Is it delayed? What is the blocker keeping it from making progress?
Am I (the borrower) currently a blocker?Or is it progressing behind the scenes?
To answer these questions in a glance, I added a Loan Progress bar to the top of the Dashboard.
"What stage is my loan in?"
We streamlined the loan process into seven key stages, from the initial loan application to the closing day. Each stage comes with its own set of tasks and requirements. Although these stages typically follow a linear path, the underlying rules can vary. In certain stages, all requirements must be fulfilled before moving on, while in others, users may find themselves navigating two stages at once.
The challenge was to present this information as clearly as possible to the user, while also accurately reflecting the backend requirements.
To achieve this, I had to carefully customize the information shared at each stage according to its specific requirements and corresponding statuses: "Completed," "Needs Action," "Blocked," "Pending," and "Upcoming."
Early explorations on handling each stage’s specific requirements
"What is needed from me?"
A common question we received from users revolved around understanding the various nuanced details regarding requirements.
What documents do I need to provide?
When should I submit them?
How can I confirm that my submission is adequate?
Where can I find each form?
Until this point, documents had been gathered through multiple channels, including email, Excel, FileInvite, and Notion. Our long-term vision was to streamline the collection of all necessary information through our new dashboard. However, the current scope of this project couldn’t support that just yet. As an intermediate step, I developed a Processing Requests portal that outlines all requirements along with relevant links. Once our processing team verified that the submissions are sufficient, users would see them marked as “complete.”
Before long, and by focusing on the primary questions on the minds of our users, we had the new Dashboard flow ready for review. With the high complexity of this project, and the many internal teams it touched, I held several rounds of design reviews, each focusing on the primary details impacting each team’s function:
Product manager review
Does this meet the requirements?
Does the design complement the back-end needs?
Is it within scope?
Loan Ops review
Does each stage, task, and instruction adequately reflect the loan process?
Does this offer the clarity and nuance needed?
Will member representatives be able to easily guide their clients towards using this feature, and will it be understood?
Will this eliminate a good percentage of the team’s regular support call time?
Engineering review
Are all the UX patterns presented logistically feasible?
Is it aligned closely enough to the component library?
Does the value of the custom UI pieces warrant the extra time they will require to build?
Do the engineers understand the design requirements as presented?
Handoff
Once we reached alignment between cross-functional teams, I gave my designs a final once-over to ensure everything was handoff-ready with clear annotations and supporting details.
My goal during handoff is to provide as much clarity as possible around interactions, edge cases, content, and behavior. For smaller, more predictable projects, I’m comfortable leaving some decisions to engineering if it helps us move faster (while staying available for questions). But for projects of this scale, I’ve found that being detailed upfront helps preserve intentional design decisions and avoids costly ambiguity down the line.
After handoff, I prioritize being available for any questions from engineering, especially on projects with complex logic and multiple dependencies like this one. Throughout implementation, the PM, engineer, and I stayed in close contact to make sure we were aligned every step of the way.
QA
If I’m honest, this one was a beast to QA. Testing required us to submit full loan applications through our test account, which fed into HubSpot as if they were real loans. That meant coordinating closely with the loan processing team to make sure we weren’t interfering with their actual benchmarks or workflows. We also had to get access to the processor and underwriter views in HubSpot so we could move the loan through each stage–verifying that the right UI showed up at every milestone, especially in “blocked” or “delayed” states.
On top of all that complexity, we also had to cover the usual QA requirements: testing across different devices, browsers, and environments. With so many moving parts, it would’ve been easy for things to slip through the cracks. To keep us organized, I created a QA testing template in Google Docs to track who was testing what, which scenarios had been covered, known issues, priorities, and ongoing updates—all in one place.
Implementation
As we were wrapping up the final details before launch, we knew adoption would hinge on encouragement from the Loan Ops team. Borrowers trust their guidance, and we needed their buy-in. The PM and I led training sessions with the team to walk through the new dashboard, so they felt confident using it and could help borrowers get the most out of the experience.
After launch, we kept a close eye on MixPanel, FullStory, and our #product-feedback Slack channel to quickly respond to any possible bugs or friction points.
Results
Note: At the time of writing this case study, this feature was newly released. More results will be added as they come available.
Early results are promising—users are reporting higher satisfaction with the visibility they now have into their loan process.
Accurate metrics will need to be evaluated after 1+ loan cycles (~30 days per cycle) to best understand how the new functionality is impacting customer satisfaction and internal processing and underwriting team efficiency.
Quantitative metrics that will be measured include:
Number of loan status support calls (compared to v1)
Days from application to processing handoff
Days from processing kickoff to underwriting handoff
Days from underwriting to close
Weekly retention of applicants (V1 vs V2)
Daily retention of applicants (V1 vs V2)
NPS score (compared to v1)
App store reviews
Qualitative research that will be conducted include:
User interviews
Usability testing
Borrower satisfaction (as expressed to member-facing teams)
FullStory Dashboard of early (~ 2 week) results
Future-proofing
During this project, our company was still focused on a mobile-first approach due to limited engineering resources. However, I realized that as we enhanced our technology after loan submissions, we would require desktop-friendly experiences.
I utilized the new component library I tailored from ShadCN to create a mockup of a future desktop experience, ensuring that this feature could adapt as our company’s needs and priorities evolved.
Current Desktop UI:
Future Desktop UI (early concept):
Want to build something cool?