Writing microcopy

Microcopy is those little bits of text that litter your typical user interface—log in links, form labels, error messages, things like that. These pieces of text are often hardcoded, so it is up to you, dear developer, to make sure it’s up to par. Quality microcopy is pivotal in creating an easy to use and accessible user experience.

This page is inspired by FutureLearn’s page on microcopy.

Capitalisation

Interface labels should be written in sentence case, with the first word capitalised and other words lowercase, unless they are proper nouns or proper adjectives.

This is the way most things are written, and users can read sentence case much faster and with more ease than all caps or title case.

For example:

Labelling

Labels should be clear and easy to understand. Try and be as specific as possible about what things do from a user’s perspective—these will typically involve verbs and actions—and not from a technical perspective. Aim for short, concise labels, however do not sacrifice clarity for brevity. A longer label that adequately describes a function is better than a shorter label that doesn’t.

For example:

Abbreviations

Acronyms and abbreviations are helpful for brevity, but can be confusing if users don’t know what they mean. It’s therefore important that abbreviations are used consistently and in a context where their meaning can be easily determined. If the same acronym appears multiple times in a page, and space allows, define the meaning of the acronym or abbreviation in first usage.

For example:

Dates and times

Dates should be written in full. Times should use the 12 hour clock. Times relative to the current time should clarify this with the word ‘ago’. No time measures should use leading zeroes.

For example:

This vs. that

Think of the user interface as a medium by which we have a dialogue with the user. When talking to or requesting information from the user, use ‘you’. When the user is talking to us, use ‘I’, ‘me’ and ‘my’.

For example:

Error messaging

Don’t use redundant words

Avoid using words that don’t add value to the message. Avoid overusing ‘please’—be direct and to the point.

For example:

Use contractions

Say thanks, not ‘thank you’. Say we’ve, not ‘we have’. Using fully expanded phrases should overly formal and robotic (it’s literally how Data talks in Star Trek: The Next Generation!)

For example:

Avoid using the passive voice

Passive voice sounds impersonal and robotic.

For example:

Talk like a human…

Write how a human would talk. It’s not that hard.

For example:

…Just don’t be too informal

Being too jokey or light-hearted can seem patronising to a user, particularly if something has just gone wrong.

For example:

When something goes wrong, take responsibility

Users don’t like being blamed for things. Even if they’re at fault, take responsibility and perhaps change things to make input errors easier to prevent.

For example:

When something goes right, give credit to the user

Conversely, giving user’s credit for things working out makes them happy. (Even if they didn’t do much!)

For example:

Use sentences

Write errors and feedback messages as though they were standard copy, using sentence case and full, correct punctuation.

For example:

Tell them what to do

If an error is displayed, tell the user what they can do to rectify the error in addition to the cause of the error.

For example: