Card

For a long time the only way to show a list was one row per item. When the values are short — a name, a date, a status — that is still the fastest layout there is. The trouble started when items began carrying more than short values. A cover image, a title, a two-line description, the faces of everyone viewing it, and a share button will not fit into one row no matter how the columns are arranged.

Narrow screens made it obvious. Open a six-column table on a phone and the rest of the columns live off the right edge; swipe over to them and you lose track of which row you were reading. People stopped swiping and started tapping whichever row was nearest, which meant the one job of a list screen — letting someone choose — had stopped working.

A card takes the information that used to run sideways and stands it upright. Put everything about one item in one box and the box stays complete wherever it lands on the screen. Four across on a wide screen, stacked one per row on a narrow one, and nothing inside the box has to change. That property became especially useful once responsive design, where layouts rearrange themselves by screen width, became the normal way to build.

The elements belonging to one item go inside a single region marked off by a border or a shadow, and that whole region is treated as one unit.

What goes in usually settles into five slots.

1. The boundary — a light border, a shallow shadow, or a background tint. Using all three makes the card float off the page, so one is normally enough.
2. A lead image or icon, placed at the top or on the left. Items without one get a gray block in that slot to keep heights equal; leave it empty and the grid falls out of alignment.
3. The title — the one line that says what this card is. It is the only element a card genuinely cannot do without.
4. Supporting values such as a date, an author, or a status. More than two or three and the title gets buried. This is where visual hierarchy, sizing and contrast that decide what gets read first, either works or doesn't.
5. The action — the whole card is clickable, or there are buttons inside it, or both.

The order of those five has to be identical on every card. Faced with twenty of them, nobody reads card by card; the eye scans down the same position in each box. If the third card puts its title above the image, that one card breaks the scan for the whole grid.

Outside the box, cards sit on a grid system with predefined columns and gutters — four columns at 1200 pixels, two on a tablet, one on a phone. Only the column count changes at each step; the card itself keeps its shape, which is what makes a single card design survive every screen width.

The action slot takes some care. Make the whole card open a detail view and also put a share button inside it, and someone who taps share gets dragged into the detail view instead. The button has to stop the click from bubbling out to the card around it, and keyboard navigation has to land on the card and the inner button once each rather than trapping the user between them.

The common case is a list where each item carries an image or a status: documents, projects, or the cluster of metrics at the top of a dashboard. A metric card can hold the number, the label, the period, and the change against the previous period in one box, which is why rows of four of them show up on so many dashboards.

The cases where cards work badly are just as clear. When values have to be compared, use a table. Finding the largest of twenty amounts takes seconds when the numbers are stacked in one column, and takes reading twenty boxes when they're scattered across cards. High counts are a problem too: a card is tall, so a hundred of them make a very long scroll, which is why cards usually arrive with pagination or a load-more button attached.

The neighboring layout components do different jobs. Tabs swap content in the same place and an accordion folds away things most people won't open, while a card lays many items out at once so one can be picked. What separates them is whether the user's job on this screen is choosing, skimming, or comparing.

In a design system, the card is built once and the contents are swapped in. Build one per list and you end up with 16-pixel padding on one screen and 20-pixel padding on the next, and every future change to the corner radius becomes ten edits instead of one.

"Let's make this list cards. People need the thumbnail to tell the documents apart."

There is information here that a single-line row can't carry.

"If there are two buttons inside the card, the whole-card click should go."

Don't build a surface where the result depends on exactly where someone tapped.

"This should be a table, not cards. We're comparing amounts."

Pick the component from the user's job, not from how it looks.

Reworking Pagedeck's document list, the first thing Noa did was take things out of the card. The first draft held a cover, a title, two lines of description, the last editor, the edit time, three tags, a share button, and an overflow menu. Lined up four across, none of it read as a title.

Noa kept three things — cover, title, edit time — and moved the rest into the detail view behind the card. Three values are enough to choose from on a list screen. Theo pointed out that a fully clickable card collides with the overflow menu, so the menu now appears only on hover.

The most common belief is that wrapping things in cards tidies up a screen. Scattered elements do look neater once they're inside a box, so the idea is easy to arrive at. But a card groups; it doesn't organize. Wrap every cluster on a page in a card and you have drawn eight boundaries, and on a screen full of boundaries nothing reads as more important than anything else.

The other frequent mistake is treating cards as a mobile component, usually because the first place people meet them is a phone screen standing in for a table. The actual test is the kind of information attached to each item, not the width of the screen. A wide screen still wants cards when every item carries an image and a status, and a narrow screen is better served by single-line rows when each item is just a name and an amount. Judge by screen width instead and you get a phone layout where one card fills the viewport to hold two lines of text.