Case Study 01 · 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, instead of stitching exceptions across separate spreadsheets. Built from deep research with three client orgs, now live with the first cohort.

Launched · 2026 Enterprise Software Research-led Mortgage Servicing 0 to 1

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

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

Weekly time saved per analyst

early data; baseline was status follow-ups + parallel reconciliation sheets

Role

Lead Product Designerresearch, IA, interaction, visual

Team

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

Timeline

6 monthsdiscovery through launch, 2026

Tools

Figma · Figma Make · Claude Design · Copilotdesign, prototyping, and AI-assisted build

A note on confidentiality

To respect Onity Group's confidentiality, I've changed the visual treatment, screen names, and workflow details shown here. I chose not to password-gate this case study, since gates only add friction for the people I want to reach; instead I recreated the screens to keep the work open and compliant. The approach, decisions, and outcomes are intact and mine. For the real product and a deeper walkthrough, reach out.

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 users found release status unaided in testing. All three client orgs are now live on the first release of secure submission plus reliable tracking. Early data shows about six hours saved per analyst each week, measured against the old follow-up and reconciliation routine.

The call I'd defend

I shipped bulk upload as a hard dependency, knowing phase two would have to unwind it.

Bulk Purchase-Advice upload mirrored the team's current mental model, so it got the first cohort live fast. The trade-off I accepted: phase two has to reduce that dependency by collecting the exact fields directly in the form. If I ran it again, I'd hold the dependency behind a feature flag from week one, so the phase-two pivot is a toggle instead of a migration. Full reasoning in the retrospective below.

Problem area

Three clients, three ways of preparing a release.

Every client prepares releases its own way, and the receiving team absorbs the variation by hand. Kickbacks surfaced about three days late, exceptions had no owner or SLA, and reconciliation was rebuilt across separate systems. The goal was to catch the errors at submission and give every package one record the whole team could trust.

Submissions arrive in different shapes

Encompass, custom LOS exports, aggregator matrices: every client submits its own way, with no shared validation layer, so formatting issues surface downstream.

Exceptions handled by escalation, not workflow

Kickbacks, MERS updates, missing dates, investor delays all become email threads. No SLA, no owner, no audit trail.

Reconciliation reconstructed by hand

Manifests, escrow returns, and unfunding adjustments arrive across separate systems. Accounting cross-references by hand.

"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

Interview synthesis board from nine walkthroughs across three client orgs, with paraphrased quotes tagged by theme and clustered into variation at the door, exceptions need a lane, and reconciliation ties to nothing

The tagging board behind the structure: 9 walkthroughs, 3 orgs, 3 themes. Recreated; quotes paraphrased for NDA.

Solution

One structured pipeline that holds the platform's variation.

A release record that handles how each client prepares its data, different LOS systems, different reports, different investor mixes, and gives the receiving team one shared structure downstream.

"Submission is better. Tracking is still the problem."

Patrick H. · Client Operations, Mortgage Servicing Partner

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

Validation moved to the door

Clients fix field-level errors in plain language at upload, a wrong report version, a missing date, a mismatched investor code, instead of finding out three days later through a forwarded email.

Validation · Error Prevention

Bulk upload screen with field-level validation, inline error checks, PA matching, saved mapping, and auto-detected loan numbers

Bulk upload mapping step, shown after a clean file is accepted and ready for submission

A receipt and a record, on accept

The moment a submission is accepted, a release record with its own ID, owner, and starting status appears on the client's dashboard. The "did you get it?" emails stop.

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

The risky loans rise to the top

Aging records, SLA breaches, and "waiting on investor" states sit above everything else, so the morning triage is a glance, not 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

Every milestone, timestamped on the record

Each release shows its milestones with timestamps and a visible "waiting on investor" state, and every hold, fix, and escalation lives in 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

One source of truth after release

Escrow returns, manifests, and unfundings tie back to the release record with amounts, dates, and references, so accounting and ops stop trading detective tickets.

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 launched to a first cohort of three client orgs, scoped to secure submission plus reliable status tracking. Before launch, I pressure-tested the design in prototype walkthroughs with release analysts and client operations leads across those orgs. The signal was strong, and early data since launch backs it up.

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 live on the first release

All three client orgs are now live on secure submission plus pipeline status, replacing the spreadsheet-and-email workflow they ran before.

Post-launch

What I'm watching now it's live.

Now the first cohort is live, I'm watching three signals to confirm the portal is doing its job, and to surface where phase two should focus.

Drop in inbound status emails

I'm tracking 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'm measuring how many formatting issues get flagged during upload vs. downstream. A higher catch-rate means less rework and fewer kickbacks.

Reconciliation cycle time

I'm tracking 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 didn't work: shipping bulk PA upload as a hard dependency. It mirrored today's mental model, but phase two now has to unwind it
What I'd do differently: hold it behind a feature flag from week one, so the phase-two pivot is a toggle instead of a migration

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