Eight columns, one row
How I broke dense tables down into chunks you can read at a glance, on web and mobile.
When I first opened the dashboard, the brief was simple: it looked too complicated. There were too many balances, attention was split across the screen, and every list was a table. That made sense for an MVP, since a table is the quickest way to put data on a screen, but nobody on the team had worked on UX, so it never went further.
One transaction carried eight facts across eight columns: recipient, transaction ID, currency, amount, date, status and more. The same table repeated for recipients and invoices. Everything was there, but none of it could be scanned, and none of it could go to a phone.
- Role
- UX, component design
- Scope
- Transactions, recipients, invoices, web & mobile
Where it started
Tables on every screen, even the dashboard.
The old dashboard, with recent transactions in a six-column table.
The transactions table, and recipients with details in an accordion that pushed every row below it out of view.
Tables work when someone checks values line by line against another document. Here the same table did every job, including a quick look to see if a payment landed. Reading one transfer meant scanning eight cells in order, and on mobile the only options were scrolling sideways or cutting columns.
First, I tried shrinking it
My first idea was to make the table responsive and drop columns as the screen got smaller. It didn't hold up. Whatever got dropped simply disappeared, and what stayed depended on screen width rather than on what mattered.
So I stopped treating a transaction as a row of cells. Instead of labelling each fact in a column, I started showing it: direction as an arrow, currency as a flag, status as a coloured chip.
Breaking the table apart
Eight columns, sorted into one row.
I took the columns as loose blocks and moved them around until they fit into one row without losing anything. Direction and currency merged into one icon. ID and time moved to a muted second line. Status became a chip under the amount. Every column ended up somewhere.
Where each of the eight columns went.
The finished row, broken down part by part.
The row
Who, how much, and whether it went through.
Deposit, receive and send, each with its own arrow. The flag or token shows the currency.
The dashboard after, with the table header gone.
Deciding what stays on the row
Not everyone agreed at first. Some of the team wanted every detail visible on the row, which would have turned it back into a table in a smaller box. I explained that the row only needs what matters in that moment, and everything else can open in a detailed view when someone clicks it.
That detailed view is where every fact gets its label: the summary, the transaction information, and the card and user details. You glance at the row to find a transaction, and open the page when you need to check it.
The detail page, with everything the row left out, labelled.
Beyond transactions
Recipients, invoices, cards and mobile.
The same structure worked for every other list: icon, main line, second line, value on the right, status. For recipients, the arrow became an avatar and the amount became their currency. For invoices, it became initials and a due date. For cards, it showed the spend against the card's limit. Nothing else had to change.
Recipients, invoices and card spend on the same structure.
The same row in the mobile app.
What shipped
The row replaced tables across transactions, recipients and invoices on the web, and became the default list in the mobile app.
The founders liked that the information now broke down into chunks that worked on mobile, which also answered the question the team had been stuck on: how tables would ever work on a phone. The full table stayed only where it helps, in full-page views with filters and CSV export for reconciliation.