A 6-step loan submission portal for real estate investment brokers
Real estate investment brokers were submitting loans through a fragmented process: emailing documents piecemeal, calling to check status, and losing track of which deals needed what. I designed the 0→1 portal that replaced it with a structured submission workflow and full pipeline visibility.
- Role
- Senior Product Designer
- Team
- 1 Designer · 2 PMs · 4 Devs · 1 QA · 1 BA
- Timeline
- 8 months
- Platform
- Web · Broker Portal
- Outcome
- 6-step portal replaced fragmented broker email submission process
What brokers were dealing with
Real estate investment lenders don't deal with retail borrowers directly. They work through mortgage brokers. A broker sources the deal, assesses whether it meets the lender's criteria, and packages the loan file for submission. If the loan closes, the broker earns a commission. Speed matters: the faster a broker can submit a clean file and track its status, the more deals they can close in a quarter.
Before this portal, brokers managed their submissions across email threads, shared drives, phone calls, and spreadsheets. Documents arrived piecemeal. Loan officers spent a significant portion of each day chasing missing information and answering "what's the status on my deal?" calls, information the broker should have been able to access without picking up the phone.
No single place. No structure. Incomplete submissions as the norm.
Brokers had no single place to manage their loan pipeline. Documents arrived via email with no structure. Loan officers spent significant time chasing missing information and answering status questions that should have been self-serve. Incomplete submissions were the norm, not the exception.
The business needed a portal that enforced completeness before submission, not after. And brokers needed to see the state of every active deal without making a phone call.
End-to-end, from brief to handoff
I was the solo designer across the full 8 months, from the first stakeholder workshop through developer handoff. The team included 2 PMs who owned the product roadmap and broker relationships, a BA who mapped the existing ops workflow before I began designing against it, 4 engineers who were involved from week three, and 1 QA. Developer input from week three shaped several key decisions about how validation and document requirements were implemented.
My work covered: discovery research (shadowing loan intake, broker interviews), information architecture, all interaction design across six submission steps plus the pipeline view, prototyping, and handoff documentation.
Shadowing the process before designing it
I started by shadowing the loan intake process end to end, from the moment a broker expressed interest to the point a file reached underwriting. The gaps were structural: no checklist, no status visibility, no enforcement of required fields before submission.
Broker interviews surfaced the core tension: they wanted speed, but their incomplete submissions were creating delays on both sides. The same brokers who complained about slow turnaround were submitting files missing 30–40% of required documents. The problem wasn't attitude. It was the absence of any system that showed them what was missing before they hit send.
Four decisions that defined the portal
Brokers visit the portal most often to check deal status, but a submission form is the expected default for a portal with 'Submit' in the brief. Making the form the default would prioritise a less-frequent task.
Pipeline view as the default landing page. New submissions triggered by an explicit Create Deal action.
Why: Research confirmed that brokers check deal status far more often than they submit new deals. A pipeline-first default made the most common task require zero navigation. The Create Deal button is prominent but not the page's primary focus.
Showing all six steps as a single long form would be technically simpler and keep all fields visible. But a wall of fields was the primary complaint brokers had about the process the portal was replacing.
Progressive disclosure through six named steps, each with a clear purpose, visible progress indicator, and the ability to save and return.
Why: Breaking submission into named steps (Deal Overview, Borrower Information, Property Details, Financial Profile, Document Upload, Review and Submit) meant each screen had a single purpose. Brokers could see exactly where they were and what remained. Saving per step meant a partial file was never lost.
Showing errors only on submission is the default web form pattern. But for complex multi-step forms, a single error screen after the broker has filled six steps creates significant backtracking.
Inline validation at the field level, surfacing errors as brokers type, not on submit.
Why: This alone reduced incomplete submissions significantly in testing. Brokers could fix issues in context, as they entered data, rather than returning to fix errors after completing all steps. The cost, slightly more complex validation logic, was accepted by the engineering team early.
The internal ops system had granular loan states that were meaningful to the lending team but would create anxiety for brokers if exposed directly.
A five-state broker-facing status system: Draft → Submitted → Underwriting → Funded, with Incomplete as an error state. Color as a secondary signal, never the only one.
Why: Brokers needed to know: is my deal moving, is it stuck, do I need to do something? The five states answer those questions without exposing ops-internal granularity. Status labels, icons, and pipeline position all communicate state, with color reinforcing it, never carrying the meaning alone.
Step 5: the dynamic document checklist
The hardest design problem was the document upload step. Required documents vary by product type: DSCR loans, RTL loans, and bridge loans each have different document requirements, and the requirements shift again depending on whether the borrower is an individual or an entity.
My first version showed all possible document categories and let brokers mark them not applicable. Testing showed this created more confusion than it resolved. Brokers weren't sure which "not applicable" items were actually optional versus which ones they'd accidentally dismissed. The dynamic checklist, showing only the documents relevant to the current deal's product type and borrower structure, reduced cognitive load and eliminated the most common source of drop-off in the upload step.
Enforcement works best when it feels like guidance
The 6-step structure doesn't block brokers. It shows them the path. That framing shift, from "you can't proceed" to "here's what's next", changed how brokers responded to the flow in testing. Steps that were described as gates in internal planning became waypoints in the broker experience.
The other lasting lesson was about scope sequencing. The portal launched with pipeline tracking, deal submission, and profile management. Additional features were deferred to a later phase. Not because they weren't valuable, but because shipping a complete, polished core experience gave brokers and the ops team something to build habits around before expanding scope. Features built on top of a trusted foundation land better than features shipped alongside an untested one.