UX Patterns Guide
My learning 0 of 20 lessons complete
Start lesson 1 →

Application · lesson 10 of 20 · Search, Browse, And Discovery

Query correction

Underlying principle: Discovery supports several starting points: a known term, a broad category, a partial memory, or a set of constraints. The interface helps people refine their understanding while they search.

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.

Start with the decision

Does this fit your task?

Users submit free-form searches where spelling and typing mistakes commonly block useful results.

Review the boundary: Compare the task with the alternatives in the decision section.

Review the decision →
Try the live example →Compare alternatives →
Study the interaction

Follow the task before choosing the component

Discovery supports several starting points: a known term, a broad category, a partial memory, or a set of constraints. The interface helps people refine their understanding while they search.

01 / Recognize the need

What the person is doing

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

02 / Design the response

What the interface must communicate

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.

Auto-applied correction state showing corrected results, original query, changed tokens, and search-original action.

03 / Judge the outcome

What to look for

Can users see both the original submitted query and the corrected query?

Submitting a query records the submitted text separately from any corrected query used for results.

Practice this pattern: Sketch query correction for this situation: Users submit free-form searches where spelling and typing mistakes commonly block useful results. Include this state: Auto-applied correction state showing corrected results, original query, changed tokens, and search-original action. Review your sketch with this question: Can users see both the original submitted query and the corrected query?

Study the Search, Browse, And Discovery family →Read the underlying principle →
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.

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.
  • The issue is filters, permissions, scope, or empty data rather than spelling or phrase mistakes.

Problem it prevents

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

Test the behavior

Open the interactive example when you need it

The full lab is intentionally loaded on request. That keeps this reading page fast while preserving the strong and weak states, keyboard checks, and failure scenarios.

In the lab you can
  • switch between strong UI, weak UI, strong UX, and weak UX;
  • trigger required, empty, loading, error, and recovery states;
  • inspect keyboard and accessibility expectations beside the demo.
Launch Query correction in the lab
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

Auto-applied correction state showing corrected results, original query, changed tokens, and search-original action.

Failure to inspect

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 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.
  • A user searches an exact policy code and the system avoids typo correction because the token is in the configured exact-match vocabulary.
Weak implementation

Vague, hidden, hard to recover from

  • The search field silently changes benifit appeel to benefit appeal and the original query is gone.
  • The UI reports zero results for an obvious typo even though a high-confidence correction is available.
  • A correction remains applied after the user changes the query, making the result count belong to old text.
  • Silent query rewriting breaks user trust and makes exact lookup impossible.
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

  • Auto-applied correction state showing corrected results, original query, changed tokens, and search-original action.
  • 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.

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.
  • 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.

Accessibility

  • Announce correction status and result counts through a polite status region after submission.
  • Use accessible names for actions such as Search original query benifit appeel and Apply corrected query benefit appeal.
  • 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.

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?
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

Source trail checked:

Saved items