RelevantSearch.AI
Pattern · Volume 07 · Section B --- Result list and snippet design · Updated May 2026

Result card design with query-aware snippets and highlighting

Source: Production methodology at major search teams; Elasticsearch / OpenSearch highlighter documentation; WCAG 2.1 accessibility patterns

Classification — Pattern for designing result cards that surface ranked retrieval results with appropriate per-domain conventions, accessibility, and user-affordances.

Intent

Present each ranked result as a card whose visual structure communicates relevance through query-aware snippets, highlighting, and prominent display of the user-relevant metadata, with proper keyboard and screen-reader accessibility.

Motivating Problem

Default result presentations — just titles and snippets stripped from document descriptions — underuse the available data and underserve the user. Production result lists need: query-aware snippets that show why each result matched; query-term highlighting that builds user trust; per-domain metadata appropriate to the document type; clear action affordances; visual hierarchy that respects the ranking; full accessibility support. The pattern documented here addresses these requirements.

How It Works

The eight-slot model. The card framework: thumbnail/hero image (first visual signal); title (primary identifier with highlighting); snippet (query-aware extract); primary metadata (price/date/author/etc.); social proof (ratings, reviews); availability (in stock, accessible); action affordances (cart/save/open); badges (best seller, new, on sale). Not every card needs every slot; the choice depends on document type. E-commerce typically uses 6–8 slots; content search 4–6; enterprise document search 5–7 with different emphasis.

Query-aware snippets. The snippet is the most important supporting context. Static snippets (extracted from a description field) are simple but don't adapt to the query. Query-aware snippets (extracting the most relevant portion of the document with query terms in context) are substantially better UX. Elasticsearch provides three highlighters: the plain highlighter (basic, fast); the unified highlighter (default, best balance); the fast vector highlighter (precise, requires term vector indexing). Choose based on quality requirements; the unified highlighter is the production default. The snippet length should match the card density: longer for content search where users read snippets, shorter for e-commerce where users scan.

Highlighting. Within titles and snippets, query terms get visually distinguished (typically bold or background-colored). The highlighter's job is identifying which terms to highlight: terms the user typed after analyzer processing (stemming, synonyms applied); terms from query expansion (synonyms, LLM-generated alternatives); terms from spell correction. Production patterns: highlight all matched terms across all fields; use distinct visual treatment for direct matches vs synonym/expansion matches if the team wants to communicate that distinction; avoid over-highlighting (highlighting most of the title produces visual noise).

Title rendering. The title is the primary identifier; it must be scannable. Patterns: truncate long titles consistently (typically 60–80 characters before ellipsis); preserve key terms even if truncating means cutting other parts; render with appropriate weight (bold) and size (larger than snippets); ensure sufficient contrast against background; make the entire title clickable as the canonical "go to this result" link.

Image / thumbnail. Visual content (product images, article hero images, document icons) substantially affects scanning behavior. Patterns: use consistent aspect ratios across cards in a list (1:1 square for products, 16:9 for video, 4:3 for articles); pre-size images at the server before serving to avoid layout shift; provide alt text for accessibility; lazy-load images below the fold to keep initial render fast; provide image-less fallback design for cases where no image exists.

Action affordances. What can the user do with this result? E-commerce cards typically need: add to cart (primary action), save/wishlist (secondary), compare (tertiary). Content cards: open/read (primary), save/bookmark (secondary), share (tertiary). Enterprise cards: open document (primary), share (secondary), pin/save (tertiary). The actions should be discoverable but not visually overwhelming; tertiary actions can be hidden until hover or behind a menu.

Card density and layout. Grid vs list layout. Grid (multi-column) emphasizes images and supports denser scanning; works for e-commerce, image-heavy content. List (single column) emphasizes text and metadata; works for content articles, enterprise documents. Production patterns: choose based on the workload; some systems offer user toggles between layouts. Density (results per page) trades quantity for quality of presentation; navigational searches benefit from denser layouts, exploratory searches benefit from richer cards.

Accessibility. Each card needs to be keyboard-navigable: tabbing through the result list should land on each card's primary link first, then secondary actions. Screen readers should read the card structure logically: title → key metadata → available actions. Icon-only buttons (save, share, compare) need aria-label attributes describing their action. Sufficient color contrast (4.5:1 minimum for body text per WCAG AA). Focus states should be visible (not just removed for visual aesthetics). The WAI-ARIA Authoring Practices document the patterns; production deployments should test with at least one screen reader.

When to Use It

Every search result presentation. The patterns scale from simple search interfaces to complex enterprise search with rich metadata.

Alternatives — plain link lists for very simple use cases (a few hundred items, no metadata). Card grids for image-heavy content. The pattern documented here applies broadly with per-domain customization.

Sources
  • Elasticsearch highlighter documentation (elastic.co)
  • OpenSearch highlighter documentation
  • WAI-ARIA Authoring Practices
  • WCAG 2.1 success criteria for accessible interactive content
Example artifacts

Schema / config

// Elasticsearch query with query-aware snippet highlighting
// Returns ranked results with highlighted snippets ready for display

GET /products/_search
{
"query": {
"multi_match": {
"query": "running shoes",
"fields": ["title^3", "description", "brand^2"],
"type": "best_fields",
"fuzziness": "AUTO"
}
},
"highlight": {
"type": "unified",
"pre_tags": ["<mark>"],
"post_tags": ["</mark>"],
"fields": {
"title": {
"number_of_fragments": 0, // highlight in full title
"no_match_size": 200 // fallback to first 200 chars
},
"description": {
"fragment_size": 150, // ~150-char snippets
"number_of_fragments": 1, // single snippet per result
"no_match_size": 150 // fallback if no terms match
}
},
"require_field_match": false // highlight even if matched elsewhere
},
"_source": ["title", "brand", "price", "image_url",
"rating", "in_stock"],
"size": 20
}

// Response structure (excerpt):
// {
// "hits": {
// "hits": [
// {
// "_id": "sku-12345",
// "_score": 8.42,
// "_source": {
// "title": "Nike Air Max 270 Running Shoes",
// "brand": "Nike",
// "price": 129.99,
// "image_url": "https://...",
// "rating": 4.6,
// "in_stock": true
// },
// "highlight": {
// "title": ["Nike Air Max 270 <mark>Running</mark>
<mark>Shoes</mark>"],
// "description": ["The Nike Air Max 270 features a lightweight
mesh upper for <mark>running</mark>..."]
// }
// }
// ]
// }
// }

Read in context within Volume 07 →