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.
The page users couldn't trust
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.
Support messages are illustrative, recreated from real ticket patterns.
Reconstructing the status model
No documentation of the status model existed, so I reconstructed it with billing and backend. The PM and project manager helped me recover the 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 were dumped into the same generic Error.
- 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.
Labels are representative and reworded for confidentiality; the inconsistency is real.
A list you can read at a glance
The redesign turned all of that into a list you can read at a glance: grouped by day, direction shown by sign and color, status on every row - so you see what happened without opening anything. Filtering by account and type puts any record a tap away, instead of a scroll-and-squint.
Details worth opening
The old detail view just restated the row you tapped — same amount, same date, nothing you couldn't already see. 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.
And when someone does reach support, the transaction context goes with them — no copying IDs, no re-explaining.
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 labeled "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.
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 1.7x in the two quarters after launch.
1.7x fewer
0
