ui-001 should GuidesAPI docs Bold all UI element names (buttons, menus, dialogs, panes, tabs, checkboxes, toggles, commands, and so on) when referenced in instructions.
These rules cover formatting UI element names, choosing interaction verbs, writing keyboard keys and menu paths, and the standard terms for common elements. Step-by-step structure lives in procedures, and when to show the UI in an image lives in screenshots.
ui-001 should GuidesAPI docs Bold all UI element names (buttons, menus, dialogs, panes, tabs, checkboxes, toggles, commands, and so on) when referenced in instructions.
Examples
Rationale
Bold marks a UI element name so the reader can spot the exact control to act on in a step.
ui-002 should GuidesAPI docs Use sentence-style capitalization for UI element labels in instructions; match the UI only when the label is consistently cased in mixed or title case.
Examples
Rationale
Sentence-cased labels stay consistent with the guide unless the UI itself uses a fixed casing to match.
ui-003 should GuidesAPI docs Avoid naming the UI element type (‘button’, ‘dialog box’, ‘pane’) unless omitting it would reduce clarity.
Examples
Rationale
Naming the element type is redundant when the label and bold already identify it, unless it aids clarity.
ui-013 should GuidesAPI docs Omit trailing ellipses from UI element labels when referencing them in instructions.
Examples
Rationale
The ellipsis on a label is not part of its name, so instructions leave it off.
ui-010 should GuidesAPI docs Use a greater-than symbol (>) with spaces on both sides to abbreviate sequential UI selections; do not bold the symbol itself.
Examples
Rationale
A spaced greater-than sign compactly shows a menu path, and not bolding it keeps it separate from the labels.
ui-004 should GuidesAPI docs Use ‘click’ as the primary verb for mouse/pointer interactions, with ‘tap’ for touchscreen interactions and ‘select’ for checkboxes, radio buttons, and list items.
Examples
Rationale
Matching the verb to the input keeps instructions accurate across mouse, touch, and selection.
ui-005 should GuidesAPI docs Use ‘select’ and ‘clear’ (not ‘check’ and ‘uncheck’) for checkbox interactions.
Examples
Rationale
“Select” and “clear” are input-neutral and unambiguous, while “check” can be read as “verify.”
ui-006 should GuidesAPI docs Use ‘turn on’ and ‘turn off’ (or ‘switch’) for toggle interactions; do not use ‘toggle’ as a verb.
Examples
Rationale
“Turn on” and “turn off” describe a toggle’s result plainly, while “toggle” as a verb does not say which way.
ui-007 should GuidesAPI docs Use ‘press’ for keyboard key actions that trigger a function, and ‘enter’ or ‘type’ for keyboard input that produces text.
Examples
Rationale
“Press” fits a key that triggers an action, while “enter” or “type” fits producing text, so the reader knows what to do.
ui-008 should GuidesAPI docs Spell out modifier key names in full (Control, Command, Option, Shift) rather than using abbreviations or symbols.
Examples
Rationale
Full key names are unambiguous across platforms, unlike symbols that vary.
ui-009 should GuidesAPI docs Format keyboard keys and shortcuts using a distinct visual treatment, such as <kbd> tags or bold, and capitalize key names.
Examples
<kbd>Esc</kbd> to close the panel.Rationale
A distinct visual treatment marks a key so it is not mistaken for ordinary text.
ui-014 should GuidesAPI docs Use the preposition that matches the UI element’s spatial metaphor: ‘in’ for container elements (dialogs, fields, lists, menus, panes, windows, sections) and ‘on’ for surface elements (pages, tabs, toolbars, canvases). If an element could reasonably be either, either preposition is acceptable; stay consistent within a document.
Examples
Rationale
The prepositions track how English speakers describe space: you are in a bounded region like a dialog or pane, and on a flat surface like a page or tab. Framing it as that principle lets an author apply it to new UI patterns.
ui-011 should GuidesAPI docs Avoid directional language (above, below, left-hand side, right-hand side) to orient users to UI elements; use screenshots, icon names, or contextual labels instead.
Examples
Rationale
“Above” and “on the left” break when layout reflows or is read linearly, so a name or label is stable.
ui-012 should GuidesAPI docs Do not use slang or informal terms for UI elements (‘hamburger icon’, ‘zippy’, ‘expando’).
Examples
Rationale
Slang names are not universal and do not translate, so a plain description works for everyone.
ui-015 should GuidesAPI docs Use ‘dialog’ (not ‘pop-up window’ or ‘dialog box’) for a smaller window that appears in front of the main application window.
Examples
Rationale
“Dialog” is the precise term for a small window over the main one, while “pop-up” and “dialog box” are looser.
ui-016 should GuidesAPI docs Use ‘page’ (not ‘window’) when referring to a web page or a subpage of a console; use ‘window’ for the full application window in a desktop environment.
Examples
Rationale
“Page” fits web content and “window” fits a desktop app, so the right term matches what the reader sees.
ui-017 should GuidesAPI docs Use ‘navigation menu’ (not ‘navigation bar’, ‘navigation pane’, ‘navigation panel’, or ‘navigation window’) for a control containing a list of navigable items.
Examples
Rationale
One consistent term for the navigation control keeps references clear across the docs.
ui-018 should GuidesAPI docs When referring to an item in a menu, use ‘menu item’ or ‘command’ based on context: prefer ‘menu item’ in procedural instructions where location matters or when the item isn’t a direct command, and prefer ‘command’ when emphasizing the action, discussing command-line interfaces, or referring to keyboard shortcuts. Avoid ‘choice’ and ‘option’.
Examples
Rationale
“Menu item” and “command” describe the same thing from different angles, one by location and one by action, so allowing both lets an author pick the word that fits the sentence instead of forcing a single term.