From mistrust to one source of truth

Lenders used to chase borrowers for review documents through email, letters, phone calls and fax. Nothing was tracked, statuses were unclear, and legally required paperwork could slip through.

As lead designer, I wrote the spec with product and development, then designed version one in Figma for both sides: lenders setting up and managing reviews, and borrowers seeing what was needed and uploading it. It launched in November 2024.

Three versions, one choice

I explored three versions of the review setup flow, mapping every state: schedule, file requests, covenants of three types (value, yes/no and custom), errors, editing, deleting and a final summary. Comparing them with product and development is how we chose the preferred design. The flow launched with three steps and grew to five by mid-2025 as needs became clear.

Every document request shows its status at a glance (incomplete, uploaded, accepted, rejected, cancelled or waived), and automated reminders replace manual chasing. When a borrower uploads a file, AI checks it and flags it if it may not be the document that was requested. I advised the junior developer who built that on how a lender would want it to behave.

Version one worked: it replaced five channels with one. But shipping wasn't the end of the story.

By 2026, one of our clients, a US lender, was using the platform to manage loan reviews, but usage was low and the team sensed something was off.

Rather than guess, we ran three remote sessions over Google Meet in June and July 2026 and watched their servicing team do their real work. The rule we set ourselves: absorb, don't fix on the call. Come back with design concepts instead.

• Session 1: staff walked us through how they find and work on reviews day to day.
• Session 2: a deeper look at how they configure reviews, add requirements and enter covenants.
• Session 3: how new loans are onboarded and set up for their first review.

I observed every session, noting where people hesitated, worked around the product, or went to another tool. Between sessions, staff logged frustrations and screenshots as they hit them.

The root problem wasn't a missing feature. It was trust. The goal everyone agreed on: a single, confident snapshot of what's required, what's received and what's missing, without cross-checking other systems.

We distilled the sessions into nine issues, then mapped each one to the change that would solve it. Some fixes solve several issues at once, which set the order.

Reviews Overview

One tab on the member profile that shows every review and its status at once, with totals for overdue, due soon and complete, grouped by product. It replaces drilling in and out of individual reviews to find a single item.

Requests Overview

A Documents tab that shows every document requested from a member in one place, grouped by document type, with totals for overdue and due soon and a clear status on each. Staff can check they have what they need without thinking about reviews at all, which is how they actually work.

Request deduplication

The platform already merged duplicate requests behind the scenes, but nobody knew. Now every document shows a "Linked in N places" chip, and opening it reveals the linked context, the products and reviews it covers, plus a timeline of when it was requested, reminded and fulfilled. Staff can see one upload satisfies several needs, and that the borrower isn't being asked twice.

Next: request rejection

Cancelled requests used to disappear like throwaway items. I'm redesigning them as a back-and-forth between lender and borrower, so the history of a document stays visible.

For each one I designed the experience, then built the UI and front end with Claude Code on our design system. A developer built the back end.

The sessions also settled design questions. The client confirmed that covenant changes should always apply to every future review; there's no real case for editing just one. Much of the old interface assumed the opposite, so this simplified future designs.

We also found features staff didn't know existed, which pointed to onboarding and documentation gaps, not just UI ones.

Three of the roadmap's fixes are built and the fourth is in progress. The bigger structural changes, and aligning review dates with the client's systems, are next and depend on decisions with the client. It's too early for hard numbers, so I'm not claiming any yet.

Watching people work tells you things a feature request never will. The client asked for date fixes, but underneath was a mismatch in how they think about their work. Designing around their mental model, member first and documents first, mattered more than any single screen.