UI + UX Data Display And Exploration standard

List view

Present objects as a vertical list of stable row summaries with a clear primary label, supporting text, metadata, status, optional leading media, row-scoped actions, selection and grouping state, and predictable behavior for sorting, filtering, pagination, virtualization, and detail handoff.

Decision first

Choose this pattern when the problem matches

Use when

  • Users need to scan and act on a collection of objects using compact summaries.
  • The item title, snippet, metadata, and status are more important than strict column comparison.
  • Rows need one primary action and a small number of row-scoped secondary actions.
  • The layout must adapt well across desktop and mobile without losing item identity.

Avoid when

  • Users need to compare many records across shared attributes.
  • Users need spreadsheet-like cell editing or grid keyboard navigation.
  • Items depend on imagery, large previews, or uneven content blocks.
  • The list is actually a form value picker.
  • Every row requires many independent controls or long multi-column detail.

Problem it prevents

Users need to scan, choose, open, and act on a set of objects, but tables overemphasize columns, card layouts waste space or depend on imagery, and dense row actions can make each item hard to identify or operate safely.

Pattern anatomy

What a strong implementation has to make clear

User need

Items are objects such as tickets, messages, files, tasks, orders, people, alerts, search results, or resources.

Pattern promise

Present objects as a vertical list of stable row summaries with a clear primary label, supporting text, metadata, status, optional leading media, row-scoped actions, selection and grouping state, and predictable behavior for sorting, filtering, pagination, virtualization, and detail handoff.

Required state

Default list state with label or heading, row count or context, visible row summaries, and primary row identity.

Recovery path

Users cannot tell which row an icon-only action will affect.

Access contract

Use semantic list markup for ordinary object lists; use listbox only when rows are options in a single control.

Quality bar

The difference between expert and weak execution

Strong implementation

Specific, visible, recoverable

  • 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 file list row shows a PDF icon, file name, folder path, modified date, sharing status, and a trailing Preview action that names the file.
  • 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 keyboard user opens a row menu, archives the ticket, and focus moves to a status message naming the archived ticket and the next row.
Weak implementation

Vague, hidden, hard to recover from

  • A list row shows columns of owner, amount, due date, and status but no headers or column sort state.
  • Every row has five unlabeled icon buttons, and the whole row also navigates.
  • A user selects rows, changes sort order, and the bulk action count still includes hidden rows without saying which rows are affected.
  • A user tries to preview a file but the row click opens navigation while the small trailing icon deletes the file.
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.
  • Use spacing, dividers, grouping labels, unread or selected markers, and responsive stacking to keep row identity and action ownership clear without turning the list into a table.
UX guidance
  • Use list view when scanning and opening object summaries is faster than comparing columns or inspecting large visual cards.
  • Preserve row identity, selection, active detail context, and scroll position as users sort, filter, paginate, refresh, or act on rows.
Implementation contract

What the implementation must handle

States

  • Default list state with label or heading, row count or context, visible row summaries, and primary row identity.
  • Focused row or focused row action state with visible focus and accessible row identity.
  • Selected row, multi-selected row, bulk-selection count, and selected-away state when selection is supported.
  • Active row state when a row controls a details panel, preview panel, route, or selected object context.

Interaction

  • Each row has one primary object identity that remains visible across selection, hover, focus, filtering, and responsive states.
  • The row's primary action, checkbox, menu, and trailing action have distinct hit targets and accessible names that include the item identity.
  • A row click opens, selects, or previews according to one stable rule; secondary actions do not conflict with that rule.
  • Selection state is not confused with focus, hover, unread, active-detail, or checked status.

Accessibility

  • Use semantic list markup for ordinary object lists; use listbox only when rows are options in a single control.
  • Give the list a heading or accessible label and expose result count, filter state, and selection count in text.
  • Ensure each row's accessible name includes the primary label and enough supporting context to identify the object.
  • Give row actions accessible names that include the row identity.

Review

  • What does one row represent and what text uniquely identifies it?
  • Is the user scanning object summaries, comparing columns, editing cells, or inspecting one selected object?
  • What is the row's primary action, and which controls are separate secondary actions?
  • Can users distinguish focus, selection, active detail, unread, pinned, disabled, and hover states?
Interactive lab

Inspect the states before you copy the pattern

Scan and act on object rows

Filter rows, sort by update time, select tickets, open a row menu, preview the active row, load more rows, inspect hidden selections, and compare fake-table, action-maze, row-conflict, lost-selection, virtual-jump, and mobile-overlap failures.

List view
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 list state with label or heading, row count or context, visible row summaries, and primary row identity.

Keyboard / Access

Tab reaches row-level controls and row actions in a predictable order without forcing users through hidden actions.

Avoid Generating

Using list view as a table without column headers or column-state feedback.

Evidence trail

Source-backed claims behind this guidance

Material Design 3: Lists

Google Material Design - checked

Material list guidance supports vertical object rows, item anatomy, supporting text, leading and trailing elements, metadata, actions, and selection.

Apple HIG: Lists and tables

Apple Developer - checked

Apple lists and tables guidance supports row organization, grouping, selection, adding, deleting, moving, disclosure, swipe actions, and platform list behavior.

Carbon Design System: Structured list

Carbon Design System - checked

Carbon structured list guidance supports scannable grouped rows, stacked row hierarchy, read-only rows, and selectable rows.

Carbon Design System: Contained list

Carbon Design System - checked

Carbon contained list guidance supports compact contained lists with headers, inline actions, interactive rows, and related content in smaller regions.

Fluent UI React: List

Microsoft Fluent 2 - checked

Fluent list guidance supports role selection, list-item actions, and keyboard navigation inside multi-action list rows.

Full agent/debug reference

Problem Context

  • Items are objects such as tickets, messages, files, tasks, orders, people, alerts, search results, or resources.
  • Users need to scan names and short summaries more than compare every item by the same set of columns.
  • Rows may include status, metadata, unread state, thumbnail or icon, selection checkbox, trailing action, row menu, swipe action, or open-detail behavior.
  • The list may be grouped, sorted, filtered, paginated, virtualized, synced with a details panel, or used as a source for bulk actions.

Selection Rules

  • Choose list view when each row is a compact object summary and users scan primarily by name, title, snippet, status, or recency.
  • Use table when aligned columns and header-to-cell comparison are central to the task.
  • Use data grid when users edit cells, navigate cells with arrow keys, select ranges, copy and paste, or operate on keyboard-managed row widgets.
  • Use details panel when the selected row needs durable adjacent detail beyond the row summary.
  • Use card list, card grid, or collection when images, previews, varied item sizes, or visual discovery are more important than dense row scanning.
  • Use feed or timeline when item order is event-centered and users consume a stream rather than manage a collection.
  • Use listbox or select when the list is a form control for choosing values rather than a browsable object surface.
  • Avoid list view when every row needs many comparable attributes that would become pseudo-columns.
  • Avoid list view when row actions are more important than identifying the item.
  • Avoid list view when rows cannot keep labels, metadata, status, and actions readable at the target viewport width.

Required States

  • Default list state with label or heading, row count or context, visible row summaries, and primary row identity.
  • Focused row or focused row action state with visible focus and accessible row identity.
  • Selected row, multi-selected row, bulk-selection count, and selected-away state when selection is supported.
  • Active row state when a row controls a details panel, preview panel, route, or selected object context.
  • Unread, new, updated, pinned, priority, archived, disabled, unavailable, or locked row states when applicable.
  • Row action menu, primary row action, secondary trailing action, swipe action, and destructive action states.
  • Grouped, sorted, filtered, searched, paginated, infinite-loaded, virtualized, and loading-more states.
  • Empty list, no-results, permission-limited, loading, partial-load, and failed-load states.
  • Narrow-screen state with stacked metadata, reachable actions, and preserved row identity.
  • Detail-open or preview-open state when list selection drives adjacent or routed detail.

Interaction Contract

  • Each row has one primary object identity that remains visible across selection, hover, focus, filtering, and responsive states.
  • The row's primary action, checkbox, menu, and trailing action have distinct hit targets and accessible names that include the item identity.
  • A row click opens, selects, or previews according to one stable rule; secondary actions do not conflict with that rule.
  • Selection state is not confused with focus, hover, unread, active-detail, or checked status.
  • Sorting and filtering update row order or membership while preserving selected rows, active detail context, and scroll position when possible.
  • Grouping labels describe meaningful sets and do not replace row-level identity.
  • Virtualized or infinite lists preserve row labels, row positions, loading boundaries, and focus restoration.
  • Bulk actions clearly state which visible or hidden selected rows are affected.

Implementation Checklist

  • Define the row object, primary label, supporting text, metadata fields, status indicators, leading media, and available row actions.
  • Choose list semantics for ordinary object rows, listbox semantics only for option selection, or grid semantics only when row interaction needs grid navigation.
  • Give the list a heading or accessible label and expose row count, active filters, and selection count near the list.
  • Keep row layout stable: primary text, secondary text, metadata, status, and actions should not jump when rows are selected, updated, or hovered.
  • Label icon-only row actions with the object identity, such as Archive ticket TCK-1042.
  • Define whether row activation opens detail, toggles selection, previews, expands, or navigates, and keep it consistent.
  • Support empty, no-results, loading, error, selected, active, unread, pinned, disabled, sorted, filtered, paginated, and virtualized states deliberately.
  • Test keyboard navigation, screen reader row identity, row action labels, selection count, virtualized focus restoration, long labels, localization, zoom, and mobile hit targets.

Common Generated-UI Mistakes

  • Using list view as a table without column headers or column-state feedback.
  • Putting too many independent controls in every row until the list becomes a keyboard trap.
  • Making the entire row, title link, checkbox, and trailing icon all trigger different undocumented actions.
  • Using color alone to show unread, selected, active, pinned, or failed rows.
  • Hiding status, owner, due date, or selection state on mobile so rows become indistinguishable.
  • Letting filters remove selected rows without explaining whether bulk actions still affect hidden selections.
  • Virtualizing rows without stable row labels, positions, loading boundaries, or focus recovery.
  • Repeating the same row summary in a details panel without adding useful detail.

Critique Questions

  • What does one row represent and what text uniquely identifies it?
  • Is the user scanning object summaries, comparing columns, editing cells, or inspecting one selected object?
  • What is the row's primary action, and which controls are separate secondary actions?
  • Can users distinguish focus, selection, active detail, unread, pinned, disabled, and hover states?
  • What happens to selected rows and active detail after sort, filter, pagination, refresh, or virtualization?
  • Would table, data grid, details panel, card layout, feed, timeline, listbox, or tree grid better fit the task?
Accessibility
  • Use semantic list markup for ordinary object lists; use listbox only when rows are options in a single control.
  • Give the list a heading or accessible label and expose result count, filter state, and selection count in text.
  • Ensure each row's accessible name includes the primary label and enough supporting context to identify the object.
  • Give row actions accessible names that include the row identity.
  • Do not nest conflicting interactive controls inside a row-level link or button.
  • Expose selected, current, expanded, disabled, unread, or busy states using appropriate native or ARIA state plus visible text.
  • Keep focus visible on both the row and individual row actions.
  • For virtualized lists, restore focus to the same object when rows mount or unmount and announce loading boundaries.
Keyboard Behavior
  • Tab reaches row-level controls and row actions in a predictable order without forcing users through hidden actions.
  • If the whole row is actionable, Enter activates the row and Space follows the chosen selection or activation model consistently.
  • If multi-action list-item keyboard navigation is used, arrow keys move between actions inside the focused row only when that behavior is documented and discoverable.
  • Arrow-key roving focus is appropriate only when the list behaves as a composite widget such as listbox or grid.
  • Selection checkboxes, row menus, trailing actions, and destructive actions remain keyboard reachable and named with the row identity.
  • After sort, filter, pagination, refresh, or action completion, focus stays on the triggering control, the same row, or a clear status summary.
  • Escape closes row menus or swipe-action panels and returns focus to the invoking row action.
Variants
  • Single-line list view
  • Two-line list view
  • Three-line list view
  • Selectable list view
  • Grouped list view
  • Search results list
  • Message list
  • File list
  • Task list
  • Notification list
  • Contained list
  • Virtualized list
  • List with detail panel
  • List with swipe actions

Verification

Last verified: