vocab.design

pattern · content-design

Microcopy

also called UX writing (nngroup), UX copy (nngroup), UI copy (community), interface copy (community), product copy (community)

An interface's smallest strings: the verb on the button, the line under the field, the sentence when it fails. Short enough to be read every time.

Microcopy is the copy that is part of the interface rather than published through it. The useful boundary is the one the Nielsen Norman Group draws by size and position: strings shorter than about three sentences, attached to a control or a state, and read far more often than anything a content team would call content. The verb on a button, the line under a field, the sentence that appears when a card is declined, the two words in an empty list. Nobody sits down to read any of it, and everybody reads all of it, which is why the cost of getting it wrong is paid on every session rather than once.

It is a class, not a component, and this dictionary is mostly full of its instances. Helper text is microcopy under a field before anything has gone wrong. An error message is microcopy after a value has been judged. An empty state and a no results state are microcopy standing in for content that is not there, placeholder as label is microcopy doing a job it cannot do, and confirmshaming is microcopy used against the reader. The class is worth naming anyway, because the work of writing all of it is one job with one voice, done by one person, and a team with no word for that job tends to leave the strings to whoever built the control.

Two neighbours are close enough to be worth separating. Plain language is a rule about reading level, and it applies to any text at all, a thousand word policy page included: it says how the sentence should be written, not which sentences these are. Microcopy is a class of strings picked out by their size and their position in the interface, and it can be written at any reading level, badly or well. The other edge is fine print, and the difference there is intent: microcopy is written to be read every time and sized for it, while fine print is written to be present. Both are short interface text, and only one of them wants your attention.

The tell that nobody has done the work is the default string. “Submit” is what a button says when it has no idea what it sends; “Invalid input” is what a form says when it knows exactly what is wrong and cannot be bothered to say. Replacing them is cheap and it is not really a writing problem: the verb on the button should name the thing that happens, the line under the field should say the rule before it is broken, and the failure should say what to do next. That only happens if the strings are written where they live. Copy drafted in a spreadsheet and pasted in later is copy written without the button, and a phrase that reads fine in a cell is the phrase that wraps to three lines on a phone.

Which word?

If you wantsay
the words a control needs to be understood, not the prose around itmicrocopy
the terms that qualify a claim, set below the threshold of attentionfine print
the copy is correct but nobody can act on itplain language
guidance under a field, not an errorhelper text

Implementations

The demo above shows the idea. To build it, start with one of these.

carbonWriting style

Sources