Cards earn their keep on heterogeneous, independently usable units
Aliases: card layout · content cards
What it is
A card says: this rectangle is one complete object. You can finish it and act on it without reading the neighbours. A stay, a recipe, a person — internals may differ (image, map, video), and they are not steps that must be read in order. Heterogeneous plus independently consumable is when a card earns its frame.
Checkout steps, a batch of mail, rows of one table are neither independent nor heterogeneous. Framing them sets the box against sequence and against comparison. Masonry is about packing variable-height media, which is a different question from “is this one object.”
Why it happens
A frame is common region: whatever sits inside is seen as one object first. Object-hood helps “pick one and use it.” It hurts “compare down a column of fields,” because the frame breaks cross-card column alignment. Heterogeneous stuff will not sit in table cells (a map and a video share no schema). Cards let each unit keep its own internals, and in exchange you lose cross-item scanning.
Independent consumption means the unit still makes sense with neighbours hidden. If sense depends on “this is step three” or “this continues the card on the left,” the frame is lying.
Where it stops holding
Dashboard metric tiles look like cards but often exist to compare numbers side by side; they are framed cells. When comparison is the job, weaken the frame and align the numbers into columns. Media browsing may use cards as shells; if height follows the image all the way, you have slid into masonry, and reading-order problems live there.
A handful of heterogeneous objects almost always wants cards. Hundreds of same-schema objects, even if each can be opened alone, will have comparison and scanning outweigh object-hood.
Applying it
- Ask two questions: with the others hidden, can this unit be understood and acted on? Do the internals share one schema? If the first is no or the second is yes, cards should not be the primary layout.
- On surfaces that do use cards, put the primary key (image or title) fully inside the frame, and put the action on that card, rather than requiring a page-level toolbar to “consume” it.
- How to check: print the set, show one card at a time to someone new to the product, and ask what it is and what they can do. If they cannot name the object, or they ask what came before, the card is faking independence. Then pull the same-schema ones into a table and see whether comparison gets immediately easier — if it does, they should not live as cards.