Command names must match terms used elsewhere in the UI

What it is

The toolbar says Archive, the menu says File away, the undo stack says Move to cabinet, and the shortcut legend says Archive again. People cannot treat those strings as one command. They think the product does three things, or that the toolbar action is missing from the menu. Command naming consistency requires the menu item, button, tooltip, undo string, and command-palette hit to share one user-visible name. It is not a general copy rule about sounding professional or leading with verbs. It is that the menu, as a discovery channel, must point at the same object as every other entrance.

Why it happens

People use the name as a retrieval key. After seeing Archive on a toolbar, they look in the menu for those two words, not for a cloud of near-synonyms. Inconsistency splits one recognition into several guesses. A tooltip teaches one word, the menu another; if the command palette indexes only menu titles, the toolbar word returns nothing. Shortcut learning is bound to the label shown beside the menu item; if that label disagrees with the button, people assume the shortcut drives something else. Worse is undo: the button said A, the undo row says B, and people will not undo for fear that B was not the last act. The name is identity across surfaces, not a title each piece of UI is free to invent.

Studying it

Run a “re-identify the same command” task: meet the name on one surface (button or tip), then retrieve it in the menu or palette. Use deliberate synonym splits as a control.

Independent variables: whether menu name equals button name, whether synonym indexing is allowed, whether the undo string reuses the command name. Dependent variables: success retrieving the menu item from the button name, empty searches in the palette, hesitation at undo, whether people later believe those were two functions.

Internal review will not see the split—people who wrote the code have already merged the synonyms. Use people who have not seen the product, and test from a four-column copy table, not from a satisfaction score.

Where it stops holding

Platform-conventional words (Cut, Paste) must follow the system menu even if the product wants a wittier verb; otherwise skill fails to transfer across apps. After localization, every surface must follow the same string; the menu cannot be one translation and the button another. When an object name enters the command (“Delete page 3”), the verb still has to match the menu verb; only the object changes. A command palette may index synonyms for matching, but there can be only one primary display name, and those synonyms should not also appear on buttons.

Applying it

• Give each command one user-visible primary name; menu, button, tip, undo, and palette hit all cite it. Do not let each surface write its own near-synonym.
• Rename everywhere at once, including shortcut tables and doc headings, so the menu does not move on while the toolbar keeps the old word.
• The palette may index aliases, but the result row should show the primary name so people can match it to the menu.
• Verify: pull twenty commands and lay menu copy, button copy, undo copy, and palette keywords in four columns. Any row with a second word gets a “find the menu from the button” test; a miss is the split.

Related

• Within the group: K2.09.1 Group commands by use situation, not by development module · K2.09.2 Deep menu nesting makes infrequent commands undiscoverable · K2.09.4 Situational items should change availability, not disappear
• Adjacent: T1.04 Terminology consistency and glossaries · K2.03 Menu Bar · T2.01 Button and action copy
• Search terms: command naming · lexical consistency · label matching