Case Study 02 · Loan Deboarding Portal · Onity Group

I designed one release pipeline that handles how each client prepares its data.

A submission and tracking portal so analysts can validate, reconcile, and ship a loan release from a single record. Validation moves to the door, exceptions get a defined lane, and reconciliation finally ties back to the release record. Informed by deep research with three representative client orgs.

In development · 2026 Enterprise SaaS Research-led Mortgage Servicing 0 to 1

1 record

Per submission

documents, status, exceptions, reconciliation all stitched to one release

9/9

Prototype users found release status unaided

across walkthroughs with three representative client orgs

~6 hrs

Projected weekly time saved per analyst

interview baseline: status follow-ups + parallel reconciliation sheets

Loan Deboarding Portal Release Dashboard showing 5 active submissions with status chips, SLA indicators, and aging signals

A release record, milestone timeline with per-loan progress at every stage

Role

Lead Product Designerresearch, IA, interaction, visual

Team

Onity Group1 PM, 3 engineers, 1 designer (me)

Timeline

6 monthsdiscovery through MVP build, 2026

Tools

Figma · FigJam · Dovetailprototype walkthroughs with 3 client orgs

Note: names, workflow details, and interfaces have been modified to maintain confidentiality.

Snapshot

The short version.

If you only read three paragraphs, read these. Problem, change, and results in about a minute.

Problem

Mortgage clients ship loan releases to the servicing team in many different shapes. The receiving team took that variation as escalations, formatting kickbacks surfaced three days late, and accounting reconstructed reconciliation by hand across separate systems with no shared record.

Change

I designed one release pipeline that catches errors at submission, gives exceptions a defined lane with owner and SLA, and ties every package to a single release record. The receiving team gets one shared structure, regardless of upstream variation.

Results

9 of 9 prototype users found release status unaided. All three client orgs aligned on the MVP scope of secure submission plus reliable tracking. Projected weekly time saved per analyst is about six hours, validated against current follow-up and reconciliation patterns.

Problem area

What's missing isn't visibility, it's structure.

Mortgage clients needed to ship loan releases to the servicing team, then reconcile what happened after funds moved. But each client prepared packages in its own systems and formats, so the receiving team took on that variation as escalations and side conversations. Formatting kickbacks took roughly three days to surface, exceptions had no SLA or audit trail, and accounting reconstructed reconciliation by hand across separate systems. The goal: catch errors at the door, give exceptions a structured lane, and build a single release record that handles upstream variation downstream.

🧩

Submissions arrive in different shapes

Even within the three orgs we interviewed, the patterns varied widely, Encompass plus an Access database for one, a custom LOS report for another, an aggregator matrix for a third. Across the rest of the platform's clients, that variation only widens. There's no shared validation layer, so formatting issues are caught downstream, not at the door.

⚠️

Exceptions handled by escalation, not workflow

Formatting kickbacks, MERS updates, missing scheduled dates, and investor approval delays all turn into email threads routed through a single escalation contact. There's no structured exception lane, no SLA, no owner, no audit trail.

📊

Reconciliation reconstructed by hand

After release, manifests, escrow returns, and unfunding adjustments arrive across separate systems. Accounting teams cross-reference by hand because nothing ties post-release activity back to the release record.

"This should work like a workflow or ticketing system. One record per submission, with assignment and history."

Client Ops Lead · Investor Servicing Group

"Email is risky. We want secure upload and a dashboard, not a chain of forwards."

Director of Client Operations · Mortgage Lender

A clear theme surfaced from the synthesis: clients didn't just want notifications, they wanted ownership of the pipeline. They wanted to see where each loan was, who held it, and what, if anything, was blocking it. They wanted email to step back and become a fallback, not the system of record.

Design goals

What I aimed to achieve.

Three goals to fix the broken state: catch errors at the door instead of downstream, give exceptions a defined workflow with ownership and SLAs, and design a release record that takes each client's upstream shape and produces one shared structure for the receiving team.

Goal 01

Move validation upstream

Catch formatting issues, missing fields, and duplicates at the moment of submission, not three days later, downstream of the receiving team. The sender should see the error first.

Goal 02

Give exceptions a workflow

Replace escalation-by-email with a structured exception lane: type, owner, SLA, resolution log. Make exceptions a first-class state, not a side conversation.

Goal 03

Standardize client variation in one record

Design a release record that takes each client's upstream shape and presents one shared structure downstream, so the receiving team isn't doing manual reconciliation across many different operational realities.

A confirmed submission

Every package gets a receipt and a record.

Today, clients send Excel plus Purchase Advices to a shared inbox and wait. I designed the submission flow so that within seconds of upload, clients see what was accepted, what needs fixing, and the record ID created on the receiving side.

"Email is risky. We want secure upload and a dashboard, not a chain of forwards."

Director of Client Operations · Mortgage Lender

Bulk upload with inline validation

Why: Formatting kickbacks were one of the top sources of rework, wrong report version, missing date, mismatched investor codes. I moved validation to the front of the workflow so common mistakes get flagged the moment a file is uploaded.

Clients see field-level errors in plain language, fix them in place, and submit cleanly the first time, instead of finding out three days later through a forwarded email.

Validation · Error Prevention

Bulk upload screen with field-level validation, showing the release package upload with inline error messages on invalid rows

Bulk upload validation second view, showing the mapping step after a clean file is accepted and ready for submission

Acceptance receipt and release record

Why: Without a confirmation, clients didn't know if their package was received, queued, or stuck in spam. I made the system create a release record with a unique ID the moment a submission is accepted.

Every accepted submission shows up immediately on the client's dashboard with a record ID, owner, and starting status, making "Did you get it?" emails unnecessary.

System Status · Confirmation

Acceptance receipt showing a new release record with release ID, status, assigned to, submitted timestamp, milestone tracker, and the attached release file

🚨 MVP scoping decision

Bulk PA upload was prioritized for launch to mirror today's mental model. Phase two reduces PA dependency by collecting the exact fields the receiving team needs directly inside the form, documents become required only for audit and exceptions.

A tracked pipeline

One record, every milestone, no inbox digging.

Once a release record exists, clients see it move. The dashboard surfaces aging up top; each record opens to a full timeline plus reconciliation.

"This should work like a workflow or ticketing system. One record per submission, with assignment and history."

Client Ops Lead · Investor Servicing Group

Pipeline dashboard with aging

Why: Clients told me they didn't just want a list, they wanted to know which loans were at risk. So the dashboard surfaces aging records, SLA breaches, and "waiting on investor" states up top, before anything else.

A release analyst can land on the dashboard in the morning, see the three loans aging out, and know exactly where to spend the next thirty minutes, instead of triaging a 200-message inbox.

Visual Hierarchy · Aging Signals

Release Dashboard with Total Submissions, At Risk, In Progress, and Released stat cards, plus a filterable table of releases with status chips and SLA indicators

Live milestone timeline per release

Why: Status today is reconstructed from email threads and reports. I built a timeline that shows each milestone, Received, Tagged, Goodbye letter, Scheduled, Released, with timestamps and a visible "waiting on investor" state when the ball is in someone else's court.

When a release is delayed, clients can see exactly where it's sitting and why. Exception handling, holds, fixes, escalations, happens inside the record with a full audit trail.

Timeline · Blockers · Audit Trail

Release record detail view showing a milestone timeline with Received, Assigned, Tagged, Goodbye Letter Sent, Scheduled Release, and Reconciliation states, plus a loan-level view at the bottom

Post-release reconciliation snapshot

Why: Accounting teams kept asking ops "what is this money?" because escrow returns, manifests, and unfundings showed up days after the release with no clear context. I added a reconciliation view that ties amounts, dates, and references back to each release record.

Accounting and ops finally share one source of truth for what happened after release, fewer detective tickets, faster month-end, and a clean handoff between teams.

Reconciliation · Accounting Handoff

Post-release reconciliation snapshot tied to release REL-2026-0044, showing UPB at release, funds returned, loans count, released-on date, milestone timeline tabs, and a cash flow summary

Shipped screens

Every surface in the release flow.

Six screens span the full release flow, from a clean upload at the door to reconciliation handed cleanly to accounting. Use the arrows to step through; click any image to view it at native resolution.

1 Release dashboard, every submission in one live view

Release Dashboard with stat cards, search and filters, and a filterable table of releases with status chips and SLA indicators

2 Bulk upload, validation at the door

Bulk upload screen with inline validation, showing field-level errors caught at submission

3 Bulk upload, mapping confirmed

Bulk upload mapping step, second slide of the validation flow showing a clean file accepted and ready to submit

4 Acceptance receipt and new release record

Acceptance receipt screen showing a new release record with release ID, status, owner, and the attached file

5 Milestone timeline per release

Release record detail showing the milestone timeline with Received, Assigned, Tagged, Goodbye Letter Sent, Scheduled, and Reconciliation states plus the loan-level view

6 Post-release reconciliation snapshot

Post-release reconciliation snapshot tied to release REL-2026-0044, showing UPB at release, funds returned, milestone timeline, and a cash flow summary

Validation

Did it work?

The portal is in early build, scoped down to a focused MVP: secure submission plus reliable status tracking. To pressure-test the design before development, I ran prototype walkthroughs with release analysts and client operations leads from three client organizations. The signal was strong.

9/9

Participants found their submission

Every interviewee located a tracked release on the dashboard within seconds, no instructions needed.

100%

Validation errors fixed inline

In the prototype, every formatting error was caught and corrected during submission instead of post-send.

3/3

Client orgs aligned on MVP scope

All three client groups confirmed that secure submission plus pipeline status would replace their current spreadsheet-and-email workflow.

Post-launch

What I'll monitor after launch.

Once the MVP is live, I'll watch for three signals to confirm the portal is doing its job, and to surface where phase two should focus.

📩

Drop in inbound status emails

I'll track the volume of "did you get it?" and "where are we?" emails. A drop signals clients trust the portal as the source of truth.

⚠️

Submission errors caught at the door

I'll measure how many formatting issues get flagged during upload vs. downstream. Higher catch-rate means less rework and fewer kickbacks.

📊

Reconciliation cycle time

I'll track how long it takes accounting to close out a release after funds move. A shorter cycle confirms the reconciliation snapshot is doing its job.

Retrospective

What I took from this.

Two layers of impact that don't show up in the metrics. The work that shaped how I designed it, and the patterns the team kept using after I shipped.

Impact on me

Absorbing variation is a design problem, not an engineering one.

Three client orgs prepared releases three different ways, and the temptation was to ship three workflows. Treating that variation as a layer above one shared record (rather than three parallel pipelines) is what made the MVP feasible. The discipline came from interview tagging, not whiteboarding.

9 prototype walkthroughs across three representative client orgs
2 rounds of cross-team review before MVP scope was locked
What I'd do differently: hold the bulk PA upload behind a feature flag from week one to make the phase-two pivot cleaner

Impact on process

Patterns the platform team kept reusing.

This was the first end-to-end release surface on Onity's platform, so the components and the discovery artifacts both became templates. The next two projects on the roadmap pulled from this work instead of starting over.

Inline validation pattern adopted for every upload surface on the platform
Exception-lane workflow (type, owner, SLA, resolution log) reused across product
3-org interview synthesis template carried into the Real-Time Inquiry research