Fintech Platform

The challenge

The core job of the platform is matching transactions across data sources. In simple cases, one bank entry matches one Stripe payout. In real life, a single bank deposit might correspond to 30 individual Stripe transactions across multiple days. Users need to see the relationship at a glance, verify it, and either accept the match or break it apart.

The insight

Early in the project, our PM brought back a finding from finance users that reframed the problem for me. The hardest part of their day wasn't finding discrepancies — it was trusting the matches the system suggested. Their existing tools would say "matched ✓" with no visible reasoning, and they'd still re-verify everything in Excel anyway. That changed my brief: the matching screen wasn't a confirmation screen; it had to be a forensic view — every match needed to show its work.

My approach

• 01Designed a split-pane layout: the source transaction lives in a compact left rail (preserving context), while the right side hosts a full table of the matched counterparts with pagination and filters. Both sides visible simultaneously, by design — so the user can compare without clicking back and forth.
• 02Built a tabbed system (5 tabs) so the same transaction can be viewed across different lenses — match details, related transactions, transaction logs, raw data — without leaving the page. The "raw data" and "transaction logs" tabs were specifically there to give finance users the audit trail they needed before trusting the match.
• 03Made the "Unreconcile" action a first-class primary button, not buried in a menu. If a user disagrees with an automated match, they need to break it without hunting.
• 04Designed a right-side drawer (~396px wide) that surfaces additional context — notes, history, related metadata — without taking the user away from the matching view.

The trade-off

Density vs. simplicity. I chose to expose the full table directly on the page rather than hide it behind expandable rows. Finance users prefer scanning over clicking — they're used to spreadsheets where everything is visible at once. The vertical space cost was worth it.

Outcome

The matching flow shipped as a core part of the live product. Through our PM, finance users gave positive feedback on the forensic / audit-trail approach — specifically that being able to see why a match was suggested gave them enough confidence to stop double-checking everything in Excel.

The challenge

For the platform to reconcile anything, customers must first connect their data sources — banks, ERPs, payment providers, internal databases. Some sources are API-connected ("Online"); others are manually uploaded files ("Offline"). The Offline flow is harder because the user has to describe their own data to the system: which column is the transaction ID, which is the amount, which is the status, what status values mean what.

This is configuration work that ML systems usually hide from users. But here, getting it wrong silently means every reconciliation downstream is wrong. The wizard had to surface the complexity without overwhelming finance users.

The insight

This was the screen that took the most iterations to land. Not the visuals — the flow itself. Early versions grouped steps logically (all field mapping together, then all status work, then transforms), but in testing the logical order didn't match how users actually thought about their data.

The version that shipped — Core Fields → Supporting Fields → Status Value → Review — came after several rounds of restructuring. It's not the most elegant taxonomy on paper, but it matches how a finance user actually opens a CSV and tries to understand it.

The four steps

• 01Core Fields — map the essential columns (transaction ID, amount, date).
• 02Supporting Fields — optional metadata (description, reference, customer ID).
• 03Status Value — translate the customer's status terminology into the platform's canonical set.
• 04Review — full preview of what was mapped, before commit.
• 05A "Data transform" step lives between mapping and review — for cases where the customer's CSV needs splitting, formatting, or coercing before it's usable. Power-user territory, but absolutely necessary.
• 06A persistent "ask AI copilot" button sits on every wizard step so users can get help in context without losing their place.
• 07Side navigation stays visible throughout the wizard rather than going full-screen modal — finance users often need to jump back to check another part of the system mid-config.
• 08Free navigation between steps with persistent state — a linear wizard would have been easier to design, but harder to recover from when the user realizes step 1 was wrong at step 3.

Outcome

The wizard shipped as the entry point for every Offline data source connected to the platform, and is currently in use with early-access and pilot customers. The step ordering proved durable enough to ship without further restructuring after launch.

The challenge

The dashboard is the first surface a finance lead sees every morning. It needs to answer one question fast: what needs my attention today? But the underlying data is huge — reconciliation status across all sources, account activity, data source health, and exceptions queues.

The insight

My first version leaned cleaner — fewer cards, more whitespace, one or two key metrics surfaced at a time. The founder pushed back: finance users wouldn't open a separate page to find each number. They wanted everything on the front page, simultaneously, scannable in one glance. Density wasn't a problem to solve — it was the requirement.

That reframing forced a redesign. Instead of asking what's the most important number, I had to ask how do I make six things equally legible without any one drowning the others. The answer was strict componentization: every card uses the same shell, header, and chart styling. The eye learns the rhythm in two seconds and can then scan content rather than navigate layout.

My approach

• 016-card grid layout — three donut charts (reconciliation, accounts, data source overviews) up top, two data tables below, and an accounts activity panel.
• 02Donut charts deliberately, not bar/line — the user's mental model here is proportion of completion on a single day, not trend over time.
• 03"Last update" timestamp + reload control in the header — finance users need to know whether they're looking at fresh data before making decisions. Non-negotiable in financial UI.
• 04Skeleton loader states in two variants, so the perception of speed matches the platform's hours-not-weeks promise.

The system-level decision

Every card uses the same component shell — same border, same radius, same header pattern with title plus dropdown filter. This let me build out the dashboard quickly and gave finance users a predictable scanning rhythm. The founder's density requirement only works if the user's eye knows where to land.

Outcome

The dashboard shipped as the platform's home screen and is what every pilot customer sees on login. The componentization paid off downstream — the same card-shell pattern was reused across the ledger overview, account overview, and reconciliation result screens, which let me build out the rest of the platform faster without redesigning each surface from scratch.