The job was exceptions, not navigation
Every morning the finance team opened the same four screens to follow a single payment. Mismatches between voyage estimates and final invoices had no automatic detection — they surfaced only when someone happened to notice — and a failed payment carried the same visual weight as one that had gone through. Three weeks of flow-mapping with finance operations, voyage operations and engineering traced the full payment lifecycle, estimate to settlement. The finding that reset the scope: the job was exception detection, not better navigation. Everything else was downstream of it.
The job wasn't navigation — it was catching the payment that failed.
One payment, one timeline
I replaced the four-screen hop with a single record view — the whole lifecycle of every invoice on one rail: estimate, PO raised, approved, sent, acknowledged, settled. Critical discrepancies sorted to the top of every list with a distinct treatment, so the team could act on them in context instead of hunting for them. The unified timeline became the most-used view in the platform. I prototyped it in high fidelity against real invoice data at full density — what needed validating was how it scanned at real scale, not how it looked in a tidy demo.
View my comment
We first built a separate exceptions panel — it tested badly. Teams didn't want a summary to check; they wanted the exception sitting in the list they were already working in. Detection had to live where the work happened.
Where critical discrepancies should live
- The obvious panelA separate exceptions panel above the ledger. It surfaced the problem but forced a context-switch, when teams needed to act inside the list.
- The quick winBetter filters, detection left manual. But the failure was no one seeing the exception at all. Filters cannot fix invisible.
- What I builtException-first sorting inside every list. Critical items float to the top and get actioned in context. Detection became the system's job.
The invoice that didn't frighten anyone
One surface had to stay still. In shipping, the paper invoice is the institution — formats refined over decades, trusted across languages and ports. The instinct was to modernise it; the right call was the opposite. I kept the document teams already trusted and automated everything around it — generated PDFs, validated fields, no re-keying. Those automated generation workflows cut document errors by 28%; redesigning how personal and expiry data was managed cut expired-document errors by half. Under a tight MVP deadline I kept the generated PDF preview in scope — seeing the final document before sending was what made teams trust the automation.
View my comment
Modernising the invoice would have demoed beautifully. I made the opposite call in the room: in shipping, the document is the institution. Familiarity was the feature, not the thing to fix.
Tracking and approvals
The approval workflow assigned approvers by permission level; once approved, status updated automatically on the dashboard — no more chasing by email. The interface was simplified as testing demanded: a four-level action footer became a single line of buttons. I restructured the information architecture around the payment lifecycle, prototyped against real invoice data, and built the component patterns — tables, status indicators, PDF templates — into the platform design system.
| Invoice | Counterparty | Amount | Status | Action |
|---|---|---|---|---|
| INV-2041 | Meridian Chartering | $486,200 | Awaiting approval | |
| INV-2042 | Port of Valencia | $512,800 | Awaiting approval | |
| INV-2039 | Hanse Bunker GmbH | $421,000 | Approved |
FREIGHT INVOICE · INV-2039
From
Hanse Bunker GmbH
Hamburg, DE
To
Aurora Shipping Ltd
London, UK
| Bunker fuel — MV Northern Star | $398,400 |
| Port handling | $22,600 |
| Total | $421,000 |
Generated automatically · no re-keying · same layout the team reconciled on paper
Interactive reconstruction with fictional data, rebuilt for this portfolio — not the shipped product. The pattern shown: approval updates status everywhere at once (no email chasing), and the generated PDF preview that kept the document trustworthy.
What it changed
$500M in invoice processing moved through the system in its first five months. Morning reconciliation went from opening four screens to a targeted exception review, and the unified timeline became the platform's most-used view. Document errors fell 28% and expired-document errors by half as the workflows around the document tightened. I stayed through QA to production, verifying component behaviour across edge cases with engineering before each release.
I led the invoice PDF generator from design through build, and every team reused it afterwards. The status patterns I built went into the platform's design system.
Reflection
The most valuable decisions were about reduction, not addition. Exception-first sorting, the unified timeline, keeping the document still. Getting there meant understanding the whole payment lifecycle well enough to know what to subordinate, not just what to surface. The four-level action footer made it into early builds because I trusted the requirements document over what I saw in test sessions. Watching the first three users would have saved a redesign cycle.