The gap between users' words and the system's words

What it is

The word a user reaches for when describing their goal and the label the system puts on screen are often not the same word — this is the vocabulary gap, also known as the vocabulary problem. Users' words come from the task and everyday language; the system's words often come from the implementer's internal model — the name of a data structure, a module, a label an engineer picked in passing. Both vocabularies are internally coherent and "correct," they just don't point at the same mental map.

Why it happens

This isn't merely "the label isn't plain enough" — the scale of the mismatch is far larger than intuition suggests. When independent people are each asked to name the same everyday concept, the odds that two of them pick the same word are often below 20%. In other words, no single "best" label was ever going to cover most users, not because the designer chose the wrong word, but because word choice itself is highly divergent across a population — there is no word that is most people's first instinct simultaneously. System vocabulary drifts systematically away from user vocabulary because the people who name things are themselves domain experts whose "first instinct" has already been trained by implementation details, and no longer represents where an ordinary user starts.

Studying it

The standard way to measure the vocabulary gap is a free-naming study: ask target users to write down, without seeing the interface, the word they would use for a given function or concept, then compute the overlap between those words and the system's actual labels — a low overlap rate is the evidence for the gap, not a designer's hunch that a label "sounds clear enough." Open card sorting (letting participants invent their own category names rather than choosing from a fixed set) is the same logic applied to grouping, and its resulting labels can likewise be compared against the system's existing categories.

Where it stops holding

The size of the gap tracks how much shared training the target population has: systems built for a single professional group that has gone through uniform training (accounting software for licensed accountants) already have user vocabulary converging on industry terms, so the gap is narrow; consumer products serving a heterogeneous population typically show the widest gap. The gap also isn't fixed over time — users absorb the system's own vocabulary the longer they use it, so the gap narrows with tenure. A naming study therefore captures the starting point of a new or prospective user, not the steady state of an experienced one.

Applying it

• Run a free-naming study with the target population before finalizing any user-facing label, menu item, or feature name — don't let the design team vote internally on whichever word "sounds clearest."
• Treat the naming study's output as a frequency distribution: record the top candidate words and each one's coverage share, rather than picking a single "winning" term — the coverage number itself tells you how much of the user base a single label can capture.
• Verification: put candidate labels into a task-based usability test and have participants guess the function from the label alone, then measure accuracy. If accuracy is well below the word's self-reported usage share from the naming study, the label has shifted meaning again inside the actual interface context (surrounding elements, icon, position) and needs re-testing.

Related

• Same group: A11.05.2 Jargon fails at cross-discipline interface boundaries · A11.05.3 Abbreviations need a nearby expansion point · A11.05.4 Synonym mapping and search fault tolerance
• Adjacent: A11.04.1 Novices rely on recognition, experts on recall
• Search terms: vocabulary problem · naming study · open card sort