General writing style

Focus on the user

Focus on what the user wants to do (with a screen, with a button, with a set of data). Remember that task and write your texts to assist the user in completing it.

Use natural language

• Use natural language that will be understood by the target audience.
• Avoid complex technical terms unless they are essential, or you are certain that every reader will understand those terms.
• For example, the label 'Assignee' is an uncommon word. 'Assigned to' is more natural and can be understood more easily by non-native speakers.

Be concise

• Use concise language that is rational and unemotional.
• If you can omit words or phrases without changing the meaning, do so.

• Avoid unnecessary modifiers (adverbs and adjectives). Look for stronger nouns and verbs that can replace excessive modifiers.
• Avoid unnecessary opening phrases (for example, 'It is important to know that…').

Be consistent

Many writing decisions are a matter of style rather than hard rules. Whichever approach you take, it is important to apply it consistently.

This applies to things like:

• Formatting of dates and times
• Referring to elements on the UI (for example, 'on the User screen' or 'in the User dashboard')
• Interacting with the UI (for example, 'Press Button', 'Click Button', or 'Choose Button')

Be clear

• Ensure that text communicates the intended meaning in full.
• To avoid confusion, ensure that names (of features, functions, buttons, and so on) are noticeably different.

Choose your words carefully

• Avoid idioms, slang, or other phrases that may be difficult for non-native speakers to understand.
• Consider whether polite language (such as 'please') is necessary.

Polite language adds length without adding meaning. However, perhaps a friendly tone of voice is appropriate for your brand. Whichever approach you take, apply it consistently. For more information about writing messages, see Alerts, warnings, and messages.

If a piece of copy relates to a task, place the verb (or task) at the beginning or close to the beginning of the text.

Avoid redundancy

For example, 'Create new' is redundant. 'New' is unnecessary, as it's implied by the word 'Create'. You can't create something that exists already.

Use active voice

• Where possible, use the active rather than the passive voice.
• In the active voice, the subject comes first. An easier way to describe it is that the subject does the acting.

• In the passive voice, the subject is acted upon. This makes it difficult to follow who performs an action.

Avoid unnecessary punctuation

For the convenience of readers in quickly scanning text, it is recommended to avoid unnecessary punctuation. In particular, refrain from using periods in isolated sentences within these UI elements:

• Labels
• Hover text
• Bulleted lists
• Dialog body text

However, it is appropriate to use periods in the following cases:

• Multiple sentences
• Any sentence that is immediately followed by a link (note that links themselves should not constitute complete sentences)

Always be positive

We can be unaware that we are falling into a negative tone, especially with error messages like 'Sorry, you can't do this'. This negative tone can give a sense of finality, effectively blaming the poor user for what has occurred.

Avoid destructive feedback

This is unhelpful, there is no feedback, it's mildly depressing, and might remind the user of their own mortality. 🙁

If our user encounters an issue, we want them to know that there is a solution.

Use 'positive, constructive' messages when something goes well

This is good, as it tells you in very positive terms what has happened and what you can now do.

Use 'negative, constructive' messages when something goes wrong

This explains what you cannot do, but at least it tells you that there is a solution in a friendly manner. 🙂

If you want to find out more, read the Feedback Method Theory by David L. Cooperrider and Diana Whitney.

Is it 'my stuff' or 'your stuff'?

The debate over whether to use 'Your' and 'My' rages on in countless forums. It comes down to what suits your brand and how social and collaborative the product is. There is an argument that using a personal pronoun is a way of making the user feel engaged.

'Your' stuff

Using 'Your' (the second person pronoun) in an interface implies the product is talking with you. It makes the product feel like it's a personal assistant. It's helpful without being too demanding.

'Your' is social. An example would be a project management app where a team is creating tasks. 'Your' is useful as it differentiates your tasks from all people's tasks.

Use 'Your' if the platform has created something for you, like a report or digest.

'My' stuff

Using 'My' (first person pronoun) suggests that the product is an extension of the user. 'My' gives the sense of control and ownership, but as an individual. It is solipsistic. An example would be a tax return site. Since the user is not in an open and sharing mood while calculating their finances, 'My' feels appropriate, especially where data is sensitive.

Another example is 'My profile', where you do not want to share any data with others. Here, the first person gives a better sense of security. It makes the user understand clearly that they are viewing their information.

Use 'My' if you have created something in the platform such as a saved search or personalised playlist.

No point of view

You can do this too. There are no rules to say that your product has to speak at all. In my experience, it is not so important to label things 'Your' or 'My'.

Use the proper noun or action, like, 'Suitcase' instead of 'My suitcase' for example. It sidesteps issues of long line lengths and visual clutter. Using the personal pronoun is unnecessary in most cases except for those I mentioned above, namely distinguishing your own data from that of a team.

Microsoft have a good summary of 'Person' guidelines.

To select or choose?

"Choose" and "select" are often used interchangeably, but there are subtle differences in their usage:

Choose
This term is more general and can imply making a decision based on personal preference, inclination, or free will. It doesn't necessarily involve a structured or formal process. For example, you might choose your favorite ice cream flavour.

Select
This term often suggests a deliberate, thoughtful, or careful process of choosing from a range of options. It can imply a more systematic or methodical approach. For example, you might select a candidate for a job from a pool of applicants.

When offering a choice, it's advisable to consistently use the term 'select' instead of 'choose.' For instance, in scenarios like wizards and creation screens where users need to make a decision from a wide array of options, we can use phrases such as 'Select a material topic' or 'Select your geographies.'

Parallel construction

Parallel construction presents similar or related information in a similar format.

For similar types of information (for example, tooltips, lists of items, or buttons), use parallel construction. Using the same pattern of words or grammatical construction helps the reader comprehend text because it is predictable.

When to use contractions

• Contractions (for example 'isn't' versus 'is not') can affect the user's perception of your product or brand.
• Consider the intended tone of your communication: contractions are more friendly and informal, but avoiding contractions can appear more formal, serious, and professional.

Dealing with numbers

• In general, spell out the numbers one to nine, and use numerals for numbers of 10 or more.
• Use numerals for the following:
  • Units of measurement (8 kg, 400 m, and so on)
  • To contrast numbers in a series ('the device is checked after 2, 7, and 14 months')

To describe ranges and approximate number ('we sell around 5 products a day', 'between 4 and 54 records').

The grammar of interactivity

A bit of theory for those of you who are interested. As developers we create the invitation to act, 'Add', 'Download', but it is the user who clicks.

Our button and action labels must make sense in the context of not one 'speaker', but two: the product and the user.

As a test to make sure button labels make sense we can use the interrogative and conditional:

• the interrogative: 'would you like to do something?'. This is us (the product) inviting the user to perform an action.
• the conditional: 'I would like to do something'. This is the user telling us (the product) what they would like to do.