Centralising broker loan submission in a single portal
Mortgage brokers submitting real estate investment loans juggled email threads, shared drives, spreadsheets, and a third-party rate tool. None of it talked to each other. I designed the 0→1 portal that replaced it.
- Role
- Senior Product Designer
- Team
- 1 Designer · 2 PMs · 4 Devs · 1 QA · 1 BA
- Timeline
- 8 months
- Platform
- Web · Broker Portal
- Outcome
- Single portal replaced 4-tool broker submission workflow
What a broker actually does
Real estate investment lenders don't deal with retail borrowers directly. They work through mortgage brokers. A broker acts as the intermediary: they source the deal (a property purchase or refinance), assess whether it meets the lender's criteria, and package the loan file for submission. If the loan closes, the broker earns a commission.
The products in play here are non-QM loans: DSCR (Debt Service Coverage Ratio) loans for rental properties and RTL (Residential Transition Loans) for fix-and-flip projects. These aren't consumer mortgages. They move faster, have tighter underwriting windows, and require borrowers and brokers to move in coordination.
Brokers run portfolios of deals simultaneously. A productive broker manages 5–20 active loan files at any point. The speed at which they can check status, get rate indications, and respond to underwriter requests directly determines how many deals they can close in a quarter.
Four tools. No central view. Deals slipping through.
Before this portal, a broker's submission workflow looked like this: rate inquiries happened over email or phone. Applications were filled in a PDF and emailed to an ops coordinator. Documents went to a shared Google Drive folder (if the broker remembered the link). Status updates required calling or emailing the ops team. Budget calculations were done in a spreadsheet, manually. There was no way for a broker to see the current state of all their deals in one place.
The lender's ops team spent a significant portion of each day answering "what's the status on my deal?" emails and calls, information the broker could in theory access but couldn't because there was no system to surface it. The cost was real: slower turnaround, broker frustration, and deals lost to competitors who had invested in their broker experience.
What we were designing within
Brokers are not internal users
Unlike the ops tools I'd designed before, this portal would be used by external partners. Onboarding had to be self-serve. The interface couldn't assume familiarity with the lender's internal terminology.
Two loan products with different flows
DSCR and RTL loans have different underwriting criteria, required documents, and timeline expectations. The application flow had to handle both without becoming a branching maze.
Ops team owns the decision
Underwriting decisions stay on the lender side. The portal gives brokers visibility and tools. It doesn't give them control over the underwriting process. That line had to be clear in the UI.
Solo designer, phased scope
As the only designer, I had to sequence the work. Core submission and pipeline tracking came first. Rate quoting (RapidRate®) and Budget Desk shipped in phase two, three months after initial launch.
End-to-end, from brief to handoff
I joined this project at the problem-definition stage, before any wireframes existed. My work covered: stakeholder workshops with the ops team (who were the internal "customers" of the tool, fielding broker calls), research sessions with three active brokers, information architecture, all interaction design, and developer handoff documentation.
The two PMs owned the product roadmap and broker relationships. The BA mapped the existing ops workflow before I could design against it. Developers were involved from week three. Their input on what was hard to build shaped several key decisions about the Budget Desk and rate quoting features.
Five decisions that defined the portal
Brokers need to submit new deals, but they also spend most of their time monitoring existing ones. Making the application form the default landing page would prioritise submission over status, but most sessions aren't for new deals.
Pipeline view as the default landing page, with the application form triggered by a Create Deal action.
Why: Research with brokers confirmed they check deal status far more often than they submit new deals. A pipeline-first default meant the most common task (status check) required zero navigation. New submissions are less frequent but high-intent, and a dedicated action button is appropriate.
Budget Desk is a detailed cost-breakdown tool that underwriters request mid-process. It could be embedded in the application form, or live as a standalone tool, but embedding it would complicate the primary submission flow.
Budget Desk as a dedicated tool in the sidebar navigation, accessed independently from the application.
Why: Underwriting requests for budget submissions arrive after the initial file is submitted, often days later. Embedding it in the application would require brokers to navigate back to a completed form to complete a distinct task. A standalone tool matched the actual workflow: brokers visit Budget Desk specifically, when requested.
Brokers check rates frequently: before submitting a deal, when pitching a borrower, and when comparing lenders. Rate quoting could be buried inside the application form, but brokers use it independently.
RapidRate® as a first-class navigation item, available without entering a deal file.
Why: Three of three brokers interviewed said they used rate tools before deciding whether to submit a deal at all. If rate quoting required entering an application, it would create fake starts and incomplete files. Surfacing it at nav level made the tool useful at the earliest point in a broker's decision process.
The lender's internal status system had nuanced states that made sense to ops staff but would confuse brokers. Exposing all internal states would create anxiety; collapsing them too much would lose meaningful information.
A four-stage status hierarchy visible to brokers: Draft → Submitted → Underwriting → Funded (with Incomplete as an error state).
Why: Internal ops states (e.g., 'Pending Appraisal', 'Doc Review', 'Final Sign-Off') map to three visible broker states under Underwriting. Brokers don't need granular ops visibility. They need to know what action is required of them. The 'Budget Required' flag surfaces the one actionable underwriting sub-state directly in the pipeline table.
The loan application covers multiple categories: borrower info, property details, loan structure, documents, and budget. A single long form is technically simpler to build but creates a wall of fields. Section-by-section wizards can lose context across steps.
A tabbed section layout within a single application page, each section visible in a nav, completable in any order, with section-level save states.
Why: Broker research showed partial completion is the norm, not the exception. A broker may have property details but not yet have the borrower's financials. Section-level saves meant a partial file was never lost. The visible section nav let brokers jump directly to the section they had information for, rather than stepping through in sequence.
The status model I had to rebuild
My first version of the pipeline table showed broker-facing status labels that I'd mapped from the ops system: "Awaiting Appraisal", "Document Review", "Credit Decision". These were accurate. They matched exactly where the loan was in the internal process.
Brokers hated it. Testing revealed they didn't find the granularity useful; they found it anxiety-inducing. Seeing "Awaiting Appraisal" without knowing what that meant for their timeline or what action it required of them was worse than a coarser status. What brokers actually wanted: is my deal moving? Is it stuck? Do I need to do something?
The final four-stage model (Draft, Submitted, Underwriting, Funded) came directly from that feedback. The only exception is the "Budget Required" flag, which surfaces one specific actionable underwriting sub-state because it requires broker action. Everything else stays invisible until it reaches a stage change the broker needs to know about.
One place for the whole submission workflow
The portal launched with pipeline tracking, deal submission, and broker profile management. RapidRate® and Budget Desk shipped in phase two. The ops team reported a measurable drop in inbound status enquiries from brokers, the single most common reason they received calls before the portal existed.
[Outcome metrics pending: broker adoption data and NPS to follow post-launch.]
AI-assisted document review
The document upload step in the application flow is the highest point of friction. Brokers need to know which documents the lender requires, which they've already uploaded, and which are missing or need re-upload. An AI layer here could pre-read uploaded documents, flag issues before submission (e.g., expired income verification, incorrect property address), and reduce the back-and-forth between broker and ops team during underwriting.
The second opportunity is in RapidRate®: connecting the rate quote directly to deal creation, so that a broker who runs a quote and likes the rate can start a deal file pre-populated with the parameters they just entered. Right now, that bridge doesn't exist: rate quoting and deal submission are separate flows with no data handoff.