UX Writing Rules: Microcopy That Helps People Act

Interfaces are made of words as much as pixels. Button labels, form hints, error messages, empty states, notifications, confirmations — this small text, usually called microcopy, guides people through every interaction. When it's unclear, people hesitate, make mistakes, or give up. When it's good, they barely notice it; they just know what to do.

UX writing is the practice of designing these words. Here are the rules I find most useful.

1. Be clear before being clever#

Clarity always comes first. A playful line that makes someone pause to decode it has failed at its job. Wit can work in low-stakes moments — a success message, an empty state — but never at the expense of understanding, and never when someone is frustrated, worried, or dealing with money, health, or security.

2. Use the words your users use#

Interfaces often leak internal language: product code names, database terms, team jargon. Users don't know what a "workspace entity" or "sync job" is.

• Learn the words customers use in support tickets, interviews, and search queries.
• Use those words consistently across the product.
• If a technical term is unavoidable, explain it briefly the first time it appears.

3. Front-load the important words#

People scan rather than read. Put the most meaningful words at the start of headings, labels, and messages.

• Before: "In order to continue, you will need to verify your email address."
• After: "Verify your email to continue."

Shorter, and the key action appears first.

4. Write buttons as specific actions#

Button labels should describe what happens when they're pressed:

• Use verbs: "Save draft," "Send invoice," "Create project."
• Be specific: "Delete account" rather than "Confirm."
• Match the label to the heading or question: if a dialog asks "Discard changes?", the button should say "Discard," not "OK."

Generic labels like "Submit," "OK," and "Yes" force people to reread the context to understand the consequence.

5. Make labels and hints work together#

For form fields:

• The label says what the field is: "Phone number."
• The hint explains format or purpose: "We'll only call about your delivery."
• The placeholder, if used at all, shows an example — never instructions people need to remember.

Keep labels short and visible at all times. Use hints to answer the question people are likely to have at that moment.

6. Write error messages that help#

A good error message explains what happened and how to fix it, in plain language, without blame.

• Before: "Invalid input."

• After: "Enter a date in the format DD/MM/YYYY."

• Before: "Error 500."

• After: "We couldn't save your changes. Check your connection and try again."

A useful structure: what went wrong, why if it's useful, and what to do next. Avoid technical codes unless they help support teams, and even then keep them secondary.

7. Don't blame the user#

Phrasing matters, especially in errors:

• Blaming: "You entered the wrong password."
• Neutral: "That password doesn't match. Try again or reset it."

People already feel frustrated when something goes wrong. Neutral, helpful language keeps them calm and moving.

8. Use empty states to guide#

Empty states should explain what belongs in the space and how to get started:

• Before: "No projects."
• After: "Projects keep your tasks, files, and team in one place. Create your first project to get started."

Pair the message with a clear primary action.

9. Confirm what happened#

After important actions, tell people what changed and, when useful, what happens next:

• "Payment received. A receipt has been sent to your email."
• "Invitation sent to sam@example.com. They'll get access once they accept."

Clear confirmation reduces anxiety and prevents duplicate actions.

10. Make destructive actions explicit#

For actions that can't be undone, the copy should state the consequence plainly:

• Heading: "Delete this project?"
• Body: "This will permanently delete the project and its 24 tasks. This can't be undone."
• Buttons: "Delete project" and "Cancel."

Specific numbers and names help people realize what they're about to lose.

11. Be consistent#

Use the same word for the same thing everywhere. If it's "Remove" in one place, don't call it "Delete" elsewhere unless the actions are actually different. Consistency builds a vocabulary users can learn.

A simple glossary of preferred terms helps teams stay consistent as the product grows.

12. Write in a natural voice#

Most products benefit from a voice that's clear, direct, and human:

• Use second person: "your account," "you can."
• Use active voice: "We sent a code" rather than "A code has been sent."
• Use contractions where natural: "can't," "you'll."
• Use sentence case for headings and buttons; it's easier to read than title case or all caps.

13. Adjust tone to the moment#

Voice is consistent; tone adapts. A product might be lighthearted when celebrating a milestone and calm and serious when reporting a failed payment or a security issue. Match the emotional state of the person reading.

14. Keep it short, but not cryptic#

Remove unnecessary words, but not at the expense of meaning. "Save" may be enough in a simple editor; "Save and publish" may be essential in a content tool where saving and publishing are different actions. Short means no wasted words — not as few words as possible.

15. Design for translation and accessibility#

If your product is localized, write with translation in mind:

• Avoid idioms and wordplay that don't translate.
• Leave room in layouts; many languages are longer than English.
• Don't build sentences from fragments, because grammar differs across languages.

For accessibility, make link and button text meaningful out of context — "Download the report" rather than "Click here" — and write alt text that describes purpose, not just appearance.

Test your words#

Microcopy can be tested like any other design element. Watch people use a flow and listen for hesitation. Run quick comparisons of two versions of a label. Read the text out loud; awkward phrasing becomes obvious. And check support tickets — many questions point directly to unclear copy.

Words are interface#

Good UX writing makes products feel easier, faster, and more trustworthy, often with very small changes. Clear labels, specific buttons, helpful errors, and consistent terms do more for usability than many visual redesigns.

Treat words as design material from the start, not as placeholder text to fill in at the end.