How to write labels for menus, buttons and other UI short texts

It has been a very productive and interesting journey creating Labcodes’ design system: there are always challenges and something new to learn. One thing we are doing is making sure we have our research and study references documented, alongside with the team's design choices, so we can have consistency throughout the components, and, mainly, a unison connection with our design principles.

One topic that always finds a way to catch my attention is the user interface short texts, and I was responsible, in our design system project, for the conception of the notifications, buttons and dropdown menu components. In common, they require guidelines and rules for writing its labels, in case of menu and buttons, and longer messages, for banners and toasts.

I remember that a long time ago, in the first versions of a mobile application that I don't remember which one, I read somewhere on the internet (sorry for the lack of references) about a change made to the interface: the term “my library” was set to “your library ”. OK! But what's interesting about that?

It was at that moment that the software began to communicate directly with its users. In the example, instead of considering the library as belonging to the system, the system now reports that the library belongs to the user. This change shows how short texts details change the reader's perception of a product. Below I will return to this subject.

Writing labels

Labels are commands applied to interface elements such as menus, tags, buttons, text inputs and other interface elements. They directly address users by communicating something or requesting an action. These commands are associated with interactive flows, normally change the system's state, and must be brief, informative and extremely clear. (adapted from n/n group)

Each company has its own brand guide, which should present the tone and voices that the organization’s written communication should have. You can use it as a basis for writing according to how your company does it. Applying these rules, as well as other good writing practices, are a great path for good results. Here at Labcodes we have our own writing guide, which helps us a lot.

Following this reasoning, our design system's buttons have labels that:

• Must communicate exactly what will happen when the user interacts with this component.
• Only the first letter of the label's sentence is capitalized, as well as any other specific noun that requires capitalization.
• They are as short as possible, preferably with a maximum of 3 words.

As difficult as it is to reduce actions labels to just 3 words, we chose to keep this rule as a challenge in order to train our synthesis skills and communicate what really matters.

For action menus we use some specific rules, but they are also applicable to buttons and other label categories:

• Use verbs and imperative phrases to describes the action triggered by the interaction. Never use verbs alone, always alongside a noun. For example: “Move item”, “Edit description”, “Get help".
• Use nouns for actions that navigates to other pages (navigation actions/links). For example: “Keyboard shortcuts”, “Profile editor", “System settings”.
• Don't use articles. They can complexify something that is simpler, increasing the length of a line, in addition to generating other unwanted effects. For example: write “Add bookmark” instead of “Add a bookmark”.

Let's take a step back to when I mentioned how short texts can change the perception of a product. Be aware when labeling system or user's owned items. A good example is to write “Your settings” instead of “My settings” since we are talking about user's preferences, that, even being stored by the system, they are still personal choices. This very naming choice shows attention to detail by making explicit product core values and showing who is in charge.

The dialogue between the system and its users must be direct, clear and friendly. When writing texts for interfaces, imagine the system as an experienced technical person talking to a non-technical person who needs to know what to do next, explaining a question in an understandable way, without making the experience dense or scary.

Something important to consider when writing button labels is the use of terms such as "Ok", "Yes", "No", "Finish", which does not have an explicit meaning for its triggered actions. It may be nice to spell out the actions that will be performed as the use of generic terms can cause difficulties in understanding or lead the user to take an action that they will regret.

Most users typically press buttons or select actions without paying much attention to what they are doing. To avoid these inconveniences, in potentially destructive actions or that could cause an error, always provide a way to undo the action and use clear labels that help the user to recognize the options of "Undo", "Cancel", "Interrupt". In some cases, it may be useful to add a second confirmation layer to avoid data loss.

In common cases, there is simply not enough space in an application to accommodate commands with long labels, so, just repeating here the reminder to keep everything very simple. Consider it as a mantra and always ask yourself if it can be simplified further without losing clarity. Give preference to labels with only one line of text that contain up to 4 words.

The design model for user interface texts

Microsoft has very interesting article on a design model for interface texts:

“As you think about UI text and its placement on your UI surfaces, consider these facts:

• During focused, immersive reading, people read in a left-to-right, top-to-bottom order (in Western cultures).
• When using software, users aren't immersed in the UI itself but in their work. Consequently, users don't read UI text, they scan it.
• When scanning a window, users may appear to be reading text when in reality they are filtering it. They often don't truly comprehend the UI text unless they perceive the need to.
• Within a window, different UI elements receive different levels of attention. Users tend to read control labels first, especially those that appear relevant to completing the task at hand. By contrast, users tend to read static text only when they think they need to.”

“For a general design model, don't assume that users carefully read the text in a left-to-right, top-to-bottom order. Rather, assume that users start by quickly scanning the whole window, then read UI text in roughly the following order:

• Interactive controls in the center
• The commit buttons
• Interactive controls found elsewhere
• Main instruction
• Supplemental explanations
• Window title
• Other static text in main body
• Footnotes”

You should also assume that, once users decide what to do, they immediately stop reading any text and take action.

Moving forward

Behavior, for me, is always something very fascinating that holds my attention. I always try, like our whole team, to produce content that is easy to understand.

Making available information clear is crucial to the decision-making process and guidance on interfaces, and in many cases the displayed information is scarce, garbled or the environment presents misplaced, wrong or contradictory messages, leading the user to fall back to more instinctive techniques such as trial and error, or luck.

Have you ever wondered that the orientation process within an interface depends, in addition to its structure, on the way that texts and micro texts are written?

In the meantime, do you have any questions, suggestions or want to start a conversation? The comments section is open, and we want to know what you think and your experiences on writing for interfaces! See you soon :)

**References: **

Messages - Atlassian Design System
Select - Atlassian Design System
Dropdown menu - Atlassian Design System
Messaging guidelines - Lightning DS
Alerts - Lightning DS
Action labels - Carbon DS
UI Copy - n/n group
Windows 7 interface text writing guide - Microsoft