Back to compare picker

Card list vs List view vs Collection vs Browse by category

Choose card list when each item needs a bounded container with mixed content such as preview media, title, summary, metadata, status, and one or two item-scoped actions, while a single-column reading order remains important.

Decision dimensions

Dimension Card listList viewCollectionBrowse by category
UI or UX UI + UX - Single-column sequence of bounded rich object summariesUI + UX - Vertical object-summary browsing surfaceUI + UX - Named, purposeful set of items with collection-level metadata and membership behaviorUI + UX - Taxonomy-based category navigation for exploring a collection before choosing a destination
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.Render a labelled vertical list where each row has a strong primary label, concise supporting text, metadata, status, optional leading media, and row-scoped actions with clear hit targets.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 categories as a scannable list or grid with user-facing names, short descriptions, item counts or example contents, and clear parent-child location cues.
UX guidance Use card list when users browse rich object summaries and need enough context to choose or act without opening every item.Use list view when scanning and opening object summaries is faster than comparing columns or inspecting large visual cards.Use collection when the set itself is meaningful and users need to save, curate, share, revisit, sequence, or manage item membership.Use browse by category when users can recognize a topic or service area but may not know the exact query, item name, or filter value.
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.A ticket list row shows TCK-2048 Database backup failed, a one-line incident summary, Critical status, owner, updated time, selected state, and a labelled More actions menu.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 services page lists Benefits, Housing and local services, Money and tax, and Driving and transport with one-line descriptions and top tasks for each category.
Bad UI Every card uses a different layout, so deadline, owner, status, and actions appear in different places.A list row shows columns of owner, amount, due date, and status but no headers or column sort state.A page shows cards named Resources, More, Useful, and Links with no collection title, purpose, count, or ownership.A category grid uses internal teams such as Operations, CX, Growth, Platform, and Enablement without saying what users can find there.
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.A user filters tickets to Critical, selects two rows, opens the details panel for one ticket, then clears the filter and the selected count and active ticket remain understandable.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 who does not know the form name chooses Money and tax, sees Self Assessment and VAT subcategories, and reaches the correct service without writing a search query.
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.A user selects rows, changes sort order, and the bulk action count still includes hidden rows without saying which rows are affected.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.Users choose Customers because they need customer support, but the category contains only internal CRM configuration articles.
Best fit Users need to browse rich object summaries with preview, summary text, metadata, status, and actions.Users need to scan and act on a collection of objects using compact summaries.Users need to save, curate, share, revisit, sequence, or maintain explicit items as a meaningful set.Users are exploring a broad catalog, service directory, help center, learning library, product collection, or content repository.
Avoid when The content is dense and homogeneous enough for a compact list view.Users need to compare many records across shared attributes.The set is only a temporary search result or filtered query.The collection is small enough for a simple list.
Required state Default card list with heading or label, result count, and visible card summaries.Default list state with label or heading, row count or context, visible row summaries, and primary row identity.Default collection state with title, description, owner or source, item count, visibility, updated time, and primary action.Top-level category state with clear names, descriptions, and enough examples or counts to choose.
Accessibility burden Use a real list or region with a heading for the card sequence.Use semantic list markup for ordinary object lists; use listbox only when rows are options in a single control.Use a heading and concise description that name the collection and explain its purpose before item navigation begins.Use real links for categories that navigate and buttons only for local expansion.
Common misuse Using cards as decorative wrappers for dense rows.Using list view as a table without column headers or column-state feedback.Treating any grid of cards as a collection without collection identity or membership behavior.Using the organization chart as the category taxonomy.

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.

List view

UI or UX
UI + UX - Vertical object-summary browsing surface
UI guidance
Render a labelled vertical list where each row has a strong primary label, concise supporting text, metadata, status, optional leading media, and row-scoped actions with clear hit targets.
UX guidance
Use list view when scanning and opening object summaries is faster than comparing columns or inspecting large visual cards.
Good UI
A ticket list row shows TCK-2048 Database backup failed, a one-line incident summary, Critical status, owner, updated time, selected state, and a labelled More actions menu.
Bad UI
A list row shows columns of owner, amount, due date, and status but no headers or column sort state.
Good UX
A user filters tickets to Critical, selects two rows, opens the details panel for one ticket, then clears the filter and the selected count and active ticket remain understandable.
Bad UX
A user selects rows, changes sort order, and the bulk action count still includes hidden rows without saying which rows are affected.
Best fit
Users need to scan and act on a collection of objects using compact summaries.
Avoid when
Users need to compare many records across shared attributes.
Required state
Default list state with label or heading, row count or context, visible row summaries, and primary row identity.
Accessibility burden
Use semantic list markup for ordinary object lists; use listbox only when rows are options in a single control.
Common misuse
Using list view as a table without column headers or column-state feedback.

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.

Browse by category

UI or UX
UI + UX - Taxonomy-based category navigation for exploring a collection before choosing a destination
UI guidance
Render categories as a scannable list or grid with user-facing names, short descriptions, item counts or example contents, and clear parent-child location cues.
UX guidance
Use browse by category when users can recognize a topic or service area but may not know the exact query, item name, or filter value.
Good UI
A services page lists Benefits, Housing and local services, Money and tax, and Driving and transport with one-line descriptions and top tasks for each category.
Bad UI
A category grid uses internal teams such as Operations, CX, Growth, Platform, and Enablement without saying what users can find there.
Good UX
A user who does not know the form name chooses Money and tax, sees Self Assessment and VAT subcategories, and reaches the correct service without writing a search query.
Bad UX
Users choose Customers because they need customer support, but the category contains only internal CRM configuration articles.
Best fit
Users are exploring a broad catalog, service directory, help center, learning library, product collection, or content repository.
Avoid when
The collection is small enough for a simple list.
Required state
Top-level category state with clear names, descriptions, and enough examples or counts to choose.
Accessibility burden
Use real links for categories that navigate and buttons only for local expansion.
Common misuse
Using the organization chart as the category taxonomy.
Decision rules
  • Choose card list when each item needs a bounded container with mixed content such as preview media, title, summary, metadata, status, and one or two item-scoped actions, while a single-column reading order remains important.
  • Choose list view when users need faster dense scanning of many similarly structured objects and each row can stay compact and predictable.
  • Choose collection when the set itself has a name, owner, membership, sharing, ordering, or management behavior beyond the individual item cards.
  • Choose browse by category when cards represent taxonomy destinations or topics rather than object summaries users open, select, save, or act on.
  • Card list can use cards for richer summaries, but the cards should share enough anatomy that users can compare titles, status, and primary actions without random visual hunting.
  • Do not use card list to imitate a multi-column visual gallery; when the main value is seeing many visual thumbnails at once, a grid or gallery pattern is more accurate.
  • Do not use card list when every item needs aligned numeric comparison, spreadsheet interaction, range selection, or sortable columns; table or data grid is more accurate.
  • Keep card-level primary activation distinct from secondary buttons, menus, selection controls, and destructive actions.
  • If a card contains hidden expansion, inline editing, or many actions, consider details panel, disclosure, action menu, or workflow-specific patterns instead of overloading the card.
  • On small screens, card list often works well because the single-column order is stable, but long cards must still preserve item identity, action ownership, and reachable controls.
Inspect live examples
Failure modes
  • A card list repeats the same dense fields as a table, but values are no longer aligned for comparison.
  • Cards have inconsistent anatomy, so users must relearn where title, status, date, and action controls appear on every item.
  • The whole card navigates while internal buttons also navigate or delete, causing overlapping hit targets and accidental activation.
  • A product calls the set a collection, but the cards have no collection-level owner, count, membership, or sharing behavior.
  • Category cards and object cards are mixed in one list, so users cannot tell whether they are navigating topics or opening objects.
  • Visual card chrome is added around tiny one-line rows, reducing scan density without adding useful preview or summary content.