List view vs Table vs Data grid vs Details panel

Choose list view when each item is best understood as a compact object summary with primary text, secondary text, metadata, status, thumbnail or icon, and one or two row-scoped actions.

List view live example Table live example Data grid live example Details panel live example

Decision dimensions

Dimension	List view	Table	Data grid	Details panel
UI or UX	UI + UX - Vertical object-summary browsing surface	UI + UX - Semantic row-and-column data comparison surface	UI + UX - Interactive row-and-column data workspace	UI + UX - Persistent selected-object inspection panel
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.	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.	Render the grid as a named work surface with visible headers, row identifiers, focus location, selection state, dirty and invalid cell markers, column controls, and status text for row count, sort, filter, and save state.	Render a details panel as a persistent side or adjacent region that names the currently selected object, shows high-value metadata, status, and local secondary actions, and keeps the object selection visible in the source list, table, map, board, or feed.
UX guidance	Use list view when scanning and opening object summaries is faster than comparing columns or inspecting large visual cards.	Use tables when aligned columns help users compare records, find exceptions, audit values, or triage work faster than opening each item.	Use a data grid when cell-level interaction makes users faster and more accurate than opening each record separately.	Use a details panel when users need to select and compare nearby objects while keeping a durable inspection area visible, such as reviewing records, tickets, assets, alerts, comments, files, or map locations.
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.	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.	An invoice-review grid shows frozen invoice IDs, column headers for Vendor, Amount, Due, Owner, and Status, one highlighted focused cell, two selected rows, a dirty edited amount, and a status line naming the current cell.	A ticket queue keeps TCK-2048 selected in the list and shows a right details panel with requester, severity, SLA, owner, activity, and Open full ticket.
Bad UI	A list row shows columns of owner, amount, due date, and status but no headers or column sort state.	A div layout looks like columns but has no caption, table semantics, or header associations.	A static report uses role grid even though users only read values and ordinary table semantics would be clearer.	A panel titled Details shows metrics from the previously selected record after the list selection changes.
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.	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.	A user presses Arrow Right to move from Amount to Due, presses Enter to edit the due date, presses Escape to cancel, and focus returns to the same cell in navigation mode.	A keyboard user moves down a ticket list, the highlighted row and details panel update together, and focus remains in the list until the user chooses Open full ticket.
Bad UX	A user selects rows, changes sort order, and the bulk action count still includes hidden rows without saying which rows are affected.	Filtering the table removes selected rows without explaining why or offering a clear-filter path.	A user edits an amount, sorts by status, and the row disappears with no saved or unsaved indication.	Sorting the list silently clears the highlighted row while the panel continues to show an old ticket.
Best fit	Users need to scan and act on a collection of objects using compact summaries.	Records share comparable attributes that users need to scan in aligned columns.	Users repeatedly inspect or update many records in shared columns.	Users repeatedly inspect selected records, tickets, alerts, files, assets, tasks, comments, or locations while staying in a work surface.
Avoid when	Users need to compare many records across shared attributes.	The content is layout, not data.	The data is read-only and ordinary table navigation is enough.	The content is just a short temporary preview before navigation.
Required state	Default list state with label or heading, row count or context, visible row summaries, and primary row identity.	Default table state with caption, visible headers, row values, and result count or context.	Default navigation state with labelled grid, column headers, row headers or row identifiers, focused cell, and row count context.	No selection state with a clear prompt or preserved last-selection rule.
Accessibility burden	Use semantic list markup for ordinary object lists; use listbox only when rows are options in a single control.	Use native table semantics for tabular data rather than div-only rows.	Use grid semantics only for an interactive composite widget with managed focus.	Name the panel region from the selected object's title or a heading that includes the object identity.
Common misuse	Using list view as a table without column headers or column-state feedback.	Using table markup to create page columns or layout spacing.	Using role grid on a static table only to make it sound richer.	Showing a details panel with no selected-object identity.

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.

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.

Data grid

UI or UX: UI + UX - Interactive row-and-column data workspace
UI guidance: Render the grid as a named work surface with visible headers, row identifiers, focus location, selection state, dirty and invalid cell markers, column controls, and status text for row count, sort, filter, and save state.
UX guidance: Use a data grid when cell-level interaction makes users faster and more accurate than opening each record separately.
Good UI: An invoice-review grid shows frozen invoice IDs, column headers for Vendor, Amount, Due, Owner, and Status, one highlighted focused cell, two selected rows, a dirty edited amount, and a status line naming the current cell.
Bad UI: A static report uses role grid even though users only read values and ordinary table semantics would be clearer.
Good UX: A user presses Arrow Right to move from Amount to Due, presses Enter to edit the due date, presses Escape to cancel, and focus returns to the same cell in navigation mode.
Bad UX: A user edits an amount, sorts by status, and the row disappears with no saved or unsaved indication.
Best fit: Users repeatedly inspect or update many records in shared columns.
Avoid when: The data is read-only and ordinary table navigation is enough.
Required state: Default navigation state with labelled grid, column headers, row headers or row identifiers, focused cell, and row count context.
Accessibility burden: Use grid semantics only for an interactive composite widget with managed focus.
Common misuse: Using role grid on a static table only to make it sound richer.

Details panel

UI or UX: UI + UX - Persistent selected-object inspection panel
UI guidance: Render a details panel as a persistent side or adjacent region that names the currently selected object, shows high-value metadata, status, and local secondary actions, and keeps the object selection visible in the source list, table, map, board, or feed.
UX guidance: Use a details panel when users need to select and compare nearby objects while keeping a durable inspection area visible, such as reviewing records, tickets, assets, alerts, comments, files, or map locations.
Good UI: A ticket queue keeps TCK-2048 selected in the list and shows a right details panel with requester, severity, SLA, owner, activity, and Open full ticket.
Bad UI: A panel titled Details shows metrics from the previously selected record after the list selection changes.
Good UX: A keyboard user moves down a ticket list, the highlighted row and details panel update together, and focus remains in the list until the user chooses Open full ticket.
Bad UX: Sorting the list silently clears the highlighted row while the panel continues to show an old ticket.
Best fit: Users repeatedly inspect selected records, tickets, alerts, files, assets, tasks, comments, or locations while staying in a work surface.
Avoid when: The content is just a short temporary preview before navigation.
Required state: No selection state with a clear prompt or preserved last-selection rule.
Accessibility burden: Name the panel region from the selected object's title or a heading that includes the object identity.
Common misuse: Showing a details panel with no selected-object identity.

Decision rules

Choose list view when each item is best understood as a compact object summary with primary text, secondary text, metadata, status, thumbnail or icon, and one or two row-scoped actions.
Choose table when users need to compare many records across the same visible attributes and column alignment is more important than object-summary reading.
Choose data grid when rows contain editable cells, cell navigation, range selection, keyboard-managed widgets, copy and paste, or spreadsheet-like operations.
Choose details panel when the list remains the source of selection and users need a durable adjacent region for full object detail, preview, history, or secondary workflow.
A list view can support sorting, filtering, grouping, selection, bulk actions, swipe actions, or row menus, but the row summary must remain the primary unit of scanning.
Do not use list view as a fake table by aligning many pseudo-columns without headers, sort state, or column comparison rules.
Do not use list view for dense visual browsing where card list, card grid, gallery, map, or collection layout would make imagery and variable content easier to inspect.
If rows have multiple actions, define whether the whole row opens detail, whether a trailing action is separate, how focus moves through row controls, and how action labels include row identity.
When filtering, sorting, paginating, or virtualizing list rows, preserve selected rows, scroll position, row identity, and active detail-panel context.
On mobile, list view is usually preferable to table or data grid when row summaries can stack naturally and actions can remain reachable without horizontal scrolling.

Inspect live examples

List view Table Data grid Details panel

Failure modes

A list view becomes a table without headers, so users see columns of dates, owners, and amounts with no column meaning.
Every row contains many independent buttons, menus, and inputs, forcing tabbing through a long control maze.
The whole row navigates and the trailing action also activates on the same click target, causing accidental destructive or navigation actions.
Sorting or filtering changes visible rows but selection badges, counts, and detail-panel content still describe the old list.
Rows are virtualized without stable row labels, so assistive technology users cannot tell which object is focused.
A details panel repeats the same summary already in the list instead of adding durable object detail.