Fintech
0→1
Web app
Ledger
Rebuilding a payments reconciliation dashboard so finance teams can close their books in hours, not days.
Role
Lead Product Designer
Timeline
5 months · 2024
Team
1 designer, 4 engineers, PM
Platform
Responsive web app
Overview
Ledger is a B2B platform that helps mid-market finance teams reconcile thousands of daily transactions. The legacy dashboard was built for power users a decade ago — dense, modal-heavy, and slow. As the company moved upmarket, new customers were churning during onboarding because the core workflow took days to learn.
I led the redesign of the reconciliation experience from research through ship, partnering closely with a PM and four engineers.
The problem
Closing the books took finance teams days, and they couldn't see why.
Support tickets clustered around one moment: matching incoming payments to open invoices. Users couldn't tell which items needed attention, so they checked everything manually. The business impact was concrete — onboarding drop-off in the first 30 days was our single largest source of churn.
Research
I ran 9 interviews with finance analysts and watched 6 reconciliation sessions end to end. Three insights reframed the project:
01
Trust beats speed
Analysts re-checked the system's matches because they didn't trust automation they couldn't see.
02
The 20% is the job
80% of items auto-matched fine. The work — and the anxiety — lived in the exceptions.
03
Context-switching tax
Answers lived across four screens, so analysts kept a spreadsheet on the side as their real workspace.
The messy middle
I explored four directions before the answer got simple.
Rather than polish one idea, I pressure-tested several. Early concepts over-indexed on automation and hid the very thing analysts wanted to see. Putting rough versions in front of users each week is what killed the wrong ideas fast.
A — Full auto
Rejected: hid exceptions
B — Inbox model
Promising: triaged work
C — Split view
Rejected: too dense
D — Guided queue
Shipped basis
What I rejected and why
The full-automation concept tested worst — analysts trusted it least. That failure became the core principle: show the work, don't hide it. Every later decision traced back to that.
Key decisions
Three decisions, each with a real tradeoff.
Lead with an exception queue, not a table
Surfacing only the items that need a human collapsed the core task into a fast triage flow.
Tradeoff
Power users lost the see-everything grid. I added it back as an explicit toggle rather than the default.
Show the matching logic inline
Every auto-match explains itself on hover, so analysts can verify without leaving the row.
Tradeoff
More visual density per row. We earned it back by hiding resolved items by default.
Ship the queue before the bulk tools
We released the triage flow first to learn, deliberately holding back bulk actions.
Tradeoff
Early users did some repetitive work for a month. The data made the bulk tools far better.
The solution
The shipped design reframes reconciliation as a triage queue: the system proposes, the analyst confirms, and every decision is visible and reversible.
ACH deposit
$980.50
Unidentified · Apr 12
Suggested match
98% match
Invoice INV-2229 · Northwind Co
Confirm match
Skip
Match detail
✓
Wire · counterparty TBD
$2,500.00
✓
Chargeback · ORD-5519
−$640.00
ACH deposit · pending
$980.50
2 selected
Resolve all
Bulk actions
Impact
↓ 42%
Median reconciliation time, measured 60 days post-launch
↑ 27%
30-day onboarding completion for new accounts
↓ 35%
Support tickets tagged "matching"
2 wks
Time-to-first-close, down from 6
What I'd do differently
I'd involve engineering in the exploration phase a week earlier — two of my strongest concepts were technically cheaper than I assumed, and I'd have tested them sooner.
Next project