Anatomy
┌──────────────────┐ ┌──────────────────┐ ┌──────────────────┐
│ [ image ] │ │ [ image ] │ │ [ image ] │
│ Riverside Fit-Out│ │ Harbour Depot │ │ Kestrel Joinery │
│ Leeds · Dana │ │ Hull · Sam │ │ Grimsby · Priya │
│ 6 open jobs │ │ 2 open jobs │ │ 1 open job │
└──────────────────┘ └──────────────────┘ └──────────────────┘
same structure, same order, same height, every card
- One shape, repeated. The eye learns the card layout once; every deviation costs that learning back.
- A five-element ceiling. Cards invite accumulation because there is visible space. The space is not free — it is the reason the list scrolls.
- Consistent height per row, or the grid ragged-edges and stops reading as a set.
Why it works, when it works
Cards buy containment. Each record is visibly one thing, which is exactly right when records differ from one another — a product with a photo, a report with a chart, a template with a preview. Containment is what a table cannot give, because a table's power comes from records sharing a structure.
They also buy space for a genuinely visual payload. A photograph in a table row is a thumbnail; in a card it is the point.
Why it usually does not work
For homogeneous records, cards destroy the one thing that makes a collection readable: alignment. Values in a table column share an edge, so the eye compares them before reading. Cards place every value in its own coordinate space, so forty records means forty separate readings.
The house rule from the design guidance is direct: for long lists, a condensed table beats large whitespace-heavy cards; reserve roomy cards for a few high-importance items. This is the named anti-pattern card soup — twenty homogeneous records rendered as enormous cards, usually chosen because the mockup with six looked good.
The test
Ask: would anyone ever want to compare this field across records? If yes — amounts, dates, statuses, counts — those values want a column. If the honest answer is that people pick one item and act on it, cards are fine.
Then ask how many records there will be in a year. Cards that work at eight rarely work at eighty, and the migration is a rewrite of the screen.
Getting it wrong
- Card soup. The default failure. Homogeneous rows, huge boxes, no comparison possible.
- Ragged heights, so the grid never resolves into a set.
- Cards that grew into records. Twelve fields per card is a table that has been folded up and made unsortable.
- Only the title clickable, so most of a large target does nothing.
Exemplars
Airbnb search results are the strongest case for cards: the photograph genuinely is the information, records are heterogeneous, and people choose one rather than compare fifty on a metric.
Figma's file browser shows the previews-are-the-point argument — a filename list would be strictly worse because recognising a design by its thumbnail is the whole task.
Stripe is the useful counter-example: almost nothing in the dashboard is a card, because almost everything is a homogeneous record people compare.
The extractable rule: cards are for recognition, tables are for comparison. Decide which one the person is doing, and the choice makes itself.