Level: Down Payment Verification

Context and stakes: Why this mattered

Down payment verification is one of the most fragile steps in the mortgage process. Borrowers must gather months of financial documents across multiple accounts, while brokers depend on those documents being complete, accurate, and trusted.

Before Level:

• “Getting bank statements are painful”
• “Lots of back and forth with getting bank statements”
• “Down payment is difficult, a nightmare to track, as amounts may be in various accounts”

The opportunity was clear:

Reduce friction in the down payment verification process without compromising trust.

Ownership and action: What I took on

I led design for Level from concept through launch, working across:

• Product
• Engineering
• Customer Success
• Executive stakeholders

My responsibility was not just to design flows, but to:

• Balance speed to market against trust and reliability
• Anticipate failure modes in third-party integrations
• Design for two distinct user mental models (brokers and borrowers)

I also played a role in evaluating the long-term viability of the product, not just its initial success.

Strategic framing: The real design problem

The problem wasn’t “how do we collect bank statements faster?” It was:

How do we help users trust that a complex, opaque process has completed correctly?

Key challenges:

• Borrowers needed reassurance that sensitive data was handled safely
• Brokers needed confidence that documents were complete and usable
• Any ambiguity created hesitation and rework

Research and system design

We conducted interviews with mortgage brokers to understand:

• Where verification broke down
• How trust was established or lost
• What failure looked like in real workflows

Insights included:

• Brokers: Need to educate borrowers on how to correctly retrieve and submit documentation for down payment verification
• Brokers: Often receive borrower documents that are inconsistent, incorrectly formatted or oriented, or insufficient for verification (missing bank account numbers or the client’s name)
• Brokers: Face the risk of losing borrowers to their bank when clients visit branches to retrieve statements
• Borrowers: Must log in to their online banking platform or visit a bank branch to obtain three months of statements for all accounts, then forward the documents to the broker
• Errors and missing information delayed approvals and increased risk

Design workshops helped the team:

• Map broker and borrower journeys
• Define success and failure criteria
• Identify risk points early

Strategic decisions and tradeoffs

Decisions I made:

• Made system state explicit to prevent silent failure in a fragile third-party bank connection (clear success, partial success, and failure states)
• Prioritized trust over perceived speed, using deliberate loading and confirmation states in a high-stakes financial workflow
• Friendly, plain-language notifications between Level and borrowers so every verification request felt clear, human, and intentional, not alarming

Tradeoffs we made:

• Integrated a third-party service to meet timeline goals
• Accepted reduced control in exchange for faster validation
• Took on reliability risk knowingly and monitored it closely

We made informed bets, not perfect ones.

Broker facing screens: mobile

Borrower facing screens: responsive web

Outcomes and leverage: What changed

What worked:

• Exceeded early adoption targets
• Received strong qualitative feedback from brokers
• Reduced manual document handling in successful cases

As seen with:

What didn’t work:

Third-party reliability eroded trust:

Risk: To accelerate time-to-market, we relied on a third-party mobile integration to retrieve bank statements. The connection was unstable and slow.

What this caused:

• Inconsistent outcomes (all, some, or no documents retrieved)
• Timeouts during multi-account retrieval
• Reduced confidence from both brokers and borrowers

As seen with evidence:

“Tested it out on myself as I have accounts at a variety of institutions. Problems I had: for multiple accounts it took some time and was susceptible to timing out… Sometimes deposit account and credit card downloaded but investment account did not… I don’t want to provide a technology solution to customers that is supposed to simplify the process and reduce effort, only to have it be a frustrating experience that isn’t reliable.”

Partial success states created confusion:

What we didn’t account for: The system treated partial document retrieval as a technical edge case, but users experienced it as ambiguity: Is this usable? Do I need to retry? What’s missing?

Impact:

• Brokers couldn’t confidently proceed with applications
• Borrowers questioned whether they had done something wrong

As seen with evidence:

“I’ve used it and had either no docs come through, all come through or only half of the documents come through. It’s a great idea but hoping they are able to work out all of the kinks.”

Reflection

This project fundamentally shaped how I approach trust-sensitive systems.

My core takeaway:

In systems that handle critical data, reliability and clarity are non-negotiable and no amount of UX polish can compensate for instability.

Today, I apply this lens to:

• Configuration and permission-based workflows
• Platform decisions that affect user trust

Marketing and branding

Iterations that never made it

The primary focus for these iterations were to:

• Reduce distraction
• Focus on content
• Emphasize interactive elements