I'm establishing some style guidance for naming items which are accessed from my application's menu bar.

What are the commonly accepted rules for naming menu items?

When should the names of the menu items begin with verbs? Adjectives? Nouns?

When should an ellipsis be required? (e.g, "Tools > Options...")

  • This is kinda open-ended. Maybe provide a screenshot with a menu open. It will help focus the answers.
    – Glen Lipka
    Apr 21, 2010 at 17:36
  • Thanks, I considered that, but didn't want to be too focused on my specific problem. I was hoping to capture some general guidance that I and others can draw from.
    – barry
    Apr 22, 2010 at 15:05

4 Answers 4


The standards cited by Paul Hibbitts on this page give some general naming guidelines and also explain how to use ellipsis (hint: “Tools > Options...” is wrong).

Here are some additional guidelines pulled together from various other sources.

Menu names should be short, clear, and concise to speed reading and recognition. Ideally, a name should be a single word. Each word must be “high value” providing the most information about what the menu item does and distinguishing the menu items from each other. This implies:

  • Do not use sentences (e.g., use Copy, not I Want You to Copy this).

  • Do not include articles (e.g., use Generate Network, not Generate the Network).

  • Do not use etiquette (e.g., don’t use Please Generate Network).

  • Do not include instructional text (e.g., don't use Click Here to Generate Network).

  • Do not include the implementation in the command (e.g., don’t use Network Generation Wizard).

  • Generally use verbs for names, indicating the action the menu item commits or purpose it serves (e.g., Copy, Undo). Avoid names of entities or states (e.g., don’t use Copier, Reversion)

  • Do not append "Now" (e.g., don't use Generate Network Now), unless necessary to distinguish it from a similar command. If a command isn't "now" due to needing more input from the user, append an ellipsis.

  • When using verbs, word in active voice as a command from the user to the computer (e.g., Generate Network). Do not use passive voice (e.g., don’t use Network Generating). Do not word as a question to the user (e.g., don’t use Generate Your Network?).

  • Use an adjective if the menu item changes the attribute of something, where the adjective is the attribute value the thing will assume (e.g., Bold, Italic). Do not include “empty” verbs that merely mean “change” (e.g., don’t use Make Bold and Set to Italic).

  • Use a noun if the menu item navigates the user to a window of attributes or objects for review or modification, where the noun is the destination (e.g., Options, Inventory). Likewise use a noun for changes the view or perspective in the current window (e.g., Print Layout). Do not include empty verbs that merely mean “get this” (e.g., don’t use Open Options, Manage Inventory, Show in Print Layout).

  • Nouns may also be used as the direct object in the grammatical sense of the pulldown or cascade menu name (e.g,. use Insert > Page Numbers, Format > Borders; not Insert > Add Page Numbers, Format > Set Borders).

BTW, these guidelines apply to names for all commands (e.g., for context menu items, side bar menus, command buttons, links), not just pulldown menu items.


  • 1
    Very nice, thanks. I followed Paul's links, and I found the Apple guidance on ellipses to be the least ambiguous. This might explain why I find Microsoft apps to be inconsistent (e.g., "Internet Options", "Options...") In summary: - An ellipsis is required if (1) the associated action requires specific input from the user ("Save As..."), (2) is performed by the user in a separate window ("Preferences..."), or (3) always requires confirmation ("Shut Down..."). - Do not use an ellipsis if clicking the item completes the action, even if it opens a separate window ("Paste", "Properties").
    – barry
    Apr 22, 2010 at 15:14
  • 1
    Thanks. BTW, in my interpretation, “Preferences” falls into the third category like “Properties” and should not have an ellipsis. Anytime the opening window merely displays attributes or objects for viewing and editing, then the action is completed by the window opening. The “Preferences” menu means “Get Preferences,” like many other menu items that begin with a noun. An example of the second category is “Find...”. Maybe there's a gray zone. Apr 22, 2010 at 17:23
  • What about singular vs. plural use, e.g., should a menu be named "Window" or "Windows"?
    – Mike L.
    Sep 28, 2011 at 18:03
  • 1
    Windows 7 UX guidelines sensibly recommends singular if the commands predominantly involves a single object (page 240). A Gerbil menu item should show me one gerbil, while a Gerbils menu item should usually show multiple gerbils. A Gerbil menu should contain predominantly menu items that generally act on a single gerbil (feed, send, interview), while Gerbils should either list gerbils as menu items, or have predominantly commands that generally act on multiple gerbils (gather, harmonize, cascade). Sep 29, 2011 at 14:49
  • This is my first time visiting this site; reading your answer ensures I will visit more frequently! Dec 30, 2013 at 12:31

I've found the published guidelines for various desktop platforms a good source of (broad) advice in these matters. Your mileage might vary of course!

Here is some related info from the Windows User Experience Guidelines.


Using ellipses

And also related info from the Apple Human Interface Guidelines.

Naming menu items

  • Links are broken
    – SMBiggs
    Feb 13 at 21:10

I think it's a application-by-application decision. It's good to have rules though.

The last menu rules I made were:

  1. Creating an object was always: New [thing]
  2. Always start with a verb in all other cases, delete [thing], upload [thing] etc
  3. Always use an icon
  4. Use separators to group things together.
  5. Look for examples of the same kind of thing and try to be consistent
  6. No ellipses in any cases
  7. Indentation was used for a specific case of "Draft/Edit/Approve" menu objects
  8. Don't use sub-menus in any cases

This isn't a general pattern. It worked in the case I had. Example:

Menu Example

  • 1
    Though most of these rules seem 100% sensible to me, I'd like to disagree on the ‘application-by-application decision’. IMHO trying to stay coherent to the general context (i.e. the OS – hence not fully applicable on the web) has some importance. À propos: Why no ellipses? IMHO they're a good (and widely used) indicator that a menu action requires more than one step and is not carried out immediately. BTW, the visual language/semantics of the icons in the screenshot unfortunately doesn't fit at all the good, clear structure of your wording. (I guess you didn't have much choice there, though.)
    – Sascha Brossmann
    Apr 23, 2010 at 23:06
  • The rules above were for one application I designed. I would likely change something in a different app with a different audience.
    – Glen Lipka
    Apr 25, 2010 at 4:54
  • Why to use an icon? It clutters the menu and usually is so small that one can't see what it means. And the killer argument against icons: Apple does not use icons in the menus. ;)
    – Mike L.
    Sep 28, 2011 at 18:05
  • There are pros and cons. However, I find they liven up the look and make people happy. Plus they often are little reminders where things are. I use them to create a particular feel. If all apps looked the same, then none would stand out. Apple thinks about that sort of thing in their design all the time. "Think Different" remember?
    – Glen Lipka
    Sep 29, 2011 at 3:46

Follow the UX Guidelines of the platform you are developing for. Monster List of UI guidelines