Query correction vs Search suggestions vs No-results recovery vs Autocomplete

Prefer query correction when the user has already submitted a free-form search and the system has a high-confidence spelling, token, split, join, or phrase correction for that submitted query.

Query correction live example Search suggestions live example No-results recovery live example Autocomplete live example

Decision dimensions

Dimension	Query correction	Search suggestions	No-results recovery	Autocomplete
UI or UX	UI + UX - Submitted search query correction and did-you-mean result state	UI + UX - Suggested-query surface	UI + UX - Search recovery state	UI + UX - Input widget with suggestion behavior
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.	Render a search field with query suggestions, active option, selected suggestion, and no-suggestion state.	Render zero-result copy, active criteria, remove-filter actions, and alternative suggestions.	Render a labeled text field, suggestion popup, highlighted option, selected value, and no-match state.
UX guidance	Use query correction to recover from likely spelling, spacing, transposition, or phrase mistakes after a user submits a free-form search.	Help users formulate better search queries without forcing a choice.	Help users recover when their own search or filters excluded all results.	Help users complete a known value faster without forcing an incorrect suggestion.
Good UI	A results page says Showing results for benefit appeal, marks benefit and appeal as corrected tokens, and offers Search instead for benifit appeel.	Suggestions appear directly below the search field with active row, readable labels, and optional matched text.	Zero-result state shows query/filters, result count, and clear or broaden actions.	Persistent label above the input, readable text size, clear popup alignment, and visible highlighted option.
Bad UI	The search field silently changes benifit appeel to benefit appeal and the original query is gone.	Suggestions overlay unrelated content without a dismiss path.	No results text alone with no criteria shown.	Placeholder-only label that disappears after typing.
Good UX	A user searches benifit appeel, sees corrected results for benefit appeal, checks the changed tokens, and can switch back to the original query.	Users can keep typing, choose a suggestion, dismiss suggestions, or submit their own query.	Users can remove one filter, clear all, edit query, or try suggested alternatives.	Typing filters suggestions while preserving the exact typed value.
Bad UX	The product overcorrects a claimant surname and users cannot get back to the exact original search.	Auto-submitting the top suggestion.	Telling users nothing exists when filters caused the state.	Automatically forcing the first suggestion into the field.
Best fit	Users submit free-form searches where spelling and typing mistakes commonly block useful results.	The system can predict likely queries.	Search, browse, or filter controls can produce an empty result set.	The list is long but values are known.
Avoid when	The input is a constrained value selector better served by autocomplete.	Suggestions are low quality or biased toward irrelevant content.	There is genuinely no possible next action and the system should instead explain availability.	The task is open-ended query exploration.
Required state	No correction state when the submitted query is exact or correction confidence is too weak.	No input state.	Zero-result state that preserves the user's criteria.	Empty input state.
Accessibility burden	Announce correction status and result counts through a polite status region after submission.	Expose the suggestions list and active option.	Announce result-count changes where search results update dynamically.	Expose combobox expanded state, active descendant, and option labels.
Common misuse	Silently replacing the user's query without saying what changed.	Auto-submitting the top suggestion without confirmation.	Showing a blank list with no explanation.	Forcing the first suggestion when the user did not choose it.

Query correction

UI or UX: UI + UX - Submitted search query correction and did-you-mean result state
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.
UX guidance: Use query correction to recover from likely spelling, spacing, transposition, or phrase mistakes after a user submits a free-form search.
Good UI: A results page says Showing results for benefit appeal, marks benefit and appeal as corrected tokens, and offers Search instead for benifit appeel.
Bad UI: The search field silently changes benifit appeel to benefit appeal and the original query is gone.
Good UX: A user searches benifit appeel, sees corrected results for benefit appeal, checks the changed tokens, and can switch back to the original query.
Bad UX: The product overcorrects a claimant surname and users cannot get back to the exact original search.
Best fit: Users submit free-form searches where spelling and typing mistakes commonly block useful results.
Avoid when: The input is a constrained value selector better served by autocomplete.
Required state: No correction state when the submitted query is exact or correction confidence is too weak.
Accessibility burden: Announce correction status and result counts through a polite status region after submission.
Common misuse: Silently replacing the user's query without saying what changed.

Search suggestions

UI or UX: UI + UX - Suggested-query surface
UI guidance: Render a search field with query suggestions, active option, selected suggestion, and no-suggestion state.
UX guidance: Help users formulate better search queries without forcing a choice.
Good UI: Suggestions appear directly below the search field with active row, readable labels, and optional matched text.
Bad UI: Suggestions overlay unrelated content without a dismiss path.
Good UX: Users can keep typing, choose a suggestion, dismiss suggestions, or submit their own query.
Bad UX: Auto-submitting the top suggestion.
Best fit: The system can predict likely queries.
Avoid when: Suggestions are low quality or biased toward irrelevant content.
Required state: No input state.
Accessibility burden: Expose the suggestions list and active option.
Common misuse: Auto-submitting the top suggestion without confirmation.

No-results recovery

UI or UX: UI + UX - Search recovery state
UI guidance: Render zero-result copy, active criteria, remove-filter actions, and alternative suggestions.
UX guidance: Help users recover when their own search or filters excluded all results.
Good UI: Zero-result state shows query/filters, result count, and clear or broaden actions.
Bad UI: No results text alone with no criteria shown.
Good UX: Users can remove one filter, clear all, edit query, or try suggested alternatives.
Bad UX: Telling users nothing exists when filters caused the state.
Best fit: Search, browse, or filter controls can produce an empty result set.
Avoid when: There is genuinely no possible next action and the system should instead explain availability.
Required state: Zero-result state that preserves the user's criteria.
Accessibility burden: Announce result-count changes where search results update dynamically.
Common misuse: Showing a blank list with no explanation.

Autocomplete

UI or UX: UI + UX - Input widget with suggestion behavior
UI guidance: Render a labeled text field, suggestion popup, highlighted option, selected value, and no-match state.
UX guidance: Help users complete a known value faster without forcing an incorrect suggestion.
Good UI: Persistent label above the input, readable text size, clear popup alignment, and visible highlighted option.
Bad UI: Placeholder-only label that disappears after typing.
Good UX: Typing filters suggestions while preserving the exact typed value.
Bad UX: Automatically forcing the first suggestion into the field.
Best fit: The list is long but values are known.
Avoid when: The task is open-ended query exploration.
Required state: Empty input state.
Accessibility burden: Expose combobox expanded state, active descendant, and option labels.
Common misuse: Forcing the first suggestion when the user did not choose it.

Decision rules

Prefer query correction when the user has already submitted a free-form search and the system has a high-confidence spelling, token, split, join, or phrase correction for that submitted query.
Prefer search suggestions when the user is still composing the query and suggestions should help phrase possible future searches without implying the current query is wrong.
Prefer no-results recovery when the query or filters are valid but the result set is empty, so the fix is broadening criteria, removing filters, changing scope, or browsing alternatives rather than correcting spelling.
Prefer autocomplete when the task is selecting a constrained known entity, code, address, product, person, or command from allowed options before submission.
Auto-apply corrected results only when confidence is high enough and the interface preserves the original query with a visible search-original path.
Use a did-you-mean prompt instead of automatic correction when several plausible corrections exist, the domain contains names or codes, or correction confidence is weak.
Do not route every zero-result query to query correction; if spelling is already valid, keep the original query and use no-results recovery actions.
Do not treat fuzzy matching or synonym expansion as query correction unless the changed query text is disclosed and reversible.
Keep correction copy tied to the submitted query, not to every keystroke, hover, autocomplete preview, or filter change.
Disable or constrain correction for identifiers, SKUs, usernames, legal references, medical terms, acronyms, quoted exact phrases, numeric tokens, and domain vocabulary that users may intentionally search exactly.

Inspect live examples

Query correction Search suggestions No-results recovery Autocomplete

Failure modes

The product silently rewrites the search field from benifit appeel to benefit appeal and users lose the original wording.
A name, code, or acronym is overcorrected into a common word and the interface offers no way to search the original.
The UI says no results even though a credible spelling correction exists and no did-you-mean path is shown.
The correction remains active after the user edits the query, producing stale results for a different phrase.
Autocomplete suggestions are labelled as spelling corrections before the user has submitted a query.
No-results filter recovery is hidden behind a spelling suggestion even though the spelling is correct and filters caused the empty result set.