Designing LowerOS so borrowers never have to repeat themselves

The Problem

Getting a mortgage means answering a lot of questions — about income, assets, property, credit, and goals. At Lower, borrowers answered those questions more than once.

A borrower would start in the consumer funnel on Lower.com, filling out a short application. That data landed in a CRM. When a Loan Officer picked up the lead and called, they couldn't see a complete picture of what the borrower had already shared — so they re-asked. When the loan moved into the legacy loan origination system, fidelity was lost again. Every system hop created another opportunity for the borrower to hear a question they'd already answered.

Repeated questions erode trust at the exact moment a borrower is deciding whether to commit to the largest financial transaction of their life. They slow the first call and they produce incomplete applications that generate downstream fallout for processing.

The core problem: Loan Officers had no good way to access the information a borrower had already provided, so borrowers answered the same questions multiple times as they moved through the system.

“LowerOS (Lower’s bet on proprietary software) was the opportunity to fix this structurally rather than patch it.”

Learning the Domain First

As the only designer on this work, I couldn't design from the screen inward. I had to understand the whole machine: how a lead becomes a loan, where soft and hard credit pulls happen, when pricing runs, how automated underwriting fits in, what disclosures require, and where the handoffs between systems actually break.

I built that fluency deliberately:

Shadowing and working sessions with Loan Officers and sales leaders to understand how the first call really works — what they ask, in what order, and what they scribble in notes because the system has no place for it.
Discovery sessions with operations teams (fees, pricing, processing) to map pain points beyond the application itself.
Studying call transcripts and demos to hear the borrower conversation as it actually happens, not as the org chart imagines it.

A framing emerged from this research that shaped everything after the application is the borrower's story. Property, income, assets, liabilities, and goals are inputs to a story the Loan Officer needs to read quickly so they can make a strong recommendation on the very first call. The job of the system is to collect that story once, keep it intact, and put it in front of whoever needs it next.

A second insight came from borrower-side research: long questionnaires give borrowers no value until the very end. Breaking the application into modules creates moments to give something back and gives the loan team flexibility in how they collect the rest.

Mapping the Ecosystem

Before designing screens, I mapped the territory. I created a set of end-to-end workflow maps covering three states. These maps became the shared reference for product, engineering, and sales leadership.

They surfaced the outstanding questions no one owned and put them in one place instead of scattered across meetings.

When does a LowerOS loan get created?
When is the borrower's account created?
Which portal does the borrower log into?

The most consequential piece was question-level field mapping. I mapped every question in the consumer funnel against every field in LowerOS to find the overlaps, the gaps, and the questions that didn't translate cleanly. This mapping is the actual mechanism behind "ask once" . It also de-risked the integration: the team had already learned that LowerOS didn't always behave the way the funnel data assumed.

This work generated a prioritized backlog of integration line items. Automatic borrower account creation, application export, dashboard refinement, consolidated borrower communications that engineering scoped directly into delivery waves.

Ecosystem Maps

Current state: Consumer funnel → CRM → Legacy LOS

Initial launch: Consumer funnel → LowerOS, with the legacy system still handling post-disclosure work

Future state: The full journey inside LowerOS

Designing the Flows

With the ecosystem mapped, I designed the borrower application flows around two service models Lower actually operates:

Fully digital self-service: a borrower moves from an ad to a mini-app to the full application, selects a loan, and uploads documents with limited LO support.
Digital with Loan Officer support: the borrower starts digitally, then works with an LO who answers questions, advises on loan selection, and guides them through submission.

Designing both side by side forced an important discipline: the data model had to be identical regardless of who was driving. Whether a borrower typed an answer or told it to their LO on a call, it landed in the same place — so no one downstream ever had to ask again.

To prove the continuity, I built a fully filled-out application prototype demonstrating exactly what carries through from the consumer funnel into LowerOS, and used it to run design reviews with engineering and product to validate the workflow end to end. The flow finished with real borrower value: completing the application generates a pre-approval letter, available right on the borrower dashboard.

The Guided "One Call" Application

The centerpiece of the LO-side work was the guided application. This live-call tool that allows a Loan Officer complete a full application in one structured, natural conversation.

What makes it work:

Pre-filled with everything the borrower already provided. Data from the consumer funnel and CRM loads before the call starts. The LO confirms rather than re-asks. This is the field-mapping work paying off.
Ordered like a conversation, not like a database. Sections follow how a loan officer actually talk to borrowers, with a stepper so they can move non-linearly when the conversation jumps.
Credit in one place. Soft credit from the funnel carries in; tradelines can be reviewed and adjusted live with the borrower which eliminated duplicate credit pulls and imports.
Edge cases designed, not discovered. Frozen credit scores, multiple jobs, self-employment, commission and bonus income, inline tradeline editing, monthly payment visualization with pricing implications.

The target: capture 90%+ of required information in a single call, with a clear definition of what could be deferred. Early feedback from loan teams was strongly positive on reduced friction and better borrower conversations.

I owned this end to end. Prototype, specs, edge cases, engineering refinement, and stakeholder confirmation. Including walking sales leadership through the designs and cycling their feedback back into deliverables.

Guided Application Exploration

Low-fidelity exploration.

This phase also produced one of the experience's signature transparency patterns: a persistent "Why are we asking?" explainer attached to property and financial questions, born from the research insight that borrowers disengage when a long questionnaire gives nothing back.

Initial assumptions that were being tested is having a ‘Primary Application’ for a borrower with follow-up modules to be completed after submitting and talking to a loan officer.

Prototyping

Validating the conversation structure with stakeholders before investing in visual design. Testing structure at low cost is what made the high-fidelity phase an execution exercise instead of a debate.

Learning from Low-Fidelity

The Primary Module captures just enough for the system to pull credit, run pricing, and set the LO up for a successful initial consult. Follow-up modules — Income, Property, Additional Details, Military, Liabilities, Documents — each unlock the next phase of the loan (initial disclosures, the 1003, the loan estimate, underwriting). Borrowers give a little, get value back, and the loan team gains flexibility in how they collect the rest. Killing the first version was the most valuable design decision in the project.

High Fidelity Iteration

Building It to Scale

A sole designer supporting an entire lending platform can't hand-craft every screen. I invested heavily in systems:

A shared component library used across the platform.
Adaptable interaction patterns searchable field groups, filters, drawers.
A design-to-configuration translation guide for engineering, documenting how to translate Figma patterns (expandable cards, repeating blocks, conditional sections) into the platform's config-based flow system. This cut design–engineering back-and-forth and stopped bespoke components from creeping in where existing patterns worked.

The guided experience shipped first as an alpha for conventional refinance, then expanded to the next three highest-volume loan products — FHA, VA, and HELOC — with program-specific eligibility questions layered onto the same shared conditional-flow architecture. Designing the architecture for reuse is what made that expansion a design exercise rather than a rebuild.

Working Across the Organization

None of this shipped because of pixels. It shipped because of relationships:

Product: I partnered with PMs on technical and design requirements assisting with the build out of user stories and PRDs.
Engineering: I helped resolved ambiguity before code was written. In one pricing workflow review, an engineering leader noted the concerns I raised "would not have been uncovered until a user hit them in a live loan." When feasibility questions came up, I worked through them live and returned an updated prototype the same day.
Sales: I ran demos with sales leadership, folded their feedback into the designs, and used a pilot loan team as early validators.
Marketing: I acted as the bridge between brand and product by aligning the consumer funnel's patterns with LowerOS early to prevent long-term divergence, and governing a unified design language across the marketing site, the borrower funnel, and the lending platform.

Over two years I became the recognized point of contact for the borrower and loan officer facing platform the institutional memory for what had been demoed, what had been decided, and why.

AI as a Force Multiplier

Being the only designer on a platform this large meant every hour of manual work had a real cost. Midway through the project I made AI a deliberate part of the process — not as a novelty, but in three phases: learn it, operationalize it, then govern it.

Learn

I started with formal training (Nielsen Norman Group's AI in Design Workflows) and translated it into an executive summary for the organization with four concrete commitments: AI-assisted rapid prototyping, design-system analysis, research synthesis, and design-critique assistance. The framing I set then held for everything after. AI accelerates exploration and ideation, but human judgment owns reliability, taste, and strategic alignment. Prompting works like directing a junior designer: iterative, and only as good as the context you provide.

Operationalize

AI moved from experiment to infrastructure in the day-to-day delivery process:

Research synthesis at scale. Clustering pain points from borrower call transcripts and loan-officer feedback, and condensing competitive analysis into stakeholder-ready insights — work that previously consumed the hours I needed for design itself.
Grounded exploration. Conversational AI prototyping (anchored to the existing component library, not free-styled) let me generate screen variations and copy for the LO experience quickly, react, and discard cheaply. When engineering raised feasibility concerns on a flow, I worked through them live in a 30-minute call and returned an updated prototype the same day.
AI-assisted handoff. I redesigned the design-to-engineering handoff and piloted it on the guided experience: per-ticket design pages linked from the ticket, Figma Dev Mode for specs, an AI annotation assistant to eliminate manual page setup, and Code Connect experiments mapping design components one-to-one to coded components. The pilot directly targeted the three root causes of handoff friction from the alpha: unfamiliar files, undocumented states, and design/ticket drift.
Writing for machine readers. The design-to-config translation guide was written for two audiences — engineers and AI coding agents — mapping design patterns (expandable cards, repeating blocks, conditional sections) to the platform's existing config shapes so that generated code lands on real components instead of bespoke one-offs.

Govern

As AI design tools multiplied, I authored the organization's rules-of-engagement playbook: which generator to use for which job, the design system as the quality gate separating "near-shippable" from "throwaway mockup," green-light lanes where PMs can explore without a designer, and hard red lines — novel flows, net-new patterns, and anything shipping to borrowers on regulated mortgage surfaces requires a designer. The honest boundary-setting mattered as much as the advocacy: AI-generated design stayed exploration-only until it could be grounded in our system, and I said so plainly to leadership.

The result: one designer kept pace with an engineering organization at a 1:20 designer-to-engineer ratio — not by working more hours, but by automating the repeatable and reserving judgment for the novel.

Outcomes

Borrowers answer questions once. The guided application pre-fills everything previously collected; credit lives in one place, ending duplicate pulls.
One call instead of many. The guided workflow targets 90%+ information capture on the first call, with strong positive feedback from loan teams on reduced friction.
From alpha to three new loan products. The conditional-flow architecture extended from conventional refinance to FHA, VA, and HELOC without redesigning the system.
Engineering velocity. Shared components meant new forms shipped with zero component rebuild; the design-to-config guide reduced implementation back-and-forth.
A shared map of the business. The workflow documentation became the reference product, engineering, and sales leadership used to sequence the platform roadmap.

What I Learned

Domain depth is a design tool. The most valuable design artifact in this project was a field mapping spreadsheet-style audit, not a screen. Understanding mortgage mechanics — credit, pricing, AUS, disclosures — is what let me design a system where information flows instead of evaporating.

Design the data continuity, then the screens. "Don't make the borrower repeat themselves" is a system problem that needed to be solved at scale.

When you're the only designer, systems are survival. Component libraries, translation guides, and documented decisions are how one designer supports an entire platform — and how the work outlives any single project.