What is best practice for button labels?

Question

What is the best practice when you're labeling your app buttons?

For example, I have a button that links the user to the product reports page, will the button say "View Product Reports" or just "Product Reports"?

Answer 1

To apply a little Einstein, all labels should be as simple as possible, but no simpler. Unnecessarily long labels take longer to read, which wastes users’ time. My impression (based on a little eye-tracking data) is that the longer the label, the less likely the user will read it, as if users follow optimal foraging theory when hunting for commands. Long, descriptive labels can paradoxically make it harder to identify the right command.

So to your question: “View Project Reports” or “Project Reports”? Everyone together now: It depends.

User Experience with Product

First of all it depends on the frequency of use by each user. A use-once web site generally needs more descriptive labels since users are learning it on the fly. For a regularly used app, the user has to only recognize the command, so the label can be shorter as long as it’s distinct.

Word Value

To assist the users in optimizing their foraging, each word in your label should have high information value. “View” usually has low information value, mostly because the designer really means something more broad than just strictly viewing. Not only will users view the project report by selecting this command, they also interpret and evaluate the report. They may print, send, copy, archive, and rate the report, if those actions are supported in your Project Report window/page. Other low value words are "Get" and "Manage."

At worse, users might subconsciously interpret a word like “View” too literally. Users looking to send a project report will not think of clicking on View Project Reports because they’re thinking send project report. If the label were simply Project Reports, it would better match the users' search image.

On the other hand, if you really mean just View, as distinct from, say, Analyze (which is done elsewhere in the app), then keep "View" in the label.

Surrounding Controls

To further support foraging, the first word in your label should ideally have highest information value, so the user can reliably pursue or reject a command with an initial glance at the beginning. So if the other commands are Edit Project Reports, Delete Project Reports, and Send Project Reports, you’re good with View Project Reports. On the other hand, if the other commands are View Inventory Status, View Shipping Receipts, and View Personnel Evaluations, maybe you should drop the View.

Page/Window/Menu Organization and Labels

Proper layout and labeling of the context can also reduce your total number of words users need to read. For example, if the commands are Edit Project Reports, Delete Project Reports, and Send Project Reports, maybe you want a frame labeled “Project Reports” with controls for View, Edit, Delete, and Send inside. If it’s View Inventory Report, View Shipping Report, and View Personnel Report, then it’s a “View Reports” frame around Project, Inventory, Shipping, Personnel.

Product Development Stage

In usability testing it’s easier to detect the impact of inadequate text (the user gets stuck or lost) than it is to detect the impact of excessive text (slightly longer hunting). Thus, prototypes should have the shortest labels you judge to be sufficient, and words should be added only when testing shows they’re needed.

If you're going to be doing usability testing, maybe try leaving out "View" but be ready to jump at adding it if you see any signs of user confusion.

Control Selection

Finally, the control you use can provide information that makes a longer label unnecessary. Users understand that a link lets them view (in the board sense) some content. If you had a Project Reports link rather than a button, you shouldn’t need “View.” Restrict buttons for specific actions that actually manipulate the content and have active labels like Delete and Send.

For more on labeling commands see my answer to What are good rules for naming menu items? Actually, see everyone’s answers.

Answer 2

Be as explicit and clear as possible. "View product reports" is much more clear than "product reports" because it implies more. Generally, using clear, concise language in your UI is preferable to what we in the UX world sometimes refer to as "programmer thinking", which is what happens when your UI labels sound like they're really model names.

There are several questions and answers about buttons and labels here on UX already that you can learn more from.

Answer 3

The problem with >Product reports< is what exactly is going to happen when i click on the button. Is this button about creating, viewing or some other action ? Given "view" is such a short word and adds clarity it doesnt hurt to add it. This would also help if this button was added to some other part of the system that had other buttons. Doing so would not require any change to the label. Users would know that >view product reports< always takes them to the same paage or whatever and does the same thing. Consistency is extremely important when designing a UI. It becomes confusing when you label the same action has different buttons with different labels.