The same concept keeps the same wording on every surface

What it is

Screens in one package will name the same object differently, and implementation will build every name. Surface-consistent wording requires that, in the screens, notes, and string table about to ship, one concept uses one chosen phrase: if navigation says “Workspace,” Settings must not switch to “Project,” and the empty-state action must not invent “Create a space.” The test is whether this shipment contradicts itself, not whether the company has a termbase, forbidden list, and migration process.

Which word you pick can still change before ship. Once the materials go out containing two words, implementation has no referee and will ship both.

Why it happens

Implementation copies strings per screen; it does not deduplicate by concept. A list that says “Archive,” a detail page that says “End,” and a confirm that says “Close” become three function names, three help-search terms, and three user models. Inside a design file the split usually comes from different frame authors, revisions weeks apart, or a near-synonym swapped so a label would fit a narrow button. Visual walkthroughs miss it: each frame is fine alone; the clash appears only when entry sentences for the same task are laid side by side.

The package is the only source collection engineering sees. Inconsistency inside it enters code with the status “design said so.” Unifying later means renaming identifiers, translation keys, and users who already learned the old names. Same wording is not a style preference. It is collapsing the concept to one surface form before it enters code. When a narrow slot cannot hold the phrase, change the layout or register an approved short label — do not quietly swap a cousin verb.

Where it stops holding

A short button label and a full name in a paragraph can coexist if the package states they are the same concept and which string is the abbreviation. User-chosen names, legal source text, and third-party product names must keep their source wording; do not rewrite them for internal neatness. A wizard that teaches with everyday language and then transitions to the product name needs that transition drawn in the flow, so other entries do not borrow the teaching word early. If different roles truly see different concepts (an admin’s “Members” versus a guest’s “Participants” under different permission models), forcing one word erases the distinction — confirm they are the same concept before demanding the same phrase.

Applying it

• Before ship, pile every visible string in the package by concept. One chosen phrase per object, action, and state; mark the others to change. Do not leave “either is fine” for implementation.
• When a narrow button needs fewer characters, register that short label as the approved short form of the concept and reuse it in every equally narrow slot. Do not let each slot abbreviate on its own.
• Serve every occurrence from one string key. Do not open a near-synonym key to save a single frame’s layout.
• Walk one primary path and copy every name for the same object onto one table. If two words appear, fix the design source and the copy source until one remains, then hand it to implementation. Do not merge synonyms at code review.

Related

• Same group: R2.06.1 Placeholder copy will be implemented as written · R2.06.2 Copy length changes the layout · R2.06.3 Copy and design must be reviewed in the same pass · R2.06.4 Variable ranges must ship with the copy · R2.06.6 Handoff must reserve space for translation length
• Adjacent: T1.04 Terminology Consistency and Glossaries · R2.01 Annotation and asset export
• Search terms: surface-consistent wording · handoff wording drift · same phrase per concept