Inconsistent terms are read as different features

What it is

When the interface swaps in a near-synonym, the default reading is not “the copy found another phrasing.” It is “this is a different feature.” Sidebar “Messages” and top-bar “Notifications,” a button that says Submit and a success page that says Sent, get taken as two mechanisms. Inconsistent terms are read as different features: people assume a system will not change words for nothing, so a changed word must mark a difference worth finding. They then hunt for a difference that is not there, or conclude an entrance is missing.

This leaf is about that interpretive consequence. One label per concept across the site is the discipline; this is how the mental model is rewritten once that discipline breaks.

Why it happens

An interface is treated as a formal language. Two signifiers for one extension lead the listener to invent two signifieds, to keep the assumption that the system does not tautologize. The pressure is stronger than hearing synonyms in ordinary speech, because controls occupy scarce choice slots and every word is taken as an intended opposition. The difference is filled in as: different scope, different freshness, different permission, different read-state. Even when the fill-in fails, the conclusion “they are two things” is not withdrawn; it turns into anxiety.

Search and support chat inherit the split: people ask with one word, hit documentation written in the other, and both sides believe they are talking about the same feature.

Studying it

Measure “how many features is this,” not “do these words seem close.”

• Paradigms: have people complete a task under word A, then show word B elsewhere (same backend object) and ask whether this is the same thing as before and what the difference is; record invented false differences.
• Independent variables: semantic distance of the pair, whether both appearances look like entrances, presence of a joining gloss.
• Dependent variables: rate of judging them different features, types of invented difference, extra steps taken to “find the other one.”
• Methodological note: asking “are these synonyms” yields a linguistic answer. Put it in a task so people decide whether to look for a second entrance. Experts and staff already know it is one system and will badly underestimate the split.

Where it stops holding

Where there is a functional difference, the words must differ; this leaf does not encourage collapsing “Draft” and “Published” into one word for a fake consistency. When legal wording and lookup wording must coexist, join them explicitly, or people will still invent a difference; the join itself admits the split risk. When product lines keep different terms on purpose (an acquired brand), the split is intended: mark product identity at account and nav boundaries, rather than swapping words inside one product.

Applying it

• Walk core objects as “how many features would this be taken as”: does the wording in nav, buttons, notices, and empty states let someone invent a second mechanism.
• On a near-synonym entrance, merge the wording. Do not patch with “i.e. xxx” except when joining a legal name.
• If two words truly name different mechanisms, put the difference on the side of the label that can eliminate (Unread notices vs Direct messages). Do not leave people to guess.
• Verify by giving both words to someone who has not been told the backend truth, and asking whether they still need to find another entrance. “Yes,” with no real difference to name, means the terminology is already minting ghost features.

Related

• Within the group: G1.08.2 Synonyms need mapping, not coexistence · G1.08.3 The glossary must cover UI, docs, and search
• Adjacent: G1.04 Labeling systems · G1.10 Controlled vocabularies and synonyms · T1.04 Terminology consistency and glossaries
• Search terms: terminology inconsistency · false feature differentiation · label drift