Cardinal Financial
Multi-channel Mortgage Company
UX Product Designer
with 2 Product Owners, 1 Project Manager, and CEO
Nov 2023 - Feb 2024
Overview
Cardinal Financial is a multi-channel mortgage lender serving both retail customers applying directly and mortgage brokers who originate loans on their clients' behalf. The company's proprietary loan origination software, Octane, handles the end-to-end lending workflow for both channels.
As part of a broader initiative to build a unified design system and introduce white-labeling capabilities for broker partners, I was asked to redesign the retail-facing mortgage application — the self-service onboarding flow that prospective borrowers use to begin a loan request. The existing application had low completion rates relative to competitors and was generating operational friction for the internal loan officers and underwriters who handled submissions downstream.
Gathering Requirements
Before starting any design, I needed and wanted to understand the constraints that would affect the users and business through the product.
In early stakeholder meetings I asked four questions that proved foundational:
• What regulations govern what we can collect and when?
• What data does the application need to capture to connect properly to the data lake and loan origination system?
• Who are the competitors we should benchmark against?
• What does success look like for this project? Is the goal more leads captured, or more applications fully completed?
The regulatory question surfaced the most consequential constraint of the entire project. I was pointed toward Regulation Z and the TRID rules — federal requirements that obligate a lender to issue a Loan Estimate within three business days of receiving a completed application. "Completed" is a defined term under TRID: once six specific pieces of information are collected, the clock starts. This meant that the structure of the application form wasn't just a UX decision — it was a compliance trigger. Capturing data too much too early would create operational burden for the business.
Competitors' customers have more preference in Self-serivce
User and Competitor Research
With the business and regulatory context established, I turned to user and market research. The company had commissioned a comprehensive survey of its customer base, which I synthesized with a focus on the application experience. Three findings stood out:
Loan officers were actively steering customers toward email conversations instead of the web application, suggesting low confidence in the digital tool. Web application usage was measurably lower than competitors. And customer satisfaction scores for the web application were inconsistent — higher among users who completed it, but those completers were a small fraction of starters.
I worked with subject matter experts in the operations team to clear out my assumptions based on these findings. Two things became clear: loan officers and underwriters needed cases to move quickly, and the existing web application experience was creating enough friction that cases stalled. Meanwhile, some customers were fully capable of completing a detailed self-service application, but not all were. The current design treated every user the same regardless of their comfort level or complexity based on their loan scenario.
I audited five competing mortgage applications, mapping each step of their flows. Two distinct approaches emerged: some captured all data upfront before showing anything, while others brought a dashboard view after collecting basic loan information. Both approaches, shared a critical part, both did not risk completing a "defined application" and triggering the three-day loan estimate requirement. However, the existing product we were providing to customers triggered it. This was a significant finding that directly shaped the solution.
Two different approaches from competitors
Solution and Phased Approach
I presented findings and three potential solution directions to the product owners and CEO, framed by cost and complexity:
A lightweight option showed visual updates paired with targeted usability improvements — addressed the most immediate friction with low development cost.
A medium-complexity option introduced a dashboard view tied to the application process, giving users better orientation during completion.
A more ambitious option allowed users to access the dashboard earlier in the process, before full application completion — more aligned with how capable self-service users wanted to work, but requiring the most build investment including data handling in the back-end.
All three options shared a critical finding from the early stage: rather than collecting exact values for certain fields, the application would collect estimated values for items that would trigger TRID if confirmed. This kept the company on the right side of regulation while still capturing enough information to move cases forward.
The product team decided to pursue all three options in sequence. We structured the work into three phases: first, update the application flow and initial dashboard; second, deepen the dashboard functionality; third, build the new early-access dashboard experience as a distinct product.
Slides from presentation, highlighting regulations and our product's position
Design
Separate paths for purchase and refinance.
A mortgage application for a home purchase and one for a refinance share significant overlap, but require meaningfully different information. By asking users to identify their intent at the start, I was able to eliminate irrelevant fields entirely for each path — reducing perceived length and avoiding questions that don't apply.
Grouping related information.
A mortgage application for a home purchase and one for a refinance share significant overlap, but require meaningfully different information. By asking users to identify their intent at the start, I was able to eliminate irrelevant fields entirely for each path — reducing perceived length and avoiding questions that don't apply.
Reducing memory burden through automation.
I introduced autocomplete for property addresses and bank information — fields where users were expected to recall precise details they often didn't have on hand. I added automatic calculations where values could be derived from information already entered from the prior sections only asking additional information. Each section ends with a review screen, giving users a checkpoint to verify their input before moving forward.
Translating complex terms into plain speech.
Mortgage applications carry a heavy regulatory vocabulary that creates anxiety and distrust in users who aren't familiar with it. I rewrote field labels, section headers, and added helper text throughout the flow — focusing not just on what information was being requested, but why it was needed and how it would be used. The goal was to make users feel informed rather than interrogated.
