Back to compare picker

Card grid vs Card list vs Collection vs Table

Choose card grid when users benefit from seeing several peer objects at once and the card's preview, title, price, status, or compact metadata are enough for first-pass selection.

Decision dimensions

Dimension Card gridCard listCollectionTable
UI or UX UI + UX - Responsive multi-column grid of peer object cardsUI + UX - Single-column sequence of bounded rich object summariesUI + UX - Named, purposeful set of items with collection-level metadata and membership behaviorUI + UX - Semantic row-and-column data comparison surface
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.Render each item as a bounded card with a stable anatomy: preview or icon, title, concise summary, metadata, status, and one clear primary action or activation target.Render a collection header with the collection title, concise description, item count, owner or source, visibility, last updated state, and primary collection actions before the item surface.Render a table with a specific caption or heading, visible column headers, optional row headers, aligned values, consistent row actions, and enough spacing for scanability.
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.Use card list when users browse rich object summaries and need enough context to choose or act without opening every item.Use collection when the set itself is meaningful and users need to save, curate, share, revisit, sequence, or manage item membership.Use tables when aligned columns help users compare records, find exceptions, audit values, or triage work faster than opening each item.
Good UI 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 grant-opportunity card shows program name, eligibility summary, deadline, award range, status, agency, and a labelled Save action in the same position on every card.A launch-assets collection shows title, description, 4 items, owner, shared-with-team state, sections for Read first and Assets, and item cards with type, status, and remove actions.A payment review table has the caption June vendor payments, headers Vendor, Status, Due date, Amount, and Action, right-aligned amounts, and row actions labelled by vendor.
Bad UI A grid mixes landscape images, portrait images, text-only cards, and action tiles without reserving preview space or explaining missing media.Every card uses a different layout, so deadline, owner, status, and actions appear in different places.A page shows cards named Resources, More, Useful, and Links with no collection title, purpose, count, or ownership.A div layout looks like columns but has no caption, table semantics, or header associations.
Good UX 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 user filters opportunities to Closing soon, saves two cards, expands one summary, changes sort order, and the saved count and card identities remain clear.A user adds a training module to a cloud-migration collection, reorders it into the first section, shares the collection link, and sees a confirmation that the item remains in the collection.A user sorts by Amount descending, filters to Pending, moves to page 2, and the table keeps its caption, active sort, active filter, row count, and selected payment context.
Bad UX 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 clicks inside a card to select text but the whole card opens, while a nearby icon deletes the item with no item name.A user filters a collection to videos, removes one visible item, and later discovers the product only cleared the filter instead of removing the item from the collection.Filtering the table removes selected rows without explaining why or offering a clear-filter path.
Best fit Users browse peer objects where visual preview, compact identity, and quick first-pass selection matter.Users need to browse rich object summaries with preview, summary text, metadata, status, and actions.Users need to save, curate, share, revisit, sequence, or maintain explicit items as a meaningful set.Records share comparable attributes that users need to scan in aligned columns.
Avoid when Users need dense scanning of many text-heavy records.The content is dense and homogeneous enough for a compact list view.The set is only a temporary search result or filtered query.The content is layout, not data.
Required state Default grid with heading or label, result count, active view controls, and at least one full row of peer cards.Default card list with heading or label, result count, and visible card summaries.Default collection state with title, description, owner or source, item count, visibility, updated time, and primary action.Default table state with caption, visible headers, row values, and result count or context.
Accessibility burden Give the grid or list a heading, result count, and concise description of active filters or sort order.Use a real list or region with a heading for the card sequence.Use a heading and concise description that name the collection and explain its purpose before item navigation begins.Use native table semantics for tabular data rather than div-only rows.
Common misuse Using card grid as decorative chrome for rows that need dense scanning or aligned comparison.Using cards as decorative wrappers for dense rows.Treating any grid of cards as a collection without collection identity or membership behavior.Using table markup to create page columns or layout spacing.

Card grid

UI or UX
UI + UX - Responsive multi-column grid of peer object cards
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.
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.
Good UI
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.
Bad UI
A grid mixes landscape images, portrait images, text-only cards, and action tiles without reserving preview space or explaining missing media.
Good UX
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.
Bad UX
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.
Best fit
Users browse peer objects where visual preview, compact identity, and quick first-pass selection matter.
Avoid when
Users need dense scanning of many text-heavy records.
Required state
Default grid with heading or label, result count, active view controls, and at least one full row of peer cards.
Accessibility burden
Give the grid or list a heading, result count, and concise description of active filters or sort order.
Common misuse
Using card grid as decorative chrome for rows that need dense scanning or aligned comparison.

Card list

UI or UX
UI + UX - Single-column sequence of bounded rich object summaries
UI guidance
Render each item as a bounded card with a stable anatomy: preview or icon, title, concise summary, metadata, status, and one clear primary action or activation target.
UX guidance
Use card list when users browse rich object summaries and need enough context to choose or act without opening every item.
Good UI
A grant-opportunity card shows program name, eligibility summary, deadline, award range, status, agency, and a labelled Save action in the same position on every card.
Bad UI
Every card uses a different layout, so deadline, owner, status, and actions appear in different places.
Good UX
A user filters opportunities to Closing soon, saves two cards, expands one summary, changes sort order, and the saved count and card identities remain clear.
Bad UX
A user clicks inside a card to select text but the whole card opens, while a nearby icon deletes the item with no item name.
Best fit
Users need to browse rich object summaries with preview, summary text, metadata, status, and actions.
Avoid when
The content is dense and homogeneous enough for a compact list view.
Required state
Default card list with heading or label, result count, and visible card summaries.
Accessibility burden
Use a real list or region with a heading for the card sequence.
Common misuse
Using cards as decorative wrappers for dense rows.

Collection

UI or UX
UI + UX - Named, purposeful set of items with collection-level metadata and membership behavior
UI guidance
Render a collection header with the collection title, concise description, item count, owner or source, visibility, last updated state, and primary collection actions before the item surface.
UX guidance
Use collection when the set itself is meaningful and users need to save, curate, share, revisit, sequence, or manage item membership.
Good UI
A launch-assets collection shows title, description, 4 items, owner, shared-with-team state, sections for Read first and Assets, and item cards with type, status, and remove actions.
Bad UI
A page shows cards named Resources, More, Useful, and Links with no collection title, purpose, count, or ownership.
Good UX
A user adds a training module to a cloud-migration collection, reorders it into the first section, shares the collection link, and sees a confirmation that the item remains in the collection.
Bad UX
A user filters a collection to videos, removes one visible item, and later discovers the product only cleared the filter instead of removing the item from the collection.
Best fit
Users need to save, curate, share, revisit, sequence, or maintain explicit items as a meaningful set.
Avoid when
The set is only a temporary search result or filtered query.
Required state
Default collection state with title, description, owner or source, item count, visibility, updated time, and primary action.
Accessibility burden
Use a heading and concise description that name the collection and explain its purpose before item navigation begins.
Common misuse
Treating any grid of cards as a collection without collection identity or membership behavior.

Table

UI or UX
UI + UX - Semantic row-and-column data comparison surface
UI guidance
Render a table with a specific caption or heading, visible column headers, optional row headers, aligned values, consistent row actions, and enough spacing for scanability.
UX guidance
Use tables when aligned columns help users compare records, find exceptions, audit values, or triage work faster than opening each item.
Good UI
A payment review table has the caption June vendor payments, headers Vendor, Status, Due date, Amount, and Action, right-aligned amounts, and row actions labelled by vendor.
Bad UI
A div layout looks like columns but has no caption, table semantics, or header associations.
Good UX
A user sorts by Amount descending, filters to Pending, moves to page 2, and the table keeps its caption, active sort, active filter, row count, and selected payment context.
Bad UX
Filtering the table removes selected rows without explaining why or offering a clear-filter path.
Best fit
Records share comparable attributes that users need to scan in aligned columns.
Avoid when
The content is layout, not data.
Required state
Default table state with caption, visible headers, row values, and result count or context.
Accessibility burden
Use native table semantics for tabular data rather than div-only rows.
Common misuse
Using table markup to create page columns or layout spacing.
Decision rules
  • Choose card grid when users benefit from seeing several peer objects at once and the card's preview, title, price, status, or compact metadata are enough for first-pass selection.
  • Choose card list when users need a linear reading order, longer summaries, richer mixed metadata, or mobile-first triage where one object should dominate each row.
  • Choose collection when the item set itself has a title, owner, membership rule, sharing state, ordering, sections, or add and remove behavior independent of card layout.
  • Choose table when users need aligned comparison of dates, amounts, owners, statuses, scores, inventory, or other repeated fields across many rows.
  • Use card grid only when card anatomy is consistent enough that users can scan the same title, visual, metadata, state, and action positions across every tile.
  • Avoid card grid when variable image ratios, long titles, and uneven metadata create a masonry wall that hides important differences or breaks keyboard order.
  • Use responsive column counts, minimum tile widths, stable gutters, and predictable reflow so the same result set remains recognizable from desktop to phone.
  • Keep grid-level controls such as filters, sort, density, result count, selected count, and load-more behavior outside individual cards.
  • Do not use card grid as a substitute for a category taxonomy; category cards should be handled by browse by category when each card is a navigation destination.
  • Do not use card grid for spreadsheet work, bulk editing, precise numeric ranking, or cell-level actions that require data grid or table behavior.
Inspect live examples
Failure modes
  • A card grid asks users to compare prices and deadlines, but those values appear in different vertical positions on every card.
  • The layout changes from four columns to one column without preserving selected, focused, or saved item state.
  • A product calls a visual grid a collection even though there is no collection title, owner, membership, sharing, or ordering behavior.
  • The grid contains mixed category cards, product cards, and action cards, so users cannot predict whether a tile opens an object or navigates a topic.
  • Infinite loading appends cards without updating counts, focus placement, or screen-reader feedback.
  • Missing thumbnails collapse card height and cause row wrapping, visual jumps, and confusing keyboard order.