UX Patterns Guide
UI + UX Search, Browse, And Discovery standard

Query correction

Expose a reversible correction state that either applies a high-confidence corrected query with disclosure or offers did-you-mean candidates while preserving the original submitted query and exact-search path.

Open in lab Compare alternatives
Decision first

Choose this pattern when the problem matches

Use when

  • Users submit free-form searches where spelling and typing mistakes commonly block useful results.
  • The search system can produce correction candidates with confidence, changed-token metadata, and enough result quality to justify the suggestion.
  • The product can preserve the original query and provide a reversible correction path.
  • Search vocabulary is broad enough that exact failure would create unnecessary no-result states.

Avoid when

  • The input is a constrained value selector better served by autocomplete.
  • Queries are primarily exact identifiers, account numbers, legal citations, SKUs, usernames, or codes.
  • Correction quality is too weak to avoid frequent overcorrection and the interface cannot provide a safe original-query path.
  • The issue is filters, permissions, scope, or empty data rather than spelling or phrase mistakes.
  • The product only needs pre-submit query suggestions and does not run submitted free-form search.

Problem it prevents

Users often submit searches with misspellings, transposed letters, missing spaces, joined words, or uncertain terminology, and a strict result state can hide relevant content or silently rewrite intent.

Pattern anatomy

What a strong implementation has to make clear

User need

The product accepts free-form submitted queries over a large content set.

Pattern promise

Expose a reversible correction state that either applies a high-confidence corrected query with disclosure or offers did-you-mean candidates while preserving the original submitted query and exact-search path.

Required state

No correction state when the submitted query is exact or correction confidence is too weak.

Recovery path

Silent query rewriting breaks user trust and makes exact lookup impossible.

Access contract

Announce correction status and result counts through a polite status region after submission.

Quality bar

The difference between expert and weak execution

Strong implementation

Specific, visible, recoverable

  • A results page says Showing results for benefit appeal, marks benefit and appeal as corrected tokens, and offers Search instead for benifit appeel.
  • A did-you-mean banner offers two candidate corrections after a zero-result typo query without overwriting the typed query.
  • A user searches benifit appeel, sees corrected results for benefit appeal, checks the changed tokens, and can switch back to the original query.
  • A user edits the query after a correction and the correction banner clears instead of showing stale corrected results.
Weak implementation

Vague, hidden, hard to recover from

  • The search field silently changes benifit appeel to benefit appeal and the original query is gone.
  • A person's name, SKU, or legal reference is corrected into a common word with no confidence, source, or revert path.
  • The product overcorrects a claimant surname and users cannot get back to the exact original search.
  • The UI reports zero results for an obvious typo even though a high-confidence correction is available.
UI guidance
  • Show the original submitted query and the corrected query in the result state, for example Showing results for benefit appeal with a Search instead for benifit appeel control.
  • Visually identify changed tokens or phrases near the result count, and keep correction actions close to the search field and result summary rather than hiding them in result cards.
UX guidance
  • Use query correction to recover from likely spelling, spacing, transposition, or phrase mistakes after a user submits a free-form search.
  • Preserve user agency: auto-apply only high-confidence corrections, offer did-you-mean for weaker candidates, and always allow searching the original wording.
Implementation contract

What the implementation must handle

States

  • No correction state when the submitted query is exact or correction confidence is too weak.
  • Auto-applied correction state showing corrected results, original query, changed tokens, and search-original action.
  • Did-you-mean state showing one or more correction candidates that have not yet been applied.
  • Original-query state after the user chooses to search the submitted wording instead of the corrected wording.

Interaction

  • Submitting a query records the submitted text separately from any corrected query used for results.
  • If corrected results are shown, the result summary states which corrected query is active and offers a reversible action to search the original.
  • Choosing Search instead for original reruns or reveals results for the original submitted text without changing the user's typed history into the correction.
  • Accepting a did-you-mean candidate applies that candidate as the active corrected query and updates the result count.

Accessibility

  • Announce correction status and result counts through a polite status region after submission.
  • Expose original and corrected query text as real text, not only color or strikethrough.
  • Use accessible names for actions such as Search original query benifit appeel and Apply corrected query benefit appeal.
  • Do not rely on color alone to identify changed tokens; pair markings with text labels or inline structure.

Review

  • Can users see both the original submitted query and the corrected query?
  • Is the correction auto-applied only when confidence and result quality justify it?
  • Can users search the original wording, accept a candidate, edit the query, and clear stale correction state?
  • Which tokens, fields, languages, codes, acronyms, names, numbers, or quoted phrases bypass correction?
Interactive lab

Inspect the states before you copy the pattern

Correct a submitted query

Submit a misspelled query, compare corrected results with the original query, and check whether the correction can be accepted, edited, or reversed.

Query correction
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 correction state when the submitted query is exact or correction confidence is too weak.

Keyboard / Access

Enter in the search field submits the current query and updates correction state only after submission.

Avoid Generating

Silently replacing the user's query without saying what changed.
Evidence trail

Source-backed claims behind this guidance

Typo tolerance

Algolia - checked

Algolia describes typo tolerance for spelling errors and typing mistakes using edit distance and ranking.

Configure typo tolerance

Algolia - checked

Algolia documents turning typo tolerance on or off, word length thresholds, numeric-token controls, disabled attributes, and exact words such as acronyms.

Suggester examples

Elastic - checked

Elastic documents term and phrase suggesters for corrections and states completion suggester is for autocomplete rather than did-you-mean behavior.

Search typo tolerance parameters

Typesense - checked

Typesense documents typo thresholds, split and joined token fallback, dropped-token fallback, and controls for numerical or alphanumerical tokens.

Spell Checking

Apache Solr - checked

Solr SpellCheckComponent provides inline query suggestions and collations but returns suggested queries rather than running them automatically.

Full agent/debug reference

Problem Context

  • The product accepts free-form submitted queries over a large content set.
  • Search relevance can compute likely spelling, phrase, split, join, or token corrections.
  • Some queries contain names, identifiers, codes, acronyms, legal references, or domain terms that must not be overcorrected.

Selection Rules

  • Choose query correction when correction happens after an explicit search submission, not while the user is merely typing.
  • Auto-apply a correction only when the corrected query is high confidence and returns useful results; otherwise show a did-you-mean candidate.
  • Always show the original query and provide a direct search-original path when corrected results are displayed.
  • Highlight only the changed query tokens or phrases, not every result card, so users can understand what changed.
  • Clear or recompute correction state when the user edits the query, changes scope, changes language, or submits again.
  • Treat fuzzy matching, synonym expansion, semantic matching, token dropping, and query correction as separate behaviors unless the changed text is explicitly disclosed.
  • Avoid correction, reduce tolerance, or require confirmation for codes, SKUs, usernames, product numbers, acronyms, quoted exact phrases, numeric tokens, names, legal terms, medical terms, and domain vocabulary.
  • Use no-results recovery rather than query correction when spelling is valid but filters, scope, availability, permissions, or empty data caused the zero-result state.
  • Use search suggestions when the user needs help forming a future query before submission; use autocomplete when the user must select a constrained known value.
  • Localize correction behavior by language, keyboard, script, stemming, plural rules, and domain vocabulary instead of assuming one global dictionary.

Required States

  • No correction state when the submitted query is exact or correction confidence is too weak.
  • Auto-applied correction state showing corrected results, original query, changed tokens, and search-original action.
  • Did-you-mean state showing one or more correction candidates that have not yet been applied.
  • Original-query state after the user chooses to search the submitted wording instead of the corrected wording.
  • Edited-query state where stale corrections clear and the new submitted query drives the result count.
  • Exact-token state where identifiers, codes, quoted phrases, or configured words bypass correction.
  • No-results-with-correction state where a correction is offered alongside normal empty-result recovery.

Interaction Contract

  • Submitting a query records the submitted text separately from any corrected query used for results.
  • If corrected results are shown, the result summary states which corrected query is active and offers a reversible action to search the original.
  • Choosing Search instead for original reruns or reveals results for the original submitted text without changing the user's typed history into the correction.
  • Accepting a did-you-mean candidate applies that candidate as the active corrected query and updates the result count.
  • Editing or clearing the search field invalidates stale correction metadata until the next explicit submit.
  • Correction candidates must be bounded, ranked, and deduplicated so users are not asked to choose from noisy spelling variants.
  • Exact-match and sensitive-token rules must be applied before automatic correction changes user intent.

Implementation Checklist

  • Store submittedQuery, correctedQuery, correctionStatus, confidence, changedTokens, and originalResultCount as distinct state fields.
  • Define confidence thresholds for auto-applied correction, did-you-mean suggestion, and no-correction fallback.
  • Configure dictionaries, exact words, disabled attributes, numeric-token rules, language analyzers, and domain-specific exceptions before launch.
  • Display correction copy in the result summary and keep the search field behavior consistent with whether the user is editing original or corrected text.
  • Provide Search original, Accept correction, edit query, and clear correction actions where relevant.
  • Log overcorrection events, search-original usage, accepted corrections, no-click corrected results, and zero-result typo queries for relevance tuning.
  • Test misspellings, transpositions, missing letters, extra letters, split words, joined words, plural forms, names, acronyms, identifiers, quoted phrases, multiple languages, mobile typos, and stale-response races.
  • Keep correction independent from autocomplete suggestions, saved searches, recent searches, highlighting, and no-results recovery actions in the data model.

Common Generated-UI Mistakes

  • Silently replacing the user's query without saying what changed.
  • Treating every fuzzy or semantic match as a corrected query.
  • Correcting identifiers, names, acronyms, product codes, or quoted terms that users intended to search exactly.
  • Showing only zero results for obvious typos when a strong correction exists.
  • Keeping a correction active after the user edits the query or changes scope.
  • Labelling pre-submit suggestions as did-you-mean corrections.
  • Hiding no-results recovery because a low-confidence correction candidate exists.
  • Displaying too many correction candidates with no ranking or explanation.

Critique Questions

  • Can users see both the original submitted query and the corrected query?
  • Is the correction auto-applied only when confidence and result quality justify it?
  • Can users search the original wording, accept a candidate, edit the query, and clear stale correction state?
  • Which tokens, fields, languages, codes, acronyms, names, numbers, or quoted phrases bypass correction?
  • Does the interface distinguish correction from autocomplete, search suggestions, synonym expansion, fuzzy matching, and no-results recovery?
  • What telemetry will reveal overcorrection, false positives, and ignored correction suggestions?
Accessibility
  • Announce correction status and result counts through a polite status region after submission.
  • Expose original and corrected query text as real text, not only color or strikethrough.
  • Use accessible names for actions such as Search original query benifit appeel and Apply corrected query benefit appeal.
  • Do not rely on color alone to identify changed tokens; pair markings with text labels or inline structure.
  • Keep correction actions keyboard reachable directly after the search summary.
  • When multiple candidates appear, use a list or group with clear labels and selected state.
Keyboard Behavior
  • Enter in the search field submits the current query and updates correction state only after submission.
  • Tab reaches Search original, Apply correction, candidate choices, edit query, and clear controls in a predictable order.
  • Escape can dismiss a did-you-mean popup or candidate menu without deleting the typed query.
  • After choosing Search original or Apply correction, focus remains near the result summary so the updated state is announced.
  • Editing the search input clears stale correction state without moving focus unexpectedly.
  • Candidate lists support arrow-key movement only when they use a combobox or listbox interaction; otherwise ordinary buttons are sufficient.
Variants
  • Auto-applied corrected results
  • Did-you-mean suggestion
  • Multiple correction candidates
  • Search instead for original query
  • Phrase correction
  • Split or joined token correction
  • Exact-token bypass
  • Language-specific correction

Verification

Last verified: