Case Study 02 · Real-Time Inquiry Portal · Onity Group

I designed a real-time portal that replaces email threads with live case visibility.

A shared, live record for every loan inquiry, where mortgage clients can track progress, message teams inline, and skip the bi-weekly status meeting. Built to stop the "where is my case?" emails and hand analysts twelve hours back every week; prototype testing backs both.

Launched · 2026 Enterprise Software Interaction Design Mortgage Servicing Research-led

Real-Time Inquiry Portal dashboard, a central hub showing every loan inquiry in one organized, live view

A central hub, every loan inquiry in one organized, live view

62%

Faster case resolution

early data, first cohort vs. the prior email baseline

6 hrs

Weekly hours back per account manager

early data; AMs had spent ~12 hrs/week chasing status by hand

Status meetings by design

the live dashboard replaces the bi-weekly call

Role

Lead Product Designerend-to-end research, IA, interaction, visual

Team

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

Timeline

5 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 had no way to track loan inquiries after submission. Updates lived in scattered email threads, and account managers burned roughly 12 hours a week chasing status by hand and running bi-weekly meetings just to stay in sync.

Change

I designed one shared workspace where every inquiry has a live record: status, threaded conversation, attached documents, and a clear resolution path. Account managers oversee their full portfolio from a filterable table; clients see exactly where each case sits.

Results

Before launch, 90% of users located case status unaided in testing and no conversations were lost. Now live with a first cohort of three client orgs, early data shows about 6 hours back per account manager each week, against a baseline of roughly 12 hours spent chasing status by hand.

Problem area

Lost in the back-and-forth.

Once an inquiry was sent, there was no shared place to see progress, share documents, or message the team. Updates lived in hundreds of email threads, and account managers burned about 12 hours a week updating spreadsheets and running bi-weekly status calls to stay in sync.

Zero visibility after creation

Once a case opens, clients can't see status or owner. So they email "just checking in."

Fragmented messaging and files

Loan documents and replies scatter across email threads. Latest version, last word, both hard to find.

Meeting-heavy status management

Account managers update spreadsheets by hand and run bi-weekly status calls to stay in sync.

"Give me the visibility to see where we sit. Show me if I'm 20% or 80% done, simple milestones or a small chart."

Ivan Camarena · Client User

"I need to see all of our open cases, not just mine, so I can cover when someone's out."

Glenda Brue · Client Administrator

Dashboard view

One screen, every case at a glance.

The entry point. Status summary cards surface aging cases at the top; the live, filterable case table replaces the bi-weekly status meeting.

"I need to see all of our open cases, not just mine, so I can cover when someone's out."

Glenda Brue · Client Administrator

Every case state, the second you log in

Aging cases surface at the top, so clients see progress at a glance instead of emailing "is this done yet?"

Visual Hierarchy · Fast Feedback

Dashboard status summary cards row showing Open Inquiries 4, With Onity 2, Waiting on you 2, and Total Cases 6 counts

One table replaces the status meeting

A filterable source of truth for every inquiry, so most of the 12 hours a week of spreadsheet updates and status calls goes away, about 6 hours back per account manager.

Data Transparency · Recognition

Live, filterable case table with inquiry ID, subject, status chips, last update, loan number, owner, created by, create date, and days columns

Case detail view

Detailed insights and interaction.

A full-page case view that puts progress, conversation, and documents in one shared history, so clients and account managers stop hunting through email threads for the latest state.

"Every case is a different email thread, finding the latest update means hoping it didn't get buried."

Synthesis · across client interviews

Progress you can read at a glance

Clients see whether a case is starting or nearly done, so they stop emailing to ask, and know when it's their turn to act.

System Status · Visual Cues

Real-time progress tracker bar showing four stages: Submitted, Assigned To, With Onity, Resolved, each with date stamps, with tabs underneath for Overview, Conversation, Documents, and Resolution and Escalation

Messages and files, kept with the case

Chat and documents live in one shared history, so nothing gets buried in an email chain and a teammate can step in cold.

Information Access · Context

Unified messaging panel showing the conversation history with Onity Support and the user, with an attached payment receipt PDF, the participants list, and a how-it-works helper card

Files view inside the same case showing the documents list, alternate slide of the unified messaging and files carousel

A clear way to close, or escalate

Clients confirm a fix or escalate to a manager, and a rating tells the team whether the outcome landed.

User Control · Feedback Loops

Resolution and Escalation tab showing Resolution Details with an Outcome dropdown, date field, closing comment, and Escalate plus Confirm and Close action buttons, next to an About Escalation help panel

Final Design

The full picture, tab by tab.

Four states of the expanded case-detail flow as a client moves through it: opening the case to see the overview, reading the conversation, attaching documents, and finally resolving or escalating. The dashboard chrome stays constant; only the inner panel changes with the active tab.

1 Overview tab, case details and timeline

Inquiry Dashboard with case 123456 expanded to the Overview tab, showing the progress tracker, the full Case Details panel (Case ID, Onity Contact, Onity Team, Created By, ETA, Days Open, Loan Number, Borrower, Contact, Description) and the Timeline panel on the right

2 Conversation tab, threaded history with attachments

Inquiry Dashboard with case 123456 expanded to the Conversation tab, showing the Onity is reviewing banner, the conversation history with Onity Support and the user, an attached PDF, the Update Budget side card and Participants list

3 Documents tab, every file attached to the case

Inquiry Dashboard with case 123456 expanded to the Documents tab, listing three PDF files (Oct_25_loan_payment_receipt, Nov_1_utility_bill_statement, Nov_5_credit_card_statement) each with Preview and Download actions

4 Resolution and Escalation tab, close or escalate the case

Inquiry Dashboard with case 123456 expanded to the Resolution and Escalation tab, showing Resolution Details with an Outcome dropdown, Date, Closing comment, plus Escalate and Confirm and Close buttons next to an About Escalation help panel

Validation

Did it work?

The portal launched to a first cohort of three client orgs, starting with the most-used tracking moves before the heavier tools land in later releases. Before launch I pressure-tested the direction with clickable-prototype usability tests; since launch, early data from real account managers backs up what the testing predicted.

90%

Success in status tracking

During testing, almost every user was able to find the exact stage of their case on the first try without any guidance.

Zero

"Lost" conversations

Users reported that having the chat and files tied directly to the case made them feel more confident about the history of the request.

6 hrs

Back per account manager each week

Early data from the first cohort: the portal's live record replaced the manual status reports account managers had been rebuilding by hand.

Post-launch

What I'm watching now it's live.

Now the first cohort is live, I'm tracking these three areas to confirm the portal is doing the job. Each one ties back to a concrete change in behavior, not a vanity number.

Shift in communication

I'm watching whether "status update" emails fall as portal logins rise, the signal that users trust the dashboard for answers.

Document task completion

I'm tracking how quickly clients upload requested files through the portal versus the old email-in method.

Self-serve reporting success

I'm measuring how often the "Export" and "Filter" features get used, a proxy for account managers handling their full workload self-serve.

Key Decision

Why I built a shared record instead of notifications.

The original ask from stakeholders was simple: add email notifications so account managers know when an inquiry status changes. I pushed back. Here's why.

Round-one lo-fi wireframes comparing the rejected notifications-only direction against the shared case record that was built, with annotations on why notifications leave the inbox as the source of truth

The round-1 lo-fi that settled it: notifications only vs. a shared record. Recreated; originals under NDA.

Why a shared record instead

Notifications tell you something happened. A record tells you what happened.

Email notifications would've reduced some back-and-forth, but they would've left the source of truth scattered across inboxes. Two people can get the same notification and still have different versions of what's true. The shared case record meant one party couldn't operate from a stale snapshot. Every status change, document upload, and message sits in the same place, so "what's the status?" becomes a lookup, not a conversation.

What I traded away

It was a harder build, and I had to make that case to engineering.

Notifications would've shipped in two weeks. A shared real-time record took three months. I framed the tradeoff this way: notifications reduce the number of follow-up emails; a shared record eliminates the reason for them. The 62% resolution improvement we modeled from prototype task times against the email baseline backed the call, but the harder moment was convincing the PM that the larger investment was worth it before we had any data. I used the research to make the case: six separate interviewees described the same "I sent an email, now I wait" pattern, and that specificity mattered more than a prototype.

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

Designing a system of record means defending what doesn't get built.

The first round of stakeholder asks would have stuffed every report, alert, and integration into one screen. Holding the MVP to four jobs, status, conversation, documents, resolution, took more meetings than the design did. It's the reason the prototype tested cleanly on the first pass.

10 user interviews shaped the four-tab IA
3 prototype rounds before usability testing
What didn't work: the SLA and escalation logic was designed without engineering in the room. It surfaced late, broke in review, and forced a re-spec before round three
What I'd do differently: bring engineering into wireframe reviews two weeks earlier, so that failure happens on paper instead

Impact on process

The patterns left behind for the next portal.

This was the first case-management surface on Onity's mortgage platform, so the components and the research artifacts both became templates. The next team building a similar workspace started from the moves I made here, not from scratch.

Live case-table pattern, status chips, owner, aging, added to the internal design system
Progress-tracker component reused on the Loan Deboarding portal
Interview synthesis template now used across the platform team