Fintech
Approve the run. Hold the one payout that shouldn’t go.
Ferrow, payout approvals for finance teams. Designed end to end, shipped as a prototype that runs.
- Scope
- Flow, identity, system, product
- Platforms
- Web and iOS
- Built on
- shadcn/ui, Geist, React
- Deliverable
- Figma and a working prototype
00Overview
One changed bank account, hidden in 148 payouts.
It showed up as row two of a table, at the same weight as the other 147. Approvers reviewed everything, so they reviewed nothing.
148 payouts. One of them changed.
Northwind Logistics · $18,420.00
Human steps, down from 10
Tool, down from three
Screens mapped, web and mobile
Decision for 147 unchanged payouts
01The flow as it stood
Ten steps, three tools, zero warnings.
Walked as it really happened. A red pin wherever an approver lost the thread.
- 01Context lost at the door
- 02Everything weighs the same
- 03All or nothing
- 04The review leaves the product
- 05The one signal was hidden
02Where it got hard
Five places where two good requirements collided.
None of the hard parts were visual. Each one was decided before a screen was drawn.
Cooling period vs Friday payroll
Isolate, never block. The batch goes; the changed payee waits.
One approval record vs 147 good payouts
Split, don’t untick. Held rows become a linked child batch.
Controls vs approver fatigue
Show what changed first. Everything else is one line.
Dual control vs an approver away
Delegate before the absence. Time-boxed and logged.
Approving on a phone vs approving blind
Mobile approves the unflagged, never the flagged.
03The flow, rebuilt
The run is only as slow as its one real exception.
Seven steps, one tool. Every fix answers a red pin.
- 01Arrives in context
- 02Weight follows risk
- 03Split, not all or nothing
- 04The check stays in the product
- 05The signal is computed
Bank detail change, with a 72-hour cooling period
45 screens mapped across web and mobile
04Identity
A treasury product that keeps its nerve.
White and soft slate, one verdigris that means “ours”, and amber for the payout that waits.
The F is a batch.
Stem, batch, payouts, and the one square held back.
05Five directions
Five ways to approve a batch with one bad payout in it.
Same data, same components. They differ in structure, never in styling.
B · Exception first
The held payout rises above the batch, old and new account side by side. Release only ever counts what is ready.
06Design system
shadcn/ui, with a different temper.
Every Ferrow token is a shadcn/ui token first. Drag to switch the theme.
07Flows and states
Every flow wireframed, with the real copy.
Drag the boards. Nothing in hi-fi had to rewrite a word.
08The product
One run, from review to settled.
Direction B through the whole run. Every number matches the prototype to the cent.
Close up
Approve between meetings. Verify at your desk.
Face ID to release. The dock turns into the approval status, so nothing on the screen moves.
A bank detail change, checked and held
Six exceptions become a queue
Controls and the states nobody scopes
09Prototype
A prototype that runs, not a mockup that clicks.
Real shadcn/ui components and Ferrow tokens. Every video on this page is the prototype, recorded at 60 fps.
Routes, from the inbox to the audit log
People to switch between
Scenarios, empty to partial failure
Payouts, $412,380.00 to the cent
10Launch page
A launch page built from the product.
Real screens, real components. Keep scrolling.
11What we test next
Three assumptions that need evidence.
On the prototype, with finance operators, with tasks rather than opinions.
The queue threshold
Is five exceptions where approvers lose track, or three?
The mobile limit
Do approvers accept desktop-only verification, or work around it?
The call-back step
Does the call get made under Friday pressure?
Have a workflow where one row decides everything?
We redesign the path to the action and hand it back as a working prototype in five days.