What Microcopy Is

Microcopy is the writing that lives inside interfaces: the label above a form field, the placeholder text inside it, the hint below it, the button label at the bottom of the form, the confirmation message after it is submitted. It is the tooltip that appears when you hover over an icon. It is the empty state when a list has no items. It is the validation message when a field is filled incorrectly.

None of these pieces of writing is long. Most are under twenty words. Many are under five. But together they constitute the language layer of an interface — and they are the difference between a form that users complete and one they abandon.

Why small words matter disproportionately

Microcopy operates at the point of action. It appears when the user is in the middle of doing something: filling in a field, clicking a button, encountering an error, waiting for something to load. At these moments, the user’s attention is active and their tolerance for confusion is low.

A vague field label — “Information” instead of “Email address” — creates a moment of hesitation. A placeholder that disappears when the user starts typing leaves them without a reference when they have forgotten what to enter. An unhelpful error message — “Invalid input” — forces the user to guess what is wrong. Each of these microcopy failures is small. Accumulated across a form or workflow, they create a frustrating experience that has nothing to do with the product’s quality.

The anatomy of interface microcopy

A form is the densest microcopy environment in most interfaces. A single form field typically contains:

A label — what this field is for. Should be visible at all times (not a placeholder that disappears). Should use the user’s language, not the system’s (“Phone number,” not “Contact digit string”).

A placeholder — a hint inside the field about expected format or example value. Not a label substitute. Should be supplementary, not essential (“e.g. +44 7700 900000”).

Helper text — a note below the field giving more context, constraints, or instructions. Essential for complex fields (“Must include a letter and a number”).

Validation text — what appears when the field is validated, either success or failure. Should say what went wrong and how to fix it, not just that something went wrong.

The button label — the text of the submission action. Should describe the consequence of pressing it, not just the action (“Create account” is better than “Submit”).

Reassurance copy — text near the form that addresses common hesitations (“We’ll never share your email” near an email field; “No credit card required” near a payment CTA).

Writing microcopy vs designing for it

The most common microcopy failure is not bad writing — it is omission. Designs that use “Label” as a placeholder for field labels, “Helper text” as a placeholder for helper text, and “Button” as a placeholder for button labels are designs that have not yet decided what the microcopy will say. When these placeholders survive into implementation, the default database field name or developer’s first guess becomes the live interface language.

Microcopy should be specified in the design phase, not added as a final pass. It is part of the design, not decoration applied over it.

Writing buttons and labels — the next article — covers the single most frequently written piece of microcopy and the most commonly written poorly.