UX Patterns Guide
UI + UX Data Display And Exploration established

Card grid

Present the objects as a responsive card grid with consistent card anatomy, stable preview dimensions, predictable column reflow, grid-level controls, clear selected and saved states, loading and empty states, keyboard order that matches visual order, and explicit alternatives for dense comparison tasks.

Open in lab Compare alternatives
Decision first

Choose this pattern when the problem matches

Use when

  • Users browse peer objects where visual preview, compact identity, and quick first-pass selection matter.
  • Several cards should be visible at the same time, especially on desktop or tablet.
  • Items share enough structure for consistent tile anatomy and responsive reflow.
  • The grid can support selection, saving, loading, filtering, sorting, and responsive states without losing object identity.

Avoid when

  • Users need dense scanning of many text-heavy records.
  • Users need aligned numeric or date comparison across many items.
  • Each item needs long explanatory copy or a linear reading sequence.
  • The item set has collection-level ownership, membership, sharing, ordering, or curation behavior.
  • Preview media is mostly absent, untrustworthy, or too inconsistent to help selection.

Problem it prevents

Users need to browse many peer objects where visual preview, compact metadata, and quick selection matter, but a vertical card list is too slow, a table overemphasizes columns, and a named collection would imply membership management that is not present.

Pattern anatomy

What a strong implementation has to make clear

User need

Items are peer objects such as products, courses, files, templates, assets, locations, people, articles, media, reports, or examples.

Pattern promise

Present the objects as a responsive card grid with consistent card anatomy, stable preview dimensions, predictable column reflow, grid-level controls, clear selected and saved states, loading and empty states, keyboard order that matches visual order, and explicit alternatives for dense comparison tasks.

Required state

Default grid with heading or label, result count, active view controls, and at least one full row of peer cards.

Recovery path

Cards with long titles stretch rows while neighboring cards hide status and actions below the fold.

Access contract

Give the grid or list a heading, result count, and concise description of active filters or sort order.

Quality bar

The difference between expert and weak execution

Strong implementation

Specific, visible, recoverable

  • A course catalog grid shows four cards per row on desktop, each with the same image ratio, course title, provider, level, duration, saved state, and Enroll action.
  • A media asset grid shows thumbnail, file type, usage rights, modified date, selected checkbox, and a More actions button in the same place on every card.
  • A shopper filters a product grid to In stock, switches from comfortable to compact density, selects three items, and the selected count and item positions remain understandable.
  • A keyboard user tabs through card title, Save, checkbox, and More actions while the visual row and column order match the reading order.
Weak implementation

Vague, hidden, hard to recover from

  • A grid mixes landscape images, portrait images, text-only cards, and action tiles without reserving preview space or explaining missing media.
  • Each card has different metadata order, different action placement, and different height, making the grid look rich but hard to scan.
  • A user tries to compare course prices, but every card wraps the price under different text lengths and the grid gives no sort or table alternative.
  • A user filters to saved assets and loses selection because the product tracked selected cards by visible position rather than object ID.
UI guidance
  • Arrange peer object cards in a responsive grid with stable tile widths, predictable gutters, consistent preview aspect ratios, titles, compact metadata, state labels, and one primary action area.
  • Keep grid-level controls such as filters, sort, result count, selected count, density, pagination, and loading status outside the cards so each tile stays focused on one object.
UX guidance
  • Use card grid when users need visual browsing, light comparison, and quick selection across many peer objects that can be understood from compact card summaries.
  • Preserve object identity, selected state, saved state, focus, and result position as the grid changes column count, loads more cards, filters, sorts, or switches density.
Implementation contract

What the implementation must handle

States

  • Default grid with heading or label, result count, active view controls, and at least one full row of peer cards.
  • Card default, hover, focus, active, selected, saved, unavailable, loading, failed-thumbnail, missing-thumbnail, disabled, and opened states.
  • Grid filtered, sorted, searched, compact density, comfortable density, loading-more, paginated, empty, no-results, and failed-load states.
  • Responsive one-column, two-column, three-column, and wide multi-column states with stable gutters and preserved card order.

Interaction

  • Each card represents one object and keeps title, preview, key metadata, state, and actions in the same relative positions across cards.
  • Visual order, DOM order, keyboard order, and screen-reader order remain consistent after responsive reflow.
  • Card activation, selection, save, overflow, and destructive actions have separate hit targets and accessible names that include the object title.
  • Grid-level filters, sort controls, density switches, pagination, and load-more controls update counts and preserve object-keyed selected, saved, and focused state.

Accessibility

  • Give the grid or list a heading, result count, and concise description of active filters or sort order.
  • Keep DOM order and keyboard order aligned with visual row-major order after responsive reflow.
  • Use accessible names for card links, Save, Select, More, Remove, and destructive actions that include the object title.
  • Do not rely on image, color, position, hover, or card shape alone to communicate type, state, selected status, or availability.

Review

  • What does the grid reveal by showing several cards at once that a card list would slow down?
  • Are users visually browsing peer objects, managing a named collection, navigating categories, or comparing columns?
  • Which fields must appear in the same place on every card for scanning to work?
  • How does the grid preserve selected, saved, focused, and acted-on cards after filtering, sorting, loading, and breakpoint changes?
Interactive lab

Inspect the states before you copy the pattern

Browse peer objects in a responsive card grid

Change density, filter available items, select and save cards, load more, inspect missing-thumbnail fallback, and compare masonry-order, comparison-trap, index-selection, hover-only, collapsed-thumbnail, and mixed-card-role failures.

Card grid
Interactive demo is ready

Launch the live UI/UX lab when you want to inspect states, keyboard behavior, and common failure modes.

State To Inspect

Default grid with heading or label, result count, active view controls, and at least one full row of peer cards.

Keyboard / Access

Tab reaches grid controls, the first card's activation, card actions, selection controls, bulk actions, pagination, and load-more controls in predictable order.

Avoid Generating

Using card grid as decorative chrome for rows that need dense scanning or aligned comparison.
Evidence trail

Source-backed claims behind this guidance

React Spectrum CardView

Adobe - checked

Supports card collection behavior, selection, keyboard navigation, dynamic rendering, and loading behavior.

Material Design Cards

Google Material Design - checked

Supports card content and actions around one topic with scan-friendly summaries.

Primer Brand Card

GitHub Primer - checked

Supports card groups, consistent image treatment, content-length constraints, and stacking at smaller viewports.

Cards: UI-Component Definition

Nielsen Norman Group - checked

Supports card components as short bounded object summaries and cautions about when cards are less suitable than dense scanning layouts.

Full agent/debug reference

Problem Context

  • Items are peer objects such as products, courses, files, templates, assets, locations, people, articles, media, reports, or examples.
  • Users choose from visual or semi-visual summaries instead of reading every item in full.
  • The result set may be filtered, sorted, searched, selected, saved, paginated, infinitely loaded, or displayed at multiple densities.
  • Cards may contain thumbnail, title, short label, rating, price, status, owner, file type, duration, tags, and one or two object actions.

Selection Rules

  • Choose card grid when users need to see multiple objects at once and visual preview or compact card identity helps them choose.
  • Choose card grid when items are peers with comparable card anatomy and no collection-level membership behavior.
  • Choose card grid when the layout can reflow across breakpoints without hiding title, preview, state, selection, or primary actions.
  • Use card list when each object requires a longer summary, more metadata, or a stronger single-column reading sequence.
  • Use collection when the item set has a title, owner, saved membership, sharing, ordering, sections, or add and remove behavior.
  • Use table or data grid when aligned attribute comparison, numeric ranking, row operations, cell editing, or dense scanning is the main task.
  • Use browse by category when each card is a topic or taxonomy destination rather than an object card.
  • Use carousel only when a small curated subset is sequentially featured and not every card needs simultaneous visibility.
  • Avoid card grid when images are decorative, missing, or inconsistent enough to dominate the layout without improving choice.
  • Avoid card grid when users need to compare exact values that would be clearer in columns.

Required States

  • Default grid with heading or label, result count, active view controls, and at least one full row of peer cards.
  • Card default, hover, focus, active, selected, saved, unavailable, loading, failed-thumbnail, missing-thumbnail, disabled, and opened states.
  • Grid filtered, sorted, searched, compact density, comfortable density, loading-more, paginated, empty, no-results, and failed-load states.
  • Responsive one-column, two-column, three-column, and wide multi-column states with stable gutters and preserved card order.
  • Selected-away, hidden selected, bulk action, saved count, item removed, item added, and restored item states when selection or saving is supported.
  • Long title, missing image, mixed media type, permission-limited, stale item, duplicate title, and unavailable action states.

Interaction Contract

  • Each card represents one object and keeps title, preview, key metadata, state, and actions in the same relative positions across cards.
  • Visual order, DOM order, keyboard order, and screen-reader order remain consistent after responsive reflow.
  • Card activation, selection, save, overflow, and destructive actions have separate hit targets and accessible names that include the object title.
  • Grid-level filters, sort controls, density switches, pagination, and load-more controls update counts and preserve object-keyed selected, saved, and focused state.
  • Missing images use a reserved fallback area so card height, row alignment, focus position, and action placement do not jump.
  • Column-count changes do not convert card grid behavior into a hidden carousel, a masonry layout with confusing order, or a dense table without headers.
  • Bulk actions state whether they affect visible cards, selected cards, hidden selected cards, or all matching cards.
  • When users need exact comparison, the surface offers a sort, filter, details view, compare mode, table view, or other clear path instead of forcing visual hunting.

Implementation Checklist

  • Define card anatomy: thumbnail or icon, title, secondary label, compact metadata, status, price or rating if relevant, primary action, selection control, save control, and overflow action.
  • Set grid minimum card width, maximum columns, gutters, row gaps, preview aspect ratio, title line limits, and responsive breakpoints before binding live content.
  • Render the card set as a list or grid with accessible labelling, object-keyed IDs, visible result count, selected count, saved count, and active filters.
  • Keep interactive descendants separate rather than placing multiple buttons and links inside one wrapping card button.
  • Provide stable fallbacks for missing previews, long titles, unavailable items, mixed media, duplicate names, and permission-limited cards.
  • Preserve selected, saved, expanded, focused, and recently acted-on cards across sort, filter, density change, breakpoint reflow, pagination, and loading more.
  • Offer keyboard operation for selection, save, overflow, bulk actions, load more, and any reorder or compare controls.
  • Test screen reader order, zoom, localization, high contrast, long text, reduced width, pointer target spacing, async loading, and virtualized grids.

Common Generated-UI Mistakes

  • Using card grid as decorative chrome for rows that need dense scanning or aligned comparison.
  • Allowing every card to choose its own image ratio, title placement, metadata order, and action area.
  • Treating a grid of result cards as a collection without collection identity, owner, count, or membership rules.
  • Hiding important card actions behind hover-only affordances that vanish on touch and keyboard.
  • Tracking selected cards by index, so filtering, sorting, or responsive reflow changes which object is selected.
  • Using masonry layout for task-critical keyboard navigation without a clear reading order.
  • Letting missing thumbnails collapse cards and break row alignment.
  • Putting too many visible actions in every card until the grid becomes a tab-stop maze.

Critique Questions

  • What does the grid reveal by showing several cards at once that a card list would slow down?
  • Are users visually browsing peer objects, managing a named collection, navigating categories, or comparing columns?
  • Which fields must appear in the same place on every card for scanning to work?
  • How does the grid preserve selected, saved, focused, and acted-on cards after filtering, sorting, loading, and breakpoint changes?
  • What fallback keeps missing previews from changing card height or keyboard order?
  • When exact comparison becomes important, what route to table, sort, filter, compare, or details view is provided?
Accessibility
  • Give the grid or list a heading, result count, and concise description of active filters or sort order.
  • Keep DOM order and keyboard order aligned with visual row-major order after responsive reflow.
  • Use accessible names for card links, Save, Select, More, Remove, and destructive actions that include the object title.
  • Do not rely on image, color, position, hover, or card shape alone to communicate type, state, selected status, or availability.
  • Expose selected, saved, unavailable, loading, missing-thumbnail, and failed-load states visibly and programmatically where applicable.
  • Provide focus indicators for card activation and every internal action.
  • Reserve preview space and provide text alternatives or labelled fallbacks for missing and decorative imagery.
  • Announce result-count changes, selected-count changes, loaded-more outcomes, and no-results states when they are not otherwise obvious.
Keyboard Behavior
  • Tab reaches grid controls, the first card's activation, card actions, selection controls, bulk actions, pagination, and load-more controls in predictable order.
  • Enter activates the focused card link or button, and Space toggles checkbox, save, or selection controls according to their role.
  • If arrow-key grid navigation is implemented, roving focus keeps row and column position clear and does not trap users away from normal Tab navigation.
  • Escape closes card action menus, preview overlays, or transient compare controls and returns focus to the invoking card control.
  • After filtering, sorting, selecting, saving, removing, loading more, or changing density, focus remains on the triggering control, the same object, a status message, or the next sensible card.
  • Keyboard alternatives exist for bulk selection, compare, reorder, or drag actions when those actions are supported.
Variants
  • Product card grid
  • Course card grid
  • Template gallery
  • Asset picker grid
  • Media grid
  • People card grid
  • Selectable card grid
  • Saved-card grid
  • Compact card grid
  • Responsive card gallery
  • Grid with preview panel
  • Grid with filters
  • Grid with pagination
  • Infinite card grid

Verification

Last verified: