skip to content

In a design system, what makes up a card's anatomy, and when should a collection use cards rather than list rows?

level: juniorimportance: should knowfreq 46%

answer

  1. container, media, title, meta, actions
  2. which parts are optional
  3. one primary target per card
  4. browse versus scan and compare
  5. same order in every card

basics

~20 s

A card is a container holding optional media, a required title, supporting metadata, optional body text and optional actions, with one primary target. Use cards to browse varied, visual items; use list rows to scan and compare many similar items.

solid answer

~40 s

A **card** groups everything about one item into a single, self-contained unit. Its anatomy is a **container**; optional **media**; a **title**, which is required and usually a heading; **metadata** such as credits, schedule and instructor; an optional short **body**; and optional **actions**. One element — usually the title — is the card's **primary target**, and every card in a collection keeps its parts in the same order so a grid can be scanned. Cards suit **browsing** varied items that each need a picture or a few attributes, like course highlights in a university registration portal. **List rows** suit **scanning and comparing** many similar items along the same attributes — a student's sections sorted by time and seats — and a table suits comparing many attributes at once.

go deeper

for a junior

Recall the parts — container, media, title, metadata, body, actions — which are optional, and that each card has one primary target.

for a middle

Explain the rules that make a collection of cards usable: title as a heading, consistent order, one primary target, few actions, informative versus decorative media.

for a senior

Judge when cards are the wrong form: comparison tasks need rows or tables, and nested or competing targets are defects to catch in review.

for a principal

Decide how the system steers teams between cards, lists and tables by task, so the product does not drift into cards everywhere because they are easy to reuse.

## What a card is for A **card** is a bounded container that presents one item — a course, an event, a person — as a self-contained unit, so a collection of them can be scanned, rearranged across screen sizes, and acted on item by item. It is not a decorative box: if the content inside is not about one item, it is not a card. ## The anatomy | Part | Required? | Purpose | Course-portal example | |---|---|---|---| | **Container** | Yes | Bounds the item, carries elevation or border | The card surface | | **Media** | Optional | Recognition, mood, or information | Department image or course thumbnail | | **Title** | Yes | Names the item; usually the primary target | 'CS 201 Data Structures' | | **Metadata** | Usually | Short facts for deciding | 4 credits · Mon/Wed 10:00 · Dr. Okafor | | **Body** | Optional | A line or two of description | 'Trees, graphs and hashing, with weekly labs' | | **Status** | Optional | Time-sensitive state | '3 seats left' | | **Actions** | Optional | Secondary operations on the item | 'Add to plan', 'Save' | Rules a design system commonly writes into the card spec: - **One primary target.** The card as a whole leads to one place — the item's detail page — normally through its title. Other actions are secondary and visibly separate. - **The title is a heading**, so screen-reader users can move from card to card by heading, and its text is short enough to be the card's name. - **Consistent order** across every card in a collection, so the eye finds the same fact in the same place. - **Informative versus decorative media.** A department photo that adds nothing gets no text alternative; a chart or diagram that carries information needs one. - **Few actions.** One or two; more belong on the detail page or in an overflow menu. - **Metadata is short and scannable**, not prose. ## Cards, list rows and tables The three collection forms answer different reading tasks. | Form | Best for | Weak at | Registration-portal example | |---|---|---|---| | **Cards** in a grid | Browsing varied items, visual recognition | Comparing many items attribute by attribute | 'Featured first-year seminars' | | **List rows** | Scanning many similar items in order | Showing rich media per item | A student's planned sections | | **Table** | Comparing many attributes across many items, sorting | Small screens, varied content | Every section of a course with time, room, seats, instructor | A useful test: if users will ask 'which of these has the earliest time and the most seats?', they need rows or a table, because a grid of cards scatters the same attribute across different positions on the screen. If they will ask 'what looks interesting?', cards fit. ## Cards across screen sizes Cards are popular partly because a grid of them reflows naturally from several columns to one. WCAG 2.2 **SC 1.4.10 Reflow** (Level AA) requires content to remain usable without two-dimensional scrolling at a width equivalent to 320 device-independent pixels — the width of a 1280-pixel viewport at 400% zoom — so a card spec should state how the grid collapses to a single column and how each card's internal layout stacks. On native mobile the same thinking applies to the platform's collection views: a card is one cell with a clear primary action. ## Common defects 1. **Several competing targets**: image, title and a 'Read more' link all lead to the same page as three separate stops. 2. **Inconsistent anatomy**: some cards put credits first, others last. 3. **Everything is a card**: whole pages of nested cards, where plain sections would read better. 4. **Card used for comparison**: forcing students to compare section times across a grid.

  • Should every card in a collection have an image?
    Only if the images help users recognise or choose items. Mixing cards with and without media makes rows uneven and shifts where the title sits, so a system usually says either all cards in a collection carry media or none do, with a neutral placeholder when an item has no image. Decorative images get no text alternative.
  • How many actions should a card carry?
    As few as possible — commonly the primary target plus one or two secondary actions. Each extra action adds a focus stop, crowds the card, and increases the chance of mis-taps near the primary target. Anything beyond that belongs on the item's detail page or in an overflow menu on the card.

A card is an index card in a course catalogue drawer: one course per card, the same fields in the same places, and you flip through them to browse. A timetable printout is the list or table you use once you need to compare.

saying these in an interview costs you the question

  • Any bordered box of content counts as a card
  • Cards are always better than lists because they look richer
  • Each card can order its parts however its content suits
  • The image, title and a 'Read more' link should all be separate links
  • Cards are a good way to compare many items attribute by attribute