Rebuilding transaction trust at Doto
A redesign of Doto's transaction history — turning a log users couldn't trust into a system of clear statuses, live timelines, and real recovery paths.
Problem: a legacy transaction page users couldn't rely on
The transactions page had been a legacy area for a while. Other parts of the product had taken priority, so the page stayed mostly untouched while payment flows and edge cases became more complex.
By the time I picked it up, the issue was bigger than outdated design. Users could see transaction records, but they couldn't always understand what was happening, how long it would take, or what to do next. That uncertainty was showing up in support, where transaction-status tickets often came down to the same frustrated questions.
The experience reflected that confusion: vague statuses, no recovery paths, repeated information in the detail view, and no reliable way to filter or distinguish transaction types. The page needed a redesign, but first I had to understand the system behind it: what each status actually meant and where it came from.
Reconstructing the status model
No documentation of the status model existed, so I reconstructed it with billing and backend, drawing on the PM and Project Manager to recover logic and edge cases. I traced every transaction type through every situation it could land in: what triggered it, what status the user saw, and which communication (if any) they got. That put the real problem in plain sight:
- A single "Error" covered a problem on the user side, a technical failure, and a manual KYC rejection.
- One "Processing" hid two distinct stages.
- Deposits needing source-of-funds checks had no status at all.
- Whether a user got a push, an in-app message, an email, or nothing followed no rule.
From there I built one source of truth — a table mapping every situation to its true status and the message it should trigger. With the UX writer, I turned that into a canonical status set: renaming the vague ones, splitting the ones that masked multiple realities, adding states that were missing, and giving each a clear communication trigger.
A list you can read at a glance
Grouped by day, money in and out split by sign and color, status on every row. You can see what happened without opening anything. Filter by account and by type — deposits, withdrawals, transfers — so a specific record is a tap away instead of a scroll-and-squint.
Details worth opening
The old details repeated the list information. The new one carries what people actually need: a copyable transaction ID, account, method, date, and bonus only when there is one. The same pattern covers every type, down to system entries like balance adjustments and inactivity fees.
Every failure names what happened and offers the next step — retry with details prefilled, verify source of funds, or reach support. "Failed" and "Rejected" are no longer the same scary word.
Pending states that show where the money is
A live progress timeline — Verification → In progress → Completed — replaces a single vague status, with real estimates ("up to 5 minutes", "up to 1 hour") so waiting never reads as stuck.
The refund that looked like a mistake
Sometimes a withdrawal can't complete in full and part of it is refunded. The old design split that single event into three disconnected records — including a surprise deposit from Doto labelled "Transfer," with no explanation. An unexplained deposit from your broker doesn't read as a refund; it reads as an error, or fraud. The redesign tells it as one story: a single withdrawal, with the refund shown as a step in its timeline and the reason in plain language.
Support that already knows the transaction
Contacting support pushes the transaction details straight into the chat — no copying IDs, no re-explaining. Less friction for the user, fewer back-and-forths for the team (and a direct dent in that support volume).
Results
The transactions page stopped being a log and started doing a job. Statuses now say what's actually happening, pending transactions show where they are, and no failure leaves the user stranded. The three questions that had been flooding support — where's my money, what does "Error" mean, why is it still processing — were designed out of the product, cutting transaction-status tickets by 40% in the two quarters after launch.
−40%
Transaction-status support tickets, first two quarters after launch0
Dead-end states: every failure now has a next step