UI + UX Data Display And Exploration established

Compare view

Provide a bounded Compare view where users intentionally add similar items, see them side by side across consistent grouped attributes, hide or highlight differences, keep item identity visible while scrolling, remove or swap candidates, and act on the chosen item without losing the shortlist.

Decision first

Choose this pattern when the problem matches

Use when

  • Users need to choose among similar offerings using multiple comparable attributes.
  • Users have already narrowed a larger result set to a small shortlist.
  • The product can provide consistent, meaningful, current attribute values across compared items.
  • The interface can preserve item identity, selected items, row labels, and differences across scroll and viewport changes.

Avoid when

  • Items are unique, nonexclusive, too simple, too cheap, or mostly aesthetic.
  • Users need to scan, sort, edit, or export many records.
  • The comparable attributes are missing, inconsistent, stale, or not decision-relevant.
  • The product cannot preserve selected-item state or provide a mobile-appropriate comparison strategy.
  • A single filter criterion should eliminate options before comparison is useful.

Problem it prevents

Users need to choose among similar offerings with many attributes, but browsing cards, opening detail pages, or scanning a large table forces memory work and makes tradeoffs between nonadjacent items hard to judge.

Pattern anatomy

What a strong implementation has to make clear

User need

Items are similar enough to share meaningful attributes, such as products, plans, locations, services, courses, vendors, devices, loans, or saved options.

Pattern promise

Provide a bounded Compare view where users intentionally add similar items, see them side by side across consistent grouped attributes, hide or highlight differences, keep item identity visible while scrolling, remove or swap candidates, and act on the chosen item without losing the shortlist.

Required state

No compared items state with instructions for adding items and a route back to browse.

Recovery path

Users compare by memory across separate detail pages because there is no shortlist or side-by-side surface.

Access contract

Expose comparison title, selected item count, maximum item count, item names, row labels, group headings, units, and missing-value meanings as text.

Quality bar

The difference between expert and weak execution

Strong implementation

Specific, visible, recoverable

  • 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 plan comparison view keeps plan names, monthly cost, primary action, and remove buttons visible while users scroll through included limits and service features.
  • 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 mobile user compares only two saved plans at a time, switches which item is visible in the second column, and keeps plan identity and price pinned above the attributes.
Weak implementation

Vague, hidden, hard to recover from

  • A comparison page shows seven products in tiny columns with paragraphs in every cell, no row grouping, no sticky headers, and no way to remove one item.
  • A side-by-side card layout repeats marketing copy but omits shared row labels, units, missing-value marks, and difference highlighting.
  • A user must open three product detail pages in separate tabs and remember battery, weight, and warranty values because the site has no comparison view.
  • A compare view resets the selected items after sorting or returning to browse, so the user must rebuild the shortlist from memory.
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.
  • Keep compared item identity visible during long comparisons through sticky column headers, repeated compact headers, pinned item cards, or a persistent selected-item tray.
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.
  • Help users reduce cognitive load by limiting the number of compared items, hiding identical attributes, highlighting differences, grouping related specs, preserving selected items, and offering a route back to browsing.
Implementation contract

What the implementation must handle

States

  • No compared items state with instructions for adding items and a route back to browse.
  • One compared item state that explains another item is needed for meaningful comparison.
  • Full comparison state with item headers, grouped attribute rows, actions, row labels, and selected-item count.
  • Maximum item limit reached state with a clear remove or replace path.

Interaction

  • Compared columns represent user-selected or explicitly preselected peer items, and the view states the item count and comparison limit.
  • Each row compares the same attribute across items using consistent labels, units, formatting, and missing-value rules.
  • Hide-identical and highlight-differences controls update row visibility or row emphasis without changing the selected items.
  • Removing, swapping, saving, or returning to browse preserves the remaining shortlist and the user's place in the originating list or grid when possible.

Accessibility

  • Expose comparison title, selected item count, maximum item count, item names, row labels, group headings, units, and missing-value meanings as text.
  • Use table semantics or equivalent row and column associations when the comparison is a matrix of attributes and items.
  • Keep item headers and row labels available to screen-reader and keyboard users even when visually sticky or horizontally scrolled.
  • Make add, remove, replace, hide-identical, highlight-differences, group collapse, save, share, export, and choose controls keyboard operable.

Review

  • What decision are users making, and which attributes genuinely influence that decision?
  • Are the compared items similar enough for row-by-row comparison and mutually exclusive enough to justify choosing among them?
  • Can users see item identity, price or status, row labels, units, and differences while scrolling?
  • What is the item limit, and how do users remove, replace, or add candidates?
Interactive lab

Inspect the states before you copy the pattern

Compare a selected shortlist

Add and remove laptop candidates, hide identical rows, highlight differences, pin item identity, switch mobile pair mode, group specs, export the shortlist, and compare too-many-items, hidden-compare, no-sticky, identical-clutter, inconsistent-specs, mobile-crush, and lost-shortlist failures.

Compare 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

No compared items state with instructions for adding items and a route back to browse.

Keyboard / Access

Tab reaches compare-selection controls in source results, selected-item tray, comparison controls, item remove buttons, item actions, group toggles, and return-to-browse control.

Avoid Generating

Allowing too many compared items so columns become unreadable.

Evidence trail

Source-backed claims behind this guidance

Full agent/debug reference

Problem Context

  • Items are similar enough to share meaningful attributes, such as products, plans, locations, services, courses, vendors, devices, loans, or saved options.
  • Users are in a shortlisting phase after search, browse, filtering, or saved-item collection and need to make a compensatory decision across several criteria.
  • The attribute set may be longer than a card can show, and some attributes matter only to a subset of users.
  • The view may be static with preselected options or dynamic with user-selected candidates from a list, grid, search result, or saved view.
  • Mobile and narrow layouts make the full matrix difficult, so the product needs item-count limits, attribute subsets, paired comparison, or a saved shortlist fallback.

Selection Rules

  • Choose Compare view when users need to evaluate a small number of similar items across the same attributes.
  • Use Compare view after users have narrowed candidates through search, filter, category browsing, recommendations, favorites, or saved items.
  • Use table when the main task is scanning many records, auditing values, sorting rows, or exporting the dataset rather than comparing a selected shortlist.
  • Use card grid or card list when users are still discovering candidates and do not need aligned attribute tradeoffs.
  • Use details panel when users need to inspect one selected item while staying in a list, grid, map, or board.
  • Use data grid when users need to edit values, reorder columns extensively, or navigate cells like a spreadsheet.
  • Use filters or facets when one nonnegotiable attribute should eliminate items before comparison.
  • Avoid Compare view when items are not mutually exclusive, too cheap or simple to justify comparison, mostly aesthetic, or too unique to share useful attributes.
  • Limit comparison to a small set, usually two to five items on desktop and fewer on mobile.
  • Do not hide important differences behind hover-only cells, collapsed rows, or marketing-only labels.

Required States

  • No compared items state with instructions for adding items and a route back to browse.
  • One compared item state that explains another item is needed for meaningful comparison.
  • Full comparison state with item headers, grouped attribute rows, actions, row labels, and selected-item count.
  • Maximum item limit reached state with a clear remove or replace path.
  • Differences highlighted, identical rows hidden, attribute group collapsed, attribute group expanded, and all attributes restored states.
  • Item removed, item swapped, item unavailable, missing attribute, stale price or status, loading attributes, and failed attribute load states.
  • Mobile pair comparison, horizontal-scroll comparison, sticky header, and selected-item tray states.
  • Return-to-browse, save comparison, share comparison, export comparison, and choose item states.

Interaction Contract

  • Compared columns represent user-selected or explicitly preselected peer items, and the view states the item count and comparison limit.
  • Each row compares the same attribute across items using consistent labels, units, formatting, and missing-value rules.
  • Hide-identical and highlight-differences controls update row visibility or row emphasis without changing the selected items.
  • Removing, swapping, saving, or returning to browse preserves the remaining shortlist and the user's place in the originating list or grid when possible.
  • Sticky item headers, row labels, and group headings preserve orientation while users scroll vertically or horizontally.
  • Mobile comparison either limits columns, lets users choose a pair or subset, or provides a saved-item fallback instead of squeezing the full matrix unreadably.
  • Action buttons such as Choose, Buy, Apply, Save, or Contact are tied to the correct compared item and remain distinguishable from remove controls.
  • The view explains unavailable, stale, missing, estimated, normalized, or vendor-supplied attributes before users rely on the comparison.

Implementation Checklist

  • Define comparable item type, maximum item count, required attributes, optional attributes, groups, units, missing-value notation, primary action, and return-to-browse state.
  • Add compare affordances to source cards or rows with persistent labels, keyboard access, and a selected-item reminder or tray.
  • Render comparison with item headers as columns, attributes as rows, grouped sections, sticky identity, row separators, and responsive behavior.
  • Implement remove, replace, hide-identical, highlight-differences, group collapse, save, share, export, and choose actions with clear focus management.
  • Model empty, one-item, max-items, missing attributes, stale attributes, unavailable item, loading, failed-load, mobile, and horizontal overflow states.
  • Keep selected items keyed by object ID rather than visible index so filtering, sorting, reordering, and returning to browse do not corrupt the shortlist.
  • Test with long item names, long attribute labels, mixed units, missing values, duplicate names, many groups, narrow screens, keyboard, zoom, and high contrast.
  • Provide a table, data grid, or details handoff when users need exact row work, many records, editing, or deep per-item inspection.

Common Generated-UI Mistakes

  • Allowing too many compared items so columns become unreadable.
  • Using inconsistent labels, units, or attribute availability across compared items.
  • Showing long marketing paragraphs instead of concise comparable values.
  • Hiding compare selection behind hover-only controls.
  • Dropping item names, prices, or key status when users scroll.
  • Failing to hide or highlight identical rows, forcing users to search manually for differences.
  • Treating a general table, details page, or card grid as a Compare view without selected-item management.
  • Removing selected items when users return to browse, filter, sort, or change viewport.

Critique Questions

  • What decision are users making, and which attributes genuinely influence that decision?
  • Are the compared items similar enough for row-by-row comparison and mutually exclusive enough to justify choosing among them?
  • Can users see item identity, price or status, row labels, units, and differences while scrolling?
  • What is the item limit, and how do users remove, replace, or add candidates?
  • How does the view behave with missing attributes, identical attributes, stale values, and mobile width?
  • Would a table, card grid, details panel, filter panel, or saved list better match the user's stage?
Accessibility
  • Expose comparison title, selected item count, maximum item count, item names, row labels, group headings, units, and missing-value meanings as text.
  • Use table semantics or equivalent row and column associations when the comparison is a matrix of attributes and items.
  • Keep item headers and row labels available to screen-reader and keyboard users even when visually sticky or horizontally scrolled.
  • Make add, remove, replace, hide-identical, highlight-differences, group collapse, save, share, export, and choose controls keyboard operable.
  • Do not rely only on color to highlight differences; pair highlighting with labels, icons, text, or difference summaries.
  • Announce selected-item count changes, max-limit errors, rows hidden, differences highlighted, item removed, and attribute load failures.
  • Ensure mobile or narrow layouts preserve header-cell relationships rather than turning values into unlabeled text.
Keyboard Behavior
  • Tab reaches compare-selection controls in source results, selected-item tray, comparison controls, item remove buttons, item actions, group toggles, and return-to-browse control.
  • Enter or Space toggles add to compare, hide identical, highlight differences, group expansion, save, remove, replace, and item action controls.
  • After adding or removing an item, focus remains on the invoking control, selected-item tray, or next sensible compared item with an announced count change.
  • Keyboard users can move through row labels, item headers, and values without losing which item and attribute they are reading.
  • Horizontal scroll regions, sticky headers, and paired mobile selectors are keyboard operable.
  • Escape closes attribute notes, item swap menus, or overflow menus and returns focus to the invoking control.
Variants
  • Static comparison table
  • Dynamic selected-item compare view
  • Two-item mobile compare view
  • Differences-only compare view
  • Highlighted-differences compare view
  • Grouped-spec comparison
  • Plan comparison
  • Product comparison
  • Vendor comparison
  • Saved shortlist comparison
  • Compare view with sticky headers
  • Compare view with item swap

Verification

Last verified: