Use Compare view when users intentionally select a small set of similar items and need side-by-side attribute tradeoff support; use table, card grid, or details panel when the task is general row scanning, browsing, or inspecting one object.
Use Compare view when users intentionally select a small set of similar items and need side-by-side attribute tradeoff support; use table, card grid, or details panel when the task is general row scanning, browsing, or inspecting one object.
Practice the judgment: Imagine this situation: Compared items lose visible identity while users scroll through attributes, forcing memory work. Write the person's goal, choose one of these patterns, and show the state that helps the person continue. Use the decision rules and source trail below to explain your choice.
Review the underlying principle →| Dimension | Compare view | Table | Card grid | Details panel |
|---|---|---|---|---|
| UI or UX | UI + UX - Selected side-by-side attribute comparison of peer items | UI + UX - Semantic row-and-column data comparison surface | UI + UX - Responsive multi-column grid of peer object cards | UI + UX - Persistent selected-object inspection panel |
| UI guidance | Render compared items as a bounded side-by-side matrix with item identity, thumbnail or icon when useful, price or status, remove controls, action controls, grouped attribute rows, row labels, consistent units, missing-value notation, and difference indicators. | 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. | 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 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 Compare view when users have selected a small set of similar items and need to weigh several meaningful attributes together before choosing, saving, buying, applying, or discarding options. | Use tables when aligned columns help users compare records, find exceptions, audit values, or triage work faster than opening each item. | 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 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 laptop compare view shows three selected models as columns, grouped rows for performance, display, portability, and support, a sticky model header with price, and a differences-only switch. | 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. | 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 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 side-by-side card layout repeats marketing copy but omits shared row labels, units, missing-value marks, and difference highlighting. | Mobile stacking removes headers and turns rows into unlabeled paragraphs. | Each card has different metadata order, different action placement, and different height, making the grid look rich but hard to scan. | A panel titled Details shows metrics from the previously selected record after the list selection changes. |
| Good UX | A shopper selects three laptops, opens comparison, hides identical specs, highlights battery and memory differences, removes the weakest option, and returns to the same shortlist in the product grid. | 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 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 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 compare view resets the selected items after sorting or returning to browse, so the user must rebuild the shortlist from memory. | Mobile stacking removes headers and turns rows into unlabeled paragraphs. | A user filters to saved assets and loses selection because the product tracked selected cards by visible position rather than object ID. | Sorting the list silently clears the highlighted row while the panel continues to show an old ticket. |
| Best fit | Users need to choose among similar offerings using multiple comparable attributes. | Records share comparable attributes that users need to scan in aligned columns. | Users browse peer objects where visual preview, compact identity, and quick first-pass selection matter. | Users repeatedly inspect selected records, tickets, alerts, files, assets, tasks, comments, or locations while staying in a work surface. |
| Avoid when | Items are unique, nonexclusive, too simple, too cheap, or mostly aesthetic. | The task depends on rich previews, imagery, or uneven metadata. | Users need dense scanning of many text-heavy records. | The content is just a short temporary preview before navigation. |
| Required state | One compared item state that explains another item is needed for meaningful comparison. | Default table state with caption, visible headers, row values, and result count or context. | Default grid with heading or label, result count, active view controls, and at least one full row of peer cards. | Selected-object state with source item highlighted and panel title naming the same object. |
| Accessibility burden | Expose comparison title, selected item count, maximum item count, item names, row labels, group headings, units, and missing-value meanings as text. | Use native table semantics for tabular data rather than div-only rows. | Give the grid or list a heading, result count, and concise description of active filters or sort order. | Name the panel region from the selected object's title or a heading that includes the object identity. |
| Common misuse | Allowing too many compared items so columns become unreadable. | Using table markup to create page columns or layout spacing. | Using card grid as decorative chrome for rows that need dense scanning or aligned comparison. | Keeping the previous ticket summary in the persistent panel after the highlighted row has moved to a different ticket. |