Use users’ language rather than system terminology
Aliases: user language · interface copy · terminology design
What it is
Interfaces should use the objects, actions, and states users speak about during the task—“customer,” “refund,” “awaiting review”—rather than exposing database tables, APIs, internal codenames, or engineering abstractions. This match between system and real world means users should not have to learn a second vocabulary.
Why it happens
Existing words carry object boundaries, responsibility, and expectations for the next step. System terms force users to build mappings: is invoice_record a bill, does sync publish, can role_2 approve? Mapping errors become wrong entry points and misunderstood consequences. Good language is not casual language; expert users may need domain terms, but they must be the domain’s stable term.
Studying it
Collect support logs, task interviews, tickets, and search queries to build a mapping between users’ names and system objects. Test candidate words through naming, explanation, and findability tasks: ask users to define objects, locate targets, distinguish near-synonyms, and predict action results. Count synonym confusion, misclassification, and help seeking.
Where it stops holding
User language can be vague, local, or internally inconsistent, so contradictory labels should not be copied verbatim. System terminology may be necessary in diagnostics, audit, and advanced configuration; the issue is letting it be the only expression in the main flow. Localization also requires validating local business terms rather than literal translation.
Applying it
- Maintain a standard vocabulary for core objects with banned synonyms, plural forms, and abbreviation rules.
- Review every navigation item, button, and error message; replace table names, code names, and internal project jargon.
- Run real tasks in which users find objects and explain button outcomes; flag words they cannot paraphrase.