Summary: Labels for commands should be brief, informative, rely on verbs and adjectives, and avoid branded terms. Command shortcuts must limit the number of modifiers and follow standard conventions.

Users want to be efficient with their time. Transparent command names and command shortcuts help users bridge the gulf of execution and are essential for a smooth, fast, and painless interaction. Though often overlooked, these textual elements enable users of all types, including those with disabilities, to move quickly through our digital products.

Definition: User-Interface copy (UI copy) refers to labels for commands that appear in buttons, menu items, and other action-oriented elements in the user interface.

Understanding UI Copy

The phrase “UX copy” is also sometimes used to refer to these elements, but we prefer to use the more precise, less ambiguous term “UI copy” for these actionable items, as opposed to long-form content that’s intended to be read, but not clicked. UI copy is also different from microcontent (or microcopy), which represents very short content used for headlines, email-subject lines, page titles, or tooltips.

UI copy is also different from link text. Links simply help users navigate through a linked content space, whereas commands are associated with interaction flows and typically change the state of the system. They are normally displayed as buttons, icons (preferably with labels or at least hover text), menu items, radio buttons, or other similar UI elements.

Commands are the bread-and-butter of applications; because applications often need to offer a large number of features and commands, command names are usually short — there is simply not a lot of space in an application screen to accommodate a lot of long command names. That means there is pressure to create command labels that capture the meaning of the command in a concise way.

Guidelines for Effective UI Copy

Keep command text short without sacrificing clarity. One-word, self-explanatory command text is easiest to scan, but obscure commands or those used infrequently will require more context. Use just enough text to accurately describe the command and include no more than 2–4 words. Avoid overexplaining commands and remove articles (“a”, “an”, and “the”) to speed up scannability, comprehension, and task completion. While short commands are preferred, use enough text to explain the command sufficiently.

Describe the consequent state, not the current state. Commands should always reflect the state the system will move into, rather than the current state. For example, when a video is playing, we see a Pause button, which signals the state the video will move into as a result of clicking the icon. This type of changeable label helps to communicate subsequent states while preserving space in the interface. If all commands were always displayed, the UI would become overly cluttered and highly confusing.

Use verbs for commands that initiate an action or submit information. Lead with verbs or verb phrases that clearly outline what will happen after the command is selected. For example, Print or Accept and Sign In. Common labels such as Back, Forward, New, Next, Previous, Undo and Settings are generally recognized by users and therefore, don’t need to be accompanied by verbs. However, remember that they (e.g., Next, Previous) can be vague and too general and, whenever possible, prefer a specific verb to one of these generic names.

Use adjectives for commands that trigger a change in the state of the system or the appearance of an element in the interface. The adjective should always reflect how the element will change. For example, for text editing, adjectives such as, Regular, Bold, or Italic are used to describe the change in appearance.

Avoid using vague command names. Users shouldn't have to Google a command name to understand what means, what it does, or how it differs from other commands. Command text should be straightforward, descriptive, and accurate; not cutesy or faddish.

Users shouldn't have to Google a command name to understand what means, what it does, or how it differs from other commands. Command text should be straightforward, descriptive, and accurate; not cutesy or faddish. Include tooltips to clarify outcomes. When icons or buttons are used to initiate an action, include tooltips that activate on rollover, and provide contextual help so that users understand exactly what will happen. Whether you use native tooltips, custom-designed tooltips, or a combination of both, the explanation in the tooltip should be informative and nonconflicting.

Limit the use of branded terms. The application’s name can be used as a label for the main application menu. And, while branded terms can add helpful context to menu items under the Help menu, in most cases, they should be avoided in command text. Users who aren’t familiar with a task flow or application won’t understand what they mean.

Use consistent command words, even if they appear in different contexts. If the same command appears in more than one menu, dialog box, or task flow, use the same label text in each instance and place it in a similar position. When the resulting action or the element impacted is not clear from the verb or adjective alone, use a noun after the verb to disambiguate the context — for example, Draw Table or Delete Folder, rather than Draw or Delete.

Avoid generic command text such as OK. Avoid using the generic phrase OK for button labels in confirmation dialogs. Out of habit, users might select it without reading the surrounding text, assuming that it’s the correct option. Explicitly state what users are doing by pushing that button. In the event that users do make an error, always include the ability to undo their actions and use clear UI copy to help users recognize Undo or Cancel as an available option.

Include ellipses (“…”) in command text to indicate when more information will be required. Ellipses distinguish commands that need arguments (in the form of further input from users) from immediate ones. Ellipses can also indicate that a selection hasn’t been made yet and lead users to make a choice.

Guidelines for Command Shortcuts

In addition to command text, the text and symbols that communicate command shortcuts are also considered UI copy.

Definition: Command shortcuts are combinations of keys that are typed on the keyboard and allow users to perform frequent commands quickly.

Command shortcuts are different from access keys: whereas access keys allow users to select a command from a visible (expanded) menu by typing a character on the keyboard, command shortcuts usually involve function keys and allow the direct invocation of a command, however deeply it may be buried in a command menu.

Thus, common examples of command shortcuts are Ctrl + S to save or Command + N to open a new browser window. Shortcuts help to speed up movement through the interface and simplify the completion of frequent tasks. For example, typing Ctrl + V or Command + V is faster than finding the copy and paste functions from the menu. However, UI copy and familiar conventions are needed to make users aware of these time savers and remember them, especially when there is little room to communicate about them in the interface.

Prioritize keyboard shortcuts for frequent app tasks. Not every task on your application needs a shortcut, so observe your users interacting with your application to determine the most common tasks and prioritize keyboard shortcuts for these. For example, when users access Facebook through a desktop browser, they can use a set of keyboard shortcuts to quickly navigate the interface and complete usual actions. (Interestingly, Facebook also has a section called Shortcuts that appears in the left navigation and refers to commonly used pages. To ensure users don’t get confused between keyboard shortcuts and quick-access points in the app, include the words keyboard shortcuts in the label for the command shortcuts.)

Don’t repurpose or override standard command shortcuts. Some command shortcuts (e.g., Ctrl + S or Command + S to save) have a widespread use and many people have become accustomed to them. Don’t overload these commands — for example, don’t use Ctrl + S to scroll the page. When creating new shortcuts, always consider the keyboard shortcuts required for accessibility to prevent interference with assistive technologies.

Make shortcuts discoverable and redefinable. Equivalent shortcuts should be available for both Mac and Windows operating systems and users should have the ability to define their own shortcuts, aside from the defaults set by the application. Provide quick points of reference; if a shortcut is available, include the function key(s) and sequence of additional keys alongside the command text in tool tips. Help sections should also include printable images, cheat sheets, or lists of keyboard shortcuts that users can easily find and share.

Shortcuts should be learnable and memorable. Don’t set a keyboard shortcut just because you think the combination is unique; it needs to be easy to learn and memorize. Use a clear, consistent system and always associate symbols and functions with the name of the button on the keyboard. Many users don’t know what certain symbols or button names mean off the top of their heads, without looking at the keyboard itself.

Use minimal modifiers. Be conscious of how many shift, control, option, and command functions you include in your shortcuts. The simpler the better. If possible, rely mostly on one- or two-letter shortcuts to ensure they help users rather than increasing their memory burden.

Conclusion

Well-written command names and familiar shortcuts direct users through the interface and help them learn how to use it. In contrast, poorly chosen UI copy confuses people and forces them to spend time to figure out how to use your UI. To learn more about writing meaningful command text, take our full-day training courses Writing Compelling Digital Copy and Application Design for Web and Desktop.