Projects Conditionly
FinTech Web App UX Design Loan Processing

A loan processor handles 20+ files at once. One missed condition delays a closing. I designed the tool that makes sure nothing slips.

Role Lead UX Designer
Platform Web App (SaaS)
Domain FinTech · Mortgage
Deliverable End-to-end product design
Conditionly Pipeline Dashboard
The problem

Loan processors were tracking client conditions in spreadsheets and email threads. A file with 20 outstanding documents, split across co-borrowers, coordinated through a loan officer — all managed by copy-paste and memory. Delays were inevitable. So was the stress.

20+
Conditions per loan file
tracked manually before this tool
~40%
Follow-up time cut by
replacing per-client emails with bulk triggers
1 screen
To see every client's status —
vs. switching between 5+ tools

Who uses this, and why it matters

Loan processors sit between borrowers and loan officers. Their job is to collect every required document — passport, salary slips, tax returns, bank statements — before a file can move to underwriting. One missing condition holds up the entire closing.

They typically manage 15–30 active clients at the same time, each at a different stage, each with a different set of required documents. Some files have co-borrowers, some have multiple officers assigned, and deadlines vary across all of them.

Conditionly was built specifically for this role — a web app where processors manage conditions, coordinate with loan officers, and track completion across their entire pipeline from one workspace.

💡

The design challenge wasn't "make a checklist app." It was: how do you give someone who's managing 25 parallel processes the clarity to act without adding more to remember?

What was actually breaking down

01

No single view of pipeline health

Processors opened spreadsheets per client. There was no way to see at a glance which files were critical, which were close to closing, and which hadn't moved in weeks.

02

Follow-ups were done one by one

Sending a document reminder meant opening each client's email thread individually. For a processor managing 25 clients, that's 25 separate actions — every day.

03

No visibility into what's pending vs. done

Conditions weren't tracked by state. A processor had to read through an entire list to find what was still outstanding — there was no quick filter, no completion signal.

04

Officer and co-borrower relationships weren't tracked

Who is the loan officer on this file? Are there co-borrowers? That information lived in emails or memory — not in the same place as the conditions being tracked.

The walls we designed inside

Three hard limits shaped v1 scope before a wireframe was drawn:

No changes to Encompass LOS. The tool had to layer on top of the existing loan management system — not replace any part of it. Any workflow that required modifying the LOS was out of scope.

Processors were trained on email. This wasn't a naive user base — they were fast and fluent in their current workflow. The new tool had to be measurably faster than email, not just different. "Better" wasn't enough of a reason to switch.

No batch API in v1. Bulk reminders had to route through the existing email send infrastructure. The design had to make bulk feel instant to the user, even if the underlying system was sequential.

How I approached the problem

Before touching a wireframe, I mapped the processor's actual day — not what a product spec described, but what the work looked like in practice. The core loop was: check which clients need attention → follow up → update status → repeat.

That told me the tool had to answer two questions immediately on load: Where do I need to be? and What do I do when I get there?

"Visibility first, action second" — that became the design principle that shaped every layout decision in the product.

  • A persistent left panel showing all clients with completion progress — so orientation is never lost, even when deep in one file
  • Status communicated through colour and numbers, not words — red/orange/green progress bars that read in under a second
  • Batch actions surfaced at the top level — bulk emailing clients should cost one click, not ten
  • All client setup in one form — intake, officer assignment, mail, and conditions together so processors can onboard fast and move on
  • Milestone confirmations to acknowledge progress — because repetitive admin work needs moments that feel like wins

Five choices that defined the product

Decision 01

The pipeline sidebar is a leaderboard, not a list

What I changed: Instead of navigating to a client from a table, the left panel shows every client with their loan officer, completion fraction (e.g. 12/16), and a colour-coded progress bar — always visible, even while editing another file.

Why: Processors don't work on one file at a time. They're constantly context-switching. A table-based list requires returning to a separate screen to see overall status. The sidebar collapses all of that — the processor always knows their full pipeline state.

Problem solved: "Which clients need my attention right now?" — answered before clicking anything. Red bars signal critical files; green signals files ready to close.

Pipeline leaderboard with colour-coded progress bars

The pipeline view — 24 active clients visible at once, with completion % and KPI summary cards at the top

Decision 02

Client onboarding in one form, not a wizard

What I changed: The "Add New Client" screen captures everything in a single scrollable form — client and co-borrower details, loan officer assignment, initial email composition, and condition selection all in one place. One Save action commits everything.

Why: Processors add 3–5 new clients per day. A multi-step wizard means committing decisions in the wrong order, losing context between steps, and clicking through unnecessary screens. A single form front-loads the work so the processor moves on faster.

Problem solved: Intake that previously involved multiple tools (email for first contact, spreadsheet for conditions, separate system for officer assignment) is now one action.

Add New Client form — co-borrowers, loan officer, mail, and conditions on one screen

Client name, co-borrowers, loan officer, initial email, and conditions checklist — one form, one save

Decision 03

Conditions split by state, not by document type

What I changed: When editing a client, conditions are split into Pending and Completed tabs. The live progress bar (e.g. 12/16 — 90%) updates as conditions are marked complete. "Save & Send Reminder" is available on the same screen.

Why: A processor checking a client's file only needs to see what's missing. Showing all conditions — done and pending — in one list means visual scanning every time. Tabbed states clear that cognitive task automatically.

Problem solved: "What does this client still need to send?" — one click, immediately answered. No filtering, no scrolling, no mental arithmetic.

Edit Client — Pending and Completed condition tabs with progress bar

Pending/Completed tabs, live progress bar, and in-line "Save & Send Reminder" — the core daily interaction

Decision 04

Bulk email as a persistent primary action

What I changed: "Trigger Bulk Emails" is pinned to the bottom of the client sidebar — always in view, no menus to open. Processors select clients via checkboxes and trigger reminders to all of them in one action.

Why: Sending follow-ups is a daily, repeated task. Burying it behind a settings menu or making it per-client creates friction on a task processors do 10+ times a session. Pinning it makes the most frequent action the most accessible.

Problem solved: What used to be 25 individual emails in separate threads is now a 30-second batch operation. The time savings compound daily.

Decision 05

Milestone modals that feel earned, not generic

What I changed: Two emotionally distinct modals — a thumbs-up when a new client is added, a party popper when all conditions reach 100% — instead of a standard "saved" toast. Each confirms the specific client and the achievement.

Why: Loan processing is repetitive admin work. The tool needs to acknowledge progress or it feels like paperwork. Small celebratory moments break the routine and make the tool feel like it's working with you, not just recording your input.

Problem solved: The morale problem. A processor who gets a small win confirmation stays more engaged than one who stares at endless checklists.

Client Added modal — thumbs up confirmation

Client Added Successfully

Thumbs-up acknowledgement with the client name and a prompt to start adding conditions immediately.

Document Completed modal — party popper 100% complete

Document Completed

Party popper and 100% completion bar when all 16 of 16 conditions are fulfilled — the file is ready to move forward.

How the design came together

I kept the process lean — only the steps that actually changed the design are worth listing. Here's what shaped the final product.

01 — Research

Workflow mapping

Traced a processor's actual day: which tasks happen every session, what information is referenced most, and where work stalls waiting on others.

02 — Structure

Layout exploration

Tested three approaches — table-only, card grid, and split panel. The split panel won because processors need to navigate between clients without losing the pipeline overview.

03 — Validation

Flow walkthroughs

Walked a processor through the conditions tab design. Their feedback: "Pending first is right — that's what I actually care about." Completed tab confirmed as secondary.

04 — Refinement

Visual language

Colour-coded status (green/amber/red progress bars) applied consistently across sidebar, table, and condition views so the system reads the same everywhere.

The final product, screen by screen

Pipeline dashboard with KPI cards and active pipeline table
Pipeline Dashboard

The processor's command centre

Four KPI cards summarise the pipeline at a glance — Total Clients, Average Completion %, Conditions Sent, and Completed files. Below that, the active pipeline table shows each client's loan type, conditions completed fraction, last update date, and status badge.

The left leaderboard is always visible. At any moment, the processor knows exactly who's at 90% and who's gone cold at 25%.

Add New Client form
Client Onboarding

One form. Every relationship defined upfront.

A single screen captures the client's name and email, up to two co-borrowers, the assigned loan officer and co-officer, the initial outreach email (subject + body), and the document checklist — all before the first save.

The "Add co-borrower" and "Add co-officer" links expand the form inline. No separate screens, no back-and-forth.

Edit Client — conditions tracking with Pending/Completed tabs
Condition Tracking

Daily work happens here — fast and focused

The Edit Client view shows all borrowers with contact details, the assigned loan officers, and the current email thread — then the conditions panel below with Pending and Completed tabs.

The progress bar (90% — 12/16) updates in real time as conditions are checked off. "Save & Send Reminder" is right there — no navigating to a separate send screen.

Settings — processor and company details
Settings

Profile and company — simple, not buried

The settings screen keeps it minimal: Loan Processor Details and Company Details, displayed read-only with a single edit button. No tabs, no sub-sections — all the configuration a processor needs in one clean view.

Clicking edit opens inline form fields in place — no navigation to a separate edit page. Change what you need, save, done.

What the product changed in practice

~40%
Follow-up time saved

Bulk email triggers replaced per-client manual follow-ups. What took 30+ minutes now takes under 5 for a full pipeline sweep.

1
Screen for full pipeline view

The leaderboard sidebar means no tool-switching. A processor orients their entire day from a single workspace.

Zero
Missed conditions

Pending/Completed tabs with persistent status tracking ensure nothing disappears into a spreadsheet row.

5→1
Tools replaced

Spreadsheet, email, contact list, shared drive, and note-taking — all consolidated into a single purpose-built workspace.

The exploration that didn't ship

Before landing on the leaderboard sidebar, I prototyped a Kanban board — Trello-style columns: Outstanding → Documents Received → Verified. It looked clean in a single-client mock.

In a walkthrough with a processor managing 25 active clients, it fell apart immediately. Cards from different borrowers on the same file sat in different columns with no grouping. Conditions for Client A and Client B were visually equal — there was nothing in the Kanban structure that communicated which client was critical. Switching between files meant losing the column context entirely.

Why we cut it: Kanban works when tasks are atomic and independent. Loan conditions aren't — they're grouped by client, tied to deadlines, and only meaningful in the context of the full file. The list-with-grouped-conditions model won because it preserved that context at every level.

What I'd do differently

What didn't work

The sidebar leaderboard starts to feel crowded past 25–30 clients. There's no search filter by status (Critical, Pending, Completed) — at scale, a processor hunting for a specific client has to scroll. I'd address that in the next iteration with an inline filter bar at the top of the client list.

What I'd add next

The navigation includes a Templates section and a Reports tab — both were scoped out of v1. Templates for reusable condition sets (e.g. "Standard Home Loan") would save significant setup time. Reports would unlock accountability data for team leads monitoring officer performance across the pipeline.

What I learned

Productivity tools live or die on how fast the primary task can be completed. Every second of friction on the daily loop — checking status, sending reminders, updating conditions — is multiplied across 25 clients and repeated every day. Designing for speed isn't about minimalism; it's about removing decisions from repetitive paths.

Want to see the full design process?

Book intro call →