The Search UX Patterns Catalog

Hybrid autocomplete with query suggestions, instant results, and personalization #

Source: Production methodology at major e-commerce and content search teams; WAI-ARIA combobox pattern; modern autocomplete libraries (Algolia Autocomplete, Downshift, Headless UI)

Classification — The pattern for production autocomplete combining multiple source types with proper accessibility, low-latency interaction, and personalization.

Build an autocomplete component that meets sub-100ms latency requirements, blends multiple suggestion sources appropriately for the workload, handles keyboard and screen reader interactions correctly, and shapes user queries toward those the backend can satisfy well.

Default autocomplete implementations are either too simple (just prefix-matching against a static list) or too complex (every keystroke hits the backend, producing laggy interactions and high backend load). Production autocomplete needs: multiple source types to address different user needs (completions for incremental discovery, instant results for navigational queries, categories for structured navigation, recent searches for return users); fast response (sub-100ms typical, sub-50ms ideal); proper accessibility for keyboard and screen reader users; failure handling when backend is slow or unavailable. The pattern documented here addresses these requirements.

Source blending. The autocomplete dropdown shows results from multiple sources, each in its own section. Query completions appear first — prefix matches against the historical query corpus. Instant results appear next (or interleaved) — actual matching documents, retrieved live. Categories appear when the prefix matches a category name or when intent classification suggests categorical browsing. Recent searches appear for logged-in users or browser-cookie-identified sessions. The blending logic is workload-specific; e-commerce typically emphasizes instant results (users want to see products) while content search emphasizes query completions (users are still formulating their question).

Debouncing and throttling. Sending a request on every keystroke is wasteful and produces choppy results. Debouncing waits a short period (typically 50–150ms) after the last keystroke before sending the request — a user typing quickly produces only one request when they pause. Throttling limits the rate of requests regardless of typing (e.g., at most one request every 100ms) — prevents overload during sustained typing. Production patterns combine both; the specifics depend on the typical user behavior and the backend capacity.

Caching. Common prefixes ("run", "ni", "kid") are queried thousands of times per day. The autocomplete should cache results aggressively: in-memory cache in the browser for recently-typed prefixes; CDN-level cache for popular prefixes globally; backend cache for the prefix lookup. Each cache layer cuts latency for cache hits. The cache invalidation discipline is light — autocomplete results don't need to be perfectly fresh; minutes-old data is fine for query completions and categories.

Async loading and skeletons. Even with caching, some keystrokes will produce cache misses that need backend round-trips. The UI should show a loading state during these gaps — skeleton placeholders for instant results, an indicator that more is coming. The skeleton pattern feels faster than spinners; users perceive progress rather than just waiting.

Keyboard navigation. Up/Down arrows navigate suggestions; Enter selects the focused suggestion; Escape dismisses the dropdown; Tab inserts the focused suggestion into the input without submitting (allows further refinement). Production implementations need to handle these consistently; the WAI-ARIA combobox pattern specifies the expected behaviors. The detail matters: small inconsistencies (e.g., Enter sometimes selects, sometimes submits) frustrate power users.

Screen reader support. The dropdown needs proper ARIA roles: role=\"combobox\" on the input; role=\"listbox\" on the dropdown; role=\"option\" on each suggestion; aria-activedescendant on the input pointing to the currently-focused option; aria-expanded indicating whether the dropdown is open. Screen readers announce the focused option as the user navigates. Production deployments test with NVDA, JAWS, and VoiceOver to verify the patterns work across screen readers.

Touch and mobile. On touch devices, autocomplete behavior differs. Suggestions must be large enough to tap reliably (44px minimum, per WCAG); selection should be on tap, not hover (hover is unreliable on touch); the keyboard should support search-as-you-type without aggressive autocorrect (which can interfere with longer or unusual queries). iOS and Android have different input behaviors that the implementation needs to accommodate.

Backend integration. The autocomplete backend typically has a dedicated endpoint optimized for low-latency prefix queries: an in-memory trie or sorted-suffix structure rather than the full search index; pre-computed popularity scores; limited result sizes (typically 5–10 completions per source); deduplication and filtering. The backend may be a separate service or a dedicated mode of the main search service; the operational characteristics (sub-50ms p99 latency, very high request rate) are different from the main search backend.

Every consumer-facing search system benefits from autocomplete. Enterprise search systems benefit when the workload includes substantial repeat or pattern-based querying. The investment is moderate (the patterns are well-established) and the returns are substantial (autocomplete shapes the queries the backend ever sees).

Alternatives — no autocomplete is appropriate for very limited workloads (a few hundred items where browse is sufficient) or for specialized interfaces (command-line search tools). Search-as-you-type without autocomplete (showing instant results without query suggestions) is a simpler variant for some use cases.

• WAI-ARIA Authoring Practices: Combobox pattern (w3.org/WAI/ARIA/apg/patterns/combobox)
• Algolia Autocomplete documentation (algolia.com/doc/ui-libraries/autocomplete/)
• Production case studies from major e-commerce and content search teams
• Downshift / Headless UI / Radix UI documentation for the underlying interaction patterns

Code

// Accessible autocomplete component (React + TypeScript)
// Implements WAI-ARIA combobox pattern with multi-source blending

import { useState, useEffect, useRef, useId } from \'react\';
import { useDebounce } from \'./hooks\';

type Suggestion =
| { kind: \'completion\'; text: string }
| { kind: \'document\'; id: string; title: string; image?: string }
| { kind: \'category\'; text: string; count: number }
| { kind: \'recent\'; text: string };

interface AutocompleteProps {
fetchSuggestions: (prefix: string) => Promise<{
completions: { text: string }[];
documents: { id: string; title: string; image?: string }[];
categories: { text: string; count: number }[];
}>;
getRecentSearches: () => string[];
onSubmit: (query: string) => void;
onDocumentSelect?: (id: string) => void;
}

export function SearchAutocomplete({
fetchSuggestions, getRecentSearches, onSubmit, onDocumentSelect,
}: AutocompleteProps) {
const [query, setQuery] = useState(\'\');
const [suggestions, setSuggestions] =
useState<Suggestion[]>([]);
const [isOpen, setIsOpen] = useState(false);
const [activeIndex, setActiveIndex] = useState(-1);
const [isLoading, setIsLoading] = useState(false);
const listboxId = useId();
const inputRef = useRef<HTMLInputElement>(null);
const debouncedQuery = useDebounce(query, 100);
// Fetch and blend suggestions when query changes
useEffect(() => {
if (!debouncedQuery) {
// Empty input: show only recent searches
const recent = getRecentSearches().slice(0, 5);
setSuggestions(recent.map(text => ({ kind: \'recent\', text })));
return;
}
setIsLoading(true);
fetchSuggestions(debouncedQuery).then(({ completions, documents,
categories }) => {
const blended: Suggestion[] = [
...completions.slice(0, 4).map(c => ({ kind: \'completion\' as
const, ...c })),
...documents.slice(0, 3) .map(d => ({ kind: \'document\' as const,
...d })),
...categories.slice(0, 2) .map(c => ({ kind: \'category\' as const,
...c })),
];
setSuggestions(blended);
setIsLoading(false);
}).catch(() => setIsLoading(false));
}, [debouncedQuery]);
function handleKeyDown(e: React.KeyboardEvent<HTMLInputElement>) {
switch (e.key) {
case \'ArrowDown\':
e.preventDefault();
setActiveIndex(i => Math.min(i + 1, suggestions.length - 1));
break;
case \'ArrowUp\':
e.preventDefault();
setActiveIndex(i => Math.max(i - 1, -1));
break;
case \'Enter\':
e.preventDefault();
if (activeIndex >= 0 && suggestions[activeIndex]) {
selectSuggestion(suggestions[activeIndex]);
} else {
onSubmit(query);
}
break;
case \'Escape\':
setIsOpen(false);
setActiveIndex(-1);
break;
}
}
function selectSuggestion(s: Suggestion) {
setIsOpen(false);
if (s.kind === \'document\' && onDocumentSelect) {
onDocumentSelect(s.id);
} else if (\'text\' in s) {
setQuery(s.text);
onSubmit(s.text);
}
}
return (
<div className="search-autocomplete">
<input
ref={inputRef}
type="search"
role="combobox"
aria-autocomplete="list"
aria-expanded={isOpen}
aria-controls={listboxId}
aria-activedescendant={activeIndex >= 0 ?
`${listboxId}-${activeIndex}` : undefined}
value={query}
onChange={e => { setQuery(e.target.value); setIsOpen(true);
setActiveIndex(-1); }}
onFocus={() => setIsOpen(true)}
onBlur={() => setTimeout(() => setIsOpen(false), 200)} // delay for
click
onKeyDown={handleKeyDown}
placeholder="Search..."
/>
{isOpen && suggestions.length > 0 && (
<ul id={listboxId} role="listbox" className="suggestions">
{suggestions.map((s, i) => (
<li
key={i}
id={`${listboxId}-${i}`}
role="option"
aria-selected={activeIndex === i}
className={`suggestion suggestion\--${s.kind} ${activeIndex === i
? \'active\' : \'\'}`}
onMouseDown={e => { e.preventDefault(); selectSuggestion(s); }}
>
{renderSuggestion(s)}
</li>
))}
</ul>
)}
</div>
);
}

function renderSuggestion(s: Suggestion) {
switch (s.kind) {
case \'completion\': return <span>{s.text}</span>;
case \'document\': return (
<div className="suggestion-doc">
{s.image && <img src={s.image} alt="" aria-hidden="true" />}
<span>{s.title}</span>
</div>
);
case \'category\': return <span>{s.text} <em>({s.count}
items)</em></span>;
case \'recent\': return <span
className="recent">{s.text}</span>;
}
}

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.

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.

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.

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.

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.

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

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>..."]
// }
// }
// ]
// }
// }

Production faceted navigation with URL state, dynamic counts, and accessibility #

Source: Production e-commerce and search platform UX; React faceted search libraries (Algolia React InstantSearch, Mantine); WCAG accessibility patterns

Classification — Pattern for implementing faceted refinement that scales to complex schemas while remaining usable, accessible, and bookmarkable.

Provide users with refinement controls that narrow large result sets through structured attributes, with URL state for bookmarkability, dynamic counts for guidance, and accessibility for all input modes.

Default facet implementations often have subtle but consequential gaps: state lives only in JavaScript memory (back-button breaks search context); counts are static (don't update as filters interact); options that lead to zero results aren't handled (users hit dead ends); facet groups are equally weighted (the most useful facets aren't prioritized); keyboard and screen-reader users struggle (facet checkboxes don't have proper grouping). The patterns documented here address each gap.

Facet types. Multi-select (checkbox list): OR within facet, AND across facets; appropriate for orthogonal attributes (brand, category, color). Single-select (radio buttons or exclusive buttons): one value at a time; appropriate for sort orders, exclusive ranges. Range (sliders or input fields): continuous values; appropriate for price, dates, ratings. Hierarchical (tree of nested categories): drill-down; appropriate for category taxonomies, organizational structures. Each schema field maps to one facet type based on its data shape and how users want to filter.

Dynamic counts. Each facet option shows a count of matching results given the current filter state. The counts are essential user information — they signal which selections are productive. Implementation: the search backend returns facet counts alongside results, computed against the post-filter result set. Production patterns: use the search engine's aggregation API (Elasticsearch terms aggregation, Solr facet.field); recompute counts on each filter change; hide or grey out options with zero counts to avoid dead-ends. The count refresh on each interaction makes the UI feel responsive and informed.

URL state. The active filter state should encode in the URL. Pattern: serialize filters as URL query parameters (?brand=nike,adidas&price_min=50&price_max=200); restore filters on page load by parsing the URL; update the URL (via history.pushState or framework router) on each filter change. The benefits: back/forward navigation works correctly; URLs are shareable and bookmarkable; refreshing the page preserves the filter state; analytics can attribute traffic to filtered URLs.

Active filters as chips. Show the current filters prominently at the top of the result area, typically as removable chips. Each chip shows "Facet: Value" with an X button to remove just that filter. Patterns: chips for each active filter; a "Clear all" affordance when multiple filters are active; visual distinction between filter chips and search query chips. The chips let users see and modify their filter state without scrolling back to the sidebar.

Facet ordering and grouping. Not every facet is equally useful for every query. Static ordering (alphabetical or per-category configuration) is simple but suboptimal. Dynamic ordering (per-query, based on which facets would most narrow the result set) is better UX but more complex. Production patterns: order facets by their refinement utility — facets whose top option would reduce the result set substantially appear at top; less-discriminating facets appear lower or are collapsed. The discipline is making this measurable and tuneable, not just guessing.

Collapsible groups. Long facet lists need to be collapsible. Defaults: expand the most-used facets, collapse others; remember the user's expansion state in URL or local storage. Within each facet, show the top 5–10 options expanded with a "show more" affordance for the rest. The patterns trade discoverability for scanability; production systems should test both extremes (everything expanded vs everything collapsed by default) to find the right balance for the workload.

Mobile facets. On smaller screens, facet sidebars don't fit alongside results. Patterns: "Filter" button that opens a modal or drawer containing the facets; apply-button at the bottom of the drawer to commit changes; preserve any in-progress changes if the user dismisses the drawer (so they don't have to redo their selections); count of pending changes visible on the apply button. The mobile pattern is different enough from desktop that production systems often have separate components for the two.

Accessibility. Each facet group needs proper grouping semantics: a fieldset with a legend for the group name, or role=\"group\" with aria-labelledby pointing to the heading. Each checkbox needs a clear label. Range sliders need keyboard support (arrow keys, page up/down for larger steps). Active filter chips need to be focusable and removable via keyboard. Production deployments test with screen readers to verify the patterns work correctly.

Search systems where results have structured attributes that users want to filter on. E-commerce (brand, category, price, attributes), content (date, source, topic), enterprise document search (department, jurisdiction, document type). Most production search benefits from facets; the question is how rich the facet implementation needs to be.

Alternatives — no facets for very simple workloads or where ranking is sufficient. Search-only refinement ("search within these results") as alternative to facet selection. The faceted pattern is the default for non-trivial workloads.

• Algolia React InstantSearch documentation (algolia.com/doc/api-reference/widgets/)
• Elasticsearch terms aggregation documentation
• WAI-ARIA Authoring Practices: group, listbox, slider patterns
• Production faceted search case studies (Wayfair, Etsy, Amazon writings)

Spell correction and query suggestion UX patterns #

Source: Production search UX methodology; Volume 2 query understanding outputs; major web search UX (Google, Bing, DuckDuckGo)

Classification — Patterns for presenting spell correction, query expansion, and reformulation suggestions to users with appropriate confidence-based behavior.

Surface query understanding outputs as user-facing affordances that improve search outcomes without removing user agency over their query intent.

Volume 2's spell correction can produce wrong corrections (the user actually meant the unusual spelling); auto-correcting confidently incorrect spellings produces frustrating failures. Showing too many alternatives clutters the UX; showing too few misses opportunities to recover from common errors. The patterns documented here address the confidence-based handling that production systems converge on.

Confidence-based behavior. The spell correction backend produces a corrected query plus a confidence score. The UX response depends on the confidence: very high confidence (the user almost certainly meant the corrected spelling): auto-apply the correction, show "Showing results for X. Search instead for Y" — the user sees the correction was applied with a one-click escape. Medium-high confidence: show original-query results but with prominent "Did you mean X?" link — the user can keep current results or switch. Lower confidence: show suggestions in less prominent places (related searches, sidebar) without claiming they're corrections.

Preserving user intent. Even when auto-applying corrections, the user's original query should be preserved as an affordance. Pattern: "Showing results for 'running shoes'. Search instead for 'running shoses'." The 'search instead for' link is essential — if the user really did mean the original (an unusual product name, a person's name, a technical term), they need a one-click path to get those results. Without the escape hatch, the team is paternalistically overriding user intent.

Confidence thresholds. The thresholds are workload-specific. Production patterns: auto-apply at very high confidence (typically 0.9+ in calibrated terms, when zero-result avoidance is the primary concern); show "did you mean" at medium-high confidence (0.7–0.9); show in less prominent places at lower confidence (0.5–0.7); don't suggest below 0.5. The thresholds should be tuned based on observed outcomes — a high auto-apply rate that produces user complaints about "it changed my query" suggests the threshold is too low.

Suggestion presentation. The "Did you mean" affordance is typically placed prominently at the top of results: a single line with the suggested correction as a link, plus the original query rendered with the suspect terms underlined or italicized. Visual distinction: italic for the original ("you typed"), regular weight for the suggestion ("we think you meant"). The link's click target should be the suggestion text plus enough padding to be tap-friendly on mobile.

Multiple suggestions. Sometimes multiple corrections are plausible. The UX choice: show one (the most confident) and risk being wrong, vs show multiple ("Did you mean X, Y, or Z?") and risk overwhelming. Production patterns favor showing one in most cases — reduces cognitive load and works for the vast majority of corrections. If the team chooses multiple, present them as a small ordered list rather than a long string.

Related searches. Beyond spell correction, query expansion produces related queries (synonyms, broader/narrower terms, popular reformulations). These should be surfaced as "Related searches" or "You might also try" — typically in a sidebar or at the bottom of results, not at the top (where they'd compete with did-you-mean). The presentation is browseable rather than prescriptive: "here are some other paths you might try."

Inline reformulation in empty states. When results are zero, the suggestion becomes the primary affordance. Empty-state pattern: "No results for X. Did you mean Y?" with the suggestion as a prominent link. The empty state is the place where reformulation suggestions can be most assertive because there's nothing competing for attention. Even low-confidence suggestions can appear in empty states as exploratory options.

Logging and learning. Did-you-mean clicks are valuable signals. Tracking which suggestions users accept vs reject improves the underlying correction model and informs the confidence thresholds. Production patterns: log every suggestion shown and whether it was clicked; aggregate to compute acceptance rates per correction pair; feed back into the spell correction model's training or tuning; revisit confidence thresholds periodically based on the data.

Any search system where users sometimes misspell or use vocabulary mismatched with the index. The patterns are foundational; the implementation can be simple (a few rules) or sophisticated (calibrated probabilities, contextual thresholds), but some form of did-you-mean handling is appropriate for almost all search.

Alternatives — silent auto-correction for very controlled workloads where the corrections are known reliable. Strict no-correction for specialized workloads (legal search, scientific search) where the user's exact terms matter. The middle ground (confidence-based suggestions) is the production default.

• Volume 2 of this series for the spell correction backend
• Production methodology writings on search UX
• Major search engine UX as observed (Google, Bing, DuckDuckGo)

The empty state hierarchy and graceful failure patterns #

Source: Production search UX methodology; UX writing literature; Volume 6 zero-result investigation patterns

Classification — Patterns for handling the various forms of search failure — partial matches, zero results with suggestions, zero results without suggestions — in user-facing ways.

Convert search failure modes into useful user interactions by acknowledging the failure clearly, offering alternative paths forward, and preserving user agency.

The worst UX failure in production search is the bare "No results" page with no alternatives, no suggestions, no path forward — the user is stuck. This pattern still appears commonly in production search. Even minimal alternatives substantially improve the empty-state experience; substantial alternatives transform it from a dead-end into a redirection opportunity.

State 1: partial match. The system found some results but they're weak (low scores, spell correction inferred but uncertain). UX response: show the partial results with a banner explaining the situation ("Showing partial matches for X"); offer the inferred query as a one-click switch; preserve the original query as a fallback ("search instead for..."). The pattern communicates uncertainty honestly while preserving user control.

State 2: zero results, suggestions possible. The system has nothing for the query but has a confident alternative (typically from spell correction or query expansion). UX response: an empty-results page with the failed query prominently displayed; a clear suggestion as the primary affordance ("Did you mean X?" as a large clickable element); the original query preserved (the user might want to try a different reformulation or contact support). Production patterns avoid auto-applying corrections in zero-result cases because the auto-apply would hide the failure from the user.

State 3: zero results, no clear suggestion. The system has nothing and no good alternative — a genuine content gap or vocabulary gap. UX response: clear acknowledgment of the gap; suggested alternative paths (browse categories, popular content); contact or request affordances where relevant; a description of what kinds of things the search does cover, so the user understands the scope. The state should feel like helpful redirection, not failure.

Content for empty states. The text matters substantially. Bad patterns: "No results found." (cold, blocking, no path forward). Good patterns: "We couldn't find products matching 'X'. Try browsing our running shoe categories below, or check your spelling." (warm, redirecting, offers paths forward). UX writing guidance: acknowledge the failure clearly without blaming the user; describe what was tried; offer alternatives; maintain brand voice. Production teams often have UX writers contribute to empty-state copy because the content has substantial impact on perceived quality.

Filter dead-ends. A specific failure case: the user applied filters that collectively eliminate all results. UX response: explicitly call out the filter combination as the cause; suggest removing specific filters ("Remove 'size 14' to see 47 more results"); offer a "clear all filters" affordance. The pattern educates the user about which filter is most restrictive; without it, the user has to manually try removing each filter to find the path forward.

Suggestions in empty states. Empty states are the right place for assertive suggestions. Patterns: top related searches (queries similar to the failed one that did produce results); popular searches in this section/category; recently viewed items (for logged-in users — something the user has shown interest in); featured or curated content (when the team wants to direct attention). The suggestions should be tailored to context: a zero-result query in the shoe department should suggest shoe alternatives, not generic store-wide popular items.

Logging and operational integration. Empty states are operationally important — Volume 6 Section B documented the investigation cycle. The UX should support the operational discipline by capturing what the user does next: did they click a suggestion? Did they reformulate? Did they leave? Did they contact support? Each behavior is a signal about whether the empty-state UX worked. Production patterns: log empty-state events with the failed query; track subsequent user actions; correlate with whether the user eventually found what they wanted (or didn't).

Mobile considerations. On mobile, empty states need to be especially well-designed because the user has fewer fallback paths (no easy sidebar for filters, fewer affordances visible at once). The empty state should fit on one screen without scrolling; the primary suggestion should be obvious and large; the path back should be one tap. The discipline is harder on mobile but more important — users abandon mobile search more readily than desktop, and good empty-state UX retains them.

Every search system. The patterns are foundational; even simple search benefits from non-trivial empty-state handling. The investment is modest (mostly content design plus modest implementation work); the returns are substantial because the failure cases compound badly without it.

Alternatives — none for serious search UX. Some systems show "contact support" as the only path in empty states; this works for very limited contexts but underuses the available alternatives. Some show generic browse links; this is better than nothing but suboptimal. The contextual, redirective pattern documented here is the production default.

• Production search UX methodology writings
• Volume 6 of this series for the operational investigation patterns
• UX writing literature (Microsoft Style Guide, Mailchimp Voice and Tone, etc.)

Mobile-specific search UX patterns and responsive design #

Source: Production mobile UX methodology; iOS and Android design guidelines; touch interaction research

Classification — Patterns for designing search UX that works well on mobile devices alongside (or instead of) desktop.

Adapt search UX patterns to mobile constraints — small screens, touch input, slower networks, different user contexts — while maintaining the affordances that make search useful.

Search UX designed primarily for desktop often translates badly to mobile. Facet sidebars don't fit alongside results; autocomplete keyboard navigation is irrelevant when there's no keyboard; result cards that work at desktop density become unscannable at mobile sizes; touch targets that work fine with a mouse become frustratingly small on a finger. Production mobile search needs design patterns that respect mobile constraints rather than just shrinking desktop UX.

Search input. Mobile search input typically takes the full screen width and is visually prominent at the top of the page. Patterns: large enough touch target (44+ pixels tall per WCAG); appropriate keyboard type (search on iOS, with the search-action key on the return button); voice input affordance (microphone icon launching speech-to-text); clear-input affordance (X button to clear the current query); no zoom-on-focus (set font-size 16+ to prevent iOS auto-zoom). The input should feel substantial and discoverable, not hidden in a corner.

Autocomplete on mobile. The autocomplete dropdown behaves differently. Patterns: the dropdown takes substantial vertical space (often half the visible screen); suggestions are individually larger (44+ pixels per touch target); fewer sources are shown (typically 2–3 sources blended, not 4–5); selecting a suggestion submits immediately rather than just filling the input (mobile users want results, not edit operations); recent searches are emphasized because they're easier than typing on mobile.

Result cards. Mobile cards typically stack in a single column at full width. Patterns: image and key information visible without scrolling per card; price/primary metadata immediately below title (don't bury); action affordances (cart, save) as taps rather than hover; cards should be tappable as a whole, not require precise targeting of the title link; sufficient vertical spacing between cards to avoid mis-taps. Card density on mobile is typically lower than desktop (4–6 results visible at a time vs 8–12 on desktop) because each card needs more vertical space.

Filters on mobile. The desktop sidebar pattern doesn't fit on mobile screens. Production patterns: "Filter" button that opens a modal or full-screen drawer; the drawer shows all facet groups with the same structures as desktop; an "Apply" button at the bottom of the drawer commits changes (don't apply on every interaction — too disruptive on mobile); a count of pending changes shown on the apply button ("Apply (3 filters)"); the drawer dismissible without applying (Cancel button); badges on the filter button showing how many filters are currently active. The pattern is universal enough that users learn it once and apply it across mobile apps.

Sorting on mobile. Sort controls follow a similar drawer pattern: a "Sort" button that opens a bottom sheet or modal with sort options. Single-select radio buttons for the available sort orders. Apply on selection (sort is simpler than multi-filter so immediate application works). Production patterns: combine sort and filter into a single bottom toolbar; show the current sort option on the toolbar ("Sorted by: Price low to high") so users see the state.

Search-as-you-type vs submit. On desktop, results often update as the user types (incremental search). On mobile, this pattern can be disruptive — the network request for every keystroke is expensive on cellular; the result updates create motion that's distracting on small screens. Production patterns: prefer submit-driven search on mobile (user taps the search button or selects an autocomplete suggestion); use autocomplete to handle the incremental discovery; reserve search-as-you-type for very fast backends and contexts where the user expects it.

Touch ergonomics. The thumb-zone matters on mobile: users hold phones in ways that make some areas easier to reach than others. The most common one-handed grip puts the thumb closest to the bottom-right (right-handed) of the screen. Important affordances should be in reachable zones: primary search input at the top is OK (users use both hands when actively searching); apply/submit buttons should be in the bottom-right or bottom-center; back/cancel in the top-left. The patterns aren't absolute but they're informed by how users actually hold phones.

Network resilience. Mobile networks are slower and less reliable than desktop. Patterns: aggressive caching of repeated searches; skeleton screens during loading (Section B); optimistic updates where appropriate; offline messaging when the network fails ("You're offline. Showing recently viewed."); retry affordances. The discipline is treating network failure as a normal case rather than an exception.

Responsive design. The same codebase often needs to serve both mobile and desktop. Patterns: design mobile-first (start with the constrained mobile design, scale up to desktop); use CSS media queries to switch layouts at breakpoints; test on actual devices (emulators miss many issues); consider conditional component rendering (the mobile filter drawer vs desktop sidebar may be different components rather than the same component restyled). The technical patterns are standard responsive web design; the design discipline is making sure the mobile experience is genuinely good rather than just usable.

Any search system that serves mobile traffic. For consumer search, mobile is typically the majority of traffic and may be over 80% in some categories. Even for enterprise search, mobile usage has grown substantially through 2024–2026. Mobile-first design is the default in modern web work.

Alternatives — desktop-only search for tightly scoped use cases (internal admin tools, specialized B2B). Native mobile apps as alternative to mobile web (the patterns documented here apply with platform-specific adaptations for iOS and Android).

• Apple Human Interface Guidelines (developer.apple.com/design/human-interface-guidelines)
• Google Material Design guidelines (m3.material.io)
• Production mobile search UX writings
• Touch interaction research (Hoober, 2013 on thumb zones; Fitts's law applications)

Conversational search UX patterns with answer synthesis and citation #

Source: Production methodology at AI-first search products (Perplexity, You.com, Google AI Overviews, Bing Chat); RAG application UX patterns through 2024–2026; Anthropic and OpenAI conversational AI guidance

Classification — Patterns for surfacing LLM-synthesized answers alongside or instead of traditional result lists.

Provide conversational answer experiences that satisfy informational and analytical queries directly while preserving the user's ability to verify sources and explore further.

Traditional search returns documents; users still have to read them and synthesize the answer themselves. For informational queries ("what are the common signs of vitamin D deficiency", "how do I file a tax extension"), the user wants the answer, not a list of articles. Conversational search synthesizes the answer from retrieved documents and presents it directly. The UX patterns for this are still emerging but consolidating around several conventions documented here.

The synthesis surface. Above or instead of the result list, the system presents a synthesized answer to the query. The answer is typically: a few sentences to a paragraph of natural-language text; with inline citations to the documents that informed the answer (footnote-style numbers, hyperlinks, or pill-shaped chips); with the source documents shown below for verification. The pattern is the RAG (retrieval-augmented generation) interface that emerged through 2023–2024 and consolidated through 2025–2026.

Citations. Citations are essential for trust. Each statement in the synthesized answer should be traceable to source documents. Patterns: inline numbered citations linked to the source list ([1] [2] [3]); hover or click reveals the cited source snippet; the source document is one click away for full reading. Without citations, users can't verify the synthesis, and the answer feels less trustworthy regardless of accuracy. Production systems emphasize citation visibility; the absence of citations is a quality signal users have learned to be wary of.

Hallucination handling. LLMs sometimes synthesize answers that aren't supported by the retrieved documents — hallucinations. UX patterns to mitigate: cite specific spans of source documents rather than just listing sources at the end; show the source snippets prominently; allow the user to dispute or report incorrect answers; never auto-present synthesized answers for high-stakes domains (medical, legal, financial) without explicit caveats. The discipline is treating the synthesis as a draft for the user's consideration rather than as authoritative output.

Follow-up and conversation. Conversational search lets users ask follow-up questions in context. "What are the common signs of vitamin D deficiency" → "How do you test for it?" → "What dosage is recommended?" Each question builds on the prior context. UX patterns: conversation thread display (each Q&A as a turn); context preservation (the next question understands the prior context implicitly); explicit context controls (clear conversation, start over). The conversational pattern is fundamentally different from the stateless query/results pattern; it requires different state management and different UI.

Mixed presentation. Many systems combine synthesis with traditional results: the synthesis appears at the top of the page; the traditional result list below offers more depth. The user can choose: read the answer and move on, or scan the results for more comprehensive coverage. The pattern works well for queries that have both a direct answer and broader exploration value.

When to synthesize vs return results. Not every query benefits from synthesis. Navigational queries ("Nike homepage") want the link, not an essay. Transactional queries ("buy running shoes") want product listings, not a summary of what running shoes are. Informational queries ("what is BM25") benefit from synthesis. The Volume 2 intent classification can route queries to synthesis-vs-list pathways. Production patterns: synthesize selectively based on query type; default to traditional results for ambiguous cases.

Voice search. Voice input adds another dimension. Users speak their query; the system transcribes via speech-to-text; the synthesis is read back via text-to-speech (or both displayed and spoken in a multimodal interface). UX patterns: clear feedback during recording (waveform, listening indicator); transcription confirmation (the user can see what was transcribed before submitting); fallback to text if transcription fails or feels uncertain. Voice search works well for some contexts (hands-free, accessibility, mobile while walking) and poorly for others (lengthy queries, contexts requiring privacy); production deployments offer voice as an option, not exclusive mode.

Cost and latency. Conversational search has different operational characteristics than traditional search. LLM inference is more expensive than retrieval (often 10–100x per query); latency is higher (1–5 seconds typical vs 100ms for traditional results); failure modes are different (the LLM may produce wrong or biased synthesis even when retrieval works). Production patterns: caching for common queries (reduces both cost and latency); streaming the synthesis as it generates (perceived latency improves substantially with streaming); fallback to traditional results if the LLM fails or times out; cost budgets enforced at the system level. The patterns are still maturing; teams deploying conversational search should expect to invest in operational sophistication.

Search workloads with substantial informational queries that benefit from synthesis. Knowledge bases. Documentation search. Research-style search. Some categories of e-commerce (comparison shopping where synthesis helps). Workloads where the cost and latency are justified by the quality improvement.

Alternatives — traditional results-only search where the workload is mostly navigational or transactional. Hybrid systems (synthesis for some query types, traditional for others) are common and often the right choice. The pure-conversational interface is most appropriate for explicitly conversational products (Claude, ChatGPT, Perplexity), not for traditional search systems where users expect results lists.

• Production methodology writings from Perplexity, You.com, Google, Bing on AI-search UX
• Anthropic Claude documentation on conversational interfaces
• RAG application UX literature (LangChain, LlamaIndex documentation)
• Volume 10 of the agentic AI series (RAG patterns)

Resources for tracking search UX discipline #

Source: Multiple practitioner, academic, and design-resource sources

Classification — Sources for staying current on search UX practice.

Provide pointers to the active sources of search UX knowledge across design, accessibility, and emerging conversational interfaces.

Search UX sits at the intersection of multiple disciplines: search engineering, UX design, accessibility, content design, information architecture. The discipline doesn't have a unified literature; practitioners assemble understanding from multiple sources.

Foundational texts. Hearst, Search User Interfaces (Cambridge, 2009; free online at searchuserinterfaces.com) — the canonical reference for search UX even though dated; many patterns remain current. Russell, Mindshare: A Field Guide to Search Behavior (2024) — contemporary observations on how users actually search. Morville and Callender, Search Patterns (O'Reilly, 2010) — the IA-side perspective on search interface design; many examples are dated but the framing remains useful.

Accessibility resources. WAI-ARIA Authoring Practices (w3.org/WAI/ARIA/apg/) — the canonical reference for accessible component patterns; the combobox, listbox, group, slider patterns directly apply to search UX. WCAG 2.1 / 2.2 success criteria (w3.org/WAI/WCAG21/) — the accessibility requirements that apply to search UX. WebAIM articles on form and search accessibility (webaim.org/articles/). Inclusive Components by Heydon Pickering (inclusive-components.design) — production patterns for accessible web components including comboboxes.

Design system documentation. Major design systems include substantial search UX patterns: Material Design (m3.material.io), Apple Human Interface Guidelines (developer.apple.com/design/human-interface-guidelines), Microsoft Fluent (fluent2.microsoft.design), GOV.UK Design System (design-system.service.gov.uk). The patterns are battle-tested in production at scale; even teams not using these design systems benefit from studying the search-relevant components.

Practitioner writing. UX research firms (Nielsen Norman Group, Baymard Institute) publish substantial search UX research; the Baymard E-commerce Search UX research is particularly thorough for retail. Algolia's UX team publishes case studies and pattern documentation. Major search teams (Etsy, Wayfair, Spotify) periodically publish UX case studies.

Tools and libraries. Component libraries with strong search UX implementations: Algolia Autocomplete and React InstantSearch; Headless UI (headlessui.com); Radix UI (radix-ui.com); React Aria from Adobe (react-spectrum.adobe.com/react-aria); Mantine search components. The libraries handle the accessibility and interaction patterns correctly so teams don't reinvent them.

Conversational AI UX. AI-first product design literature is emerging: Anthropic's product documentation on conversational interfaces; OpenAI's ChatGPT design discussions; Perplexity's public design choices documented in their blog. The conventions are consolidating through 2025–2026.

Communities. UX design communities (Designer Hangout, ADP List, IxDA local chapters). Search-specific UX rare but emerging; Relevancy Engineering Slack has a #ux channel.

Emerging areas. Conversational and generative search UX is the most active emerging area through 2024–2026. AI-augmented faceted search (LLM-generated facet suggestions, semantic clustering of results) is appearing in production. Multimodal search UX (image-based, voice-based, gesture-based) is appearing in specialized products. Privacy-respecting search UX (under tightening regulations) is becoming distinct from analytics-rich UX.

UX designers working on search products. Search engineers designing UX components. Product managers prioritizing UX investments. Continuous education as patterns evolve.

Alternatives — specialized UX consulting for high-stakes engagements. Internal design systems for teams with mature practice. The combination of external tracking and applied judgment is the working pattern.

• Hearst, Search User Interfaces (Cambridge, 2009; free online)
• Morville and Callender, Search Patterns (O'Reilly, 2010)
• WAI-ARIA Authoring Practices (w3.org/WAI/ARIA/apg/)
• Baymard Institute E-commerce Search UX research
• Nielsen Norman Group search research articles
• Major design system documentation (Material, HIG, Fluent, GOV.UK)