T3.02.3Controlled user-language retrieval for helpdesignresearch

Search must tolerate user vocabulary and synonyms

Aliases: user-vocabulary search · controlled synonym · spelling tolerance · retrieval intent

What it is

Controlled user-language retrieval for help maps users' descriptions of tasks, symptoms, and outcomes, along with controlled synonyms, spelling variants, and morphological forms, to stable concept or task IDs. Here, intent means the result or recovery path a person seeks, not an inference about their identity, ability, or psychology. Tolerance should be bounded, explainable, and reversible rather than indiscriminate fuzzy matching of every similar string.

Why it happens

Users often describe a real-world task or visible symptom while help content indexes only canonical product terms. Inflection, tokenization, spelling differences, and colloquial phrasing widen the gap. A controlled mapping can connect “get my money back” to the canonical refund task, while a concept ID preserves the relationship among copy, index, and interface. Unbounded spelling or semantic expansion can instead mix similar but distinct failures, permissions, or high-risk actions.

Studying it

Build a de-identified query-to-task evaluation set from zero results, reformulations, support language, and task failures. Retain only necessary strata such as language, script, device, and entry; do not retain raw sensitive queries. Test user phrases, controlled synonyms, spelling and morphological variants, and outcome intent separately, with relevance judged by content and task experts. Inspect recall, precision at the top, zero results, reformulation, task resolution, and harmful high-risk results rather than treating clicks as sufficient evidence of understanding.

Where it stops holding

The termbase governs concepts, preferred and prohibited terms, and controlled aliases. This leaf consumes that data and validated user expressions to improve help retrieval; it does not silently change canonical interface terminology. General search-system entries own cross-domain input, correction, and ranking mechanisms. This leaf governs only vocabulary mapping, indexing, and query policy for help content. Authorization must precede result counts, snippets, and suggestions so retrieval does not disclose the existence of restricted features or content.

Applying it

  • Define locale-specific tokenization, morphology, and spelling rules. Preserve the original query during normalization rather than silently replacing user input.
  • Maintain a user-expression → concept or task ID map with source, locale, applicable context, owner, version, and invalidation rule. Review changes and include them in regression tests.
  • For correction or intent expansion, show what the system is searching for and allow users to undo, restore the original words, or narrow scope. Apply stricter thresholds to high-risk tasks.
  • Enforce access control before producing result counts, snippets, or recommendations. Minimize, redact, restrict, and expire query logs; regularly review zero results, false positives, and stale mappings.

Related

  • Same group: T3.02.1 Organize help by user task, not by feature module · T3.02.2 Help entries belong next to where problems occur
  • Adjacent: T1.04.1 Use exactly one term per concept across the product · T2.05.1 Distinguish no-data, no-match, and error states
  • Search terms: controlled synonym mapping · query intent · privacy-safe help search

Cards in the same group

Quick Actions

Share

Share this page

ios_share

https://hci.top/en/handbook/T3.02.3