Search should recognize different phrasings of the same request as the same target

What it is

Synonym mapping routes the many different phrasings a user might use for the same function or concept to a single internal target, paired with fault tolerance in the search layer so a query hits regardless of which word the user chose. This doesn't solve "pick a better name" — it accepts the premise that no single name can cover most people, and instead builds a many-to-one map between phrasings and the target.

Why it happens

Free-naming studies repeatedly show that no single term's spontaneous-use rate reaches a majority of users, so chasing "a name everyone understands" by iterating on the label itself hits a low ceiling by construction. Synonym mapping reframes the problem from "which word" to "which coverage table": the system keeps one canonical name internally for implementation and maintenance, while the search layer routes many user-side phrasings to that canonical name. The burden of naming choice moves from interface copy to data structure and retrieval logic, and the two can then iterate independently of each other.

Studying it

Candidate synonyms come from three sources: naming studies, failed queries pulled from real search logs, and the range of phrasings users give the same function in support tickets. Coverage is quantified by running every free-form term collected in a naming study against the existing alias table and measuring the share that resolves successfully; the terms that don't resolve are the candidates that need adding.

Where it stops holding

Synonym mapping fixes lexical mismatch, not the deeper case where the user has no corresponding concept at all — if someone is searching for a function the system simply doesn't have, no amount of alias coverage routes the query to anything, and the fix is adding the feature or telling the user it doesn't exist, not expanding the map. The map also needs ongoing maintenance: as product language evolves, old aliases go stale, and a one-time build doesn't stay accurate on its own.

Applying it

• Build the synonym index for the search layer from three sources — naming studies, zero-result search-log queries, and support-ticket phrasings — and keep the canonical name for internal implementation and long-term maintenance only, without forcing users toward one shared phrasing.
• Put this mapping inside the search and command-palette retrieval logic, rather than trying to cover every phrasing by repeatedly rewriting the displayed label.
• Verification: periodically re-run historical zero-result queries against the updated index and track the share that now resolves. A resolution rate that stays flat over time means alias additions aren't keeping pace with how the product's language is evolving, and it's time for another round of naming research.

Related

• Same group: A11.05.1 The gap between users' words and the system's words · A11.05.2 Jargon fails at cross-discipline interface boundaries · A11.05.3 Abbreviations need a nearby expansion point
• Adjacent: G1.10 Controlled vocabularies and synonyms
• Search terms: synonym mapping · alias index · zero-result search