Anatomy
┌────────────────────────────────────────────────────────────────┐
│ Customer Owner MRR Renews Status │ ← sticky
├────────────────────────────────────────────────────────────────┤
│ Acme Corporation Dana $1,200 12 Sep 2026 Active │
│ Globex Sam — trial, d9 Trial │
│ Initech Dana $400 03 Nov 2026 Active │
│ Umbrella — — — Churned │
└────────────────────────────────────────────────────────────────┘
left-aligned ↑ right-aligned, tabular figures ↑ word first
The rules that make it work are unglamorous and all of them are about alignment:
- Numbers right, text left, tabular figures throughout. A column of right-aligned numbers can be compared by length alone — you spot the outlier without reading a single digit. Proportional figures break this, because a
1is narrower than an8. - A sticky header. Once you have scrolled past it, an unlabelled column is a guessing game.
- Separators, not stripes. Zebra striping was a fix for wide tables on low-resolution screens. On a modern screen it adds visual noise proportional to row count.
- Tight rows. 36–44px. Every extra pixel of row height is a row that fell off the screen.
Why it works
A table is an alignment machine. The reason it beats cards for this job has nothing to do with taste: values in a column share a baseline and a left or right edge, so the eye compares them preattentively — before reading. Cards destroy that. The same forty records in cards force forty separate readings, because no two values ever line up.
This is the direct application of two principles. Minimize distance: related values sit adjacent, so connecting "this customer" to "this renewal date" costs a glance rather than a scroll. Progressive disclosure: the table is the overview layer, and everything you left off it lives one click deeper — you are deferring detail, not deleting it.
The density judgment itself is settled house guidance: for long lists, a condensed table beats large white-space-heavy cards; roomy cards are for a few high-importance items.
Choosing columns
The hard part is not building the table. It is deciding what goes in it, and the failure mode is putting in everything the model has.
Ask one question per candidate column: would someone ever scan this column to decide which row to open? If not, it is detail, and detail belongs in the record.
A working budget is six or seven columns:
| Slot | What goes there |
|---|---|
| Identity | The name a person would say out loud |
| Status | Where this record is in its lifecycle |
| Measure | The one or two numbers people compare |
| Owner | Who is responsible, when that matters |
| Time | The date that creates urgency |
If a stakeholder wants an eighth column, something has to come out. The budget is the mechanism; without a fixed cap, every stakeholder's favourite field lands in the table and you are back to a spreadsheet.
Getting it wrong
- The horizontal scroll table. Thirty fields dumped into columns because nobody decided what mattered. Half the data is off-screen, and the half that matters is not reliably the visible half. This is the named anti-pattern Data dump, and the cure is the column budget above.
- Card soup. Twenty homogeneous records rendered as enormous cards. Usually chosen because cards photograph better, at the cost of the job the screen exists for.
- Rainbow status. Six hues at the same saturation, two of them meaning two things each. Colour stops separating anything and the table turns to confetti under a squint test.
- Centred numbers. Kills the ragged edge that makes a numeric column comparable at a glance.
Exemplars
Stripe's payments list. Amount right-aligned in tabular figures, status as a word with a small colour dot, everything else deferred. Notable for what is absent: the payment object has dozens of fields and about six reach the table.
Linear's issue list. Proves density is not the enemy of calm — tight rows, generous horizontal whitespace, and almost no colour, so the few coloured things genuinely mean something.
Ramp's transactions. Shows the escape valve done properly: the table stays narrow and disciplined, and the rest of the record opens beside it rather than being crammed into another column.
The extractable rule: a great operational table is defined by the columns its designers refused to add.