Content Design & UX Writing: Labels to Error Messages

Content Design and UX Writing

Most of an interface is words: button labels, field names, hints, error messages, empty states, notifications, and confirmation dialogs. When those words are vague ("Submit", "Something went wrong", "Are you sure?"), people hesitate, make mistakes, and contact support. When they are specific and helpful, the same interface feels simple. Content design treats words as part of the product's design — decided from user needs and tested like any other interaction — and UX writing is the craft of writing them.

Content is also an engineering concern. Strings live in code and translation files, error messages depend on what the backend reports, plurals and word order vary by language, and screen readers announce link text and labels out of context. Good content work happens alongside design and development, not as a final polish pass.

TL;DR

Start from the user's task: say what people need to know, in the order they need it, in plain language.
Make labels and buttons specific: verbs that name the action ("Delete project"), not "OK" or "Submit".
Error messages say what happened, why, and how to fix it — near the problem, without blaming the user.
Empty states explain what will appear and how to start; confirmations name the consequence for destructive actions.
Keep terminology consistent with a glossary, and adapt tone to the situation within one voice.
Write for localization (no concatenation, message formats for plurals), accessibility (meaningful link text), and test content with users.

Quick Example

Before and after for common interface text:

Localization-ready strings with ICU MessageFormat, so plurals and variables work in every language:

Core Concepts

Principles

Purposeful: every word helps someone complete a task or make a decision.
Clear: plain words, short sentences, active voice, specific nouns and verbs.
Concise: front-load the important part; cut what people do not need.
Consistent: the same thing has the same name everywhere.
Human: polite and direct; no jargon, internal codes, or blame.

Plain language is not "dumbing down": specialists also read faster and make fewer errors with clear text. Many governments publish plain-language guidance for this reason.

Voice and Tone

Voice is the product's consistent personality (for example: clear, calm, helpful). Tone adapts to context: celebratory after a milestone, neutral in settings, calm and precise in errors, serious around money, security, or data loss. Avoid jokes in error messages and anywhere people may be stressed.

Labels, Buttons, and Instructions

See Accessible Forms and Error Recovery.

Error Messages

Good error messages answer three questions: what happened, why (if it helps), and what to do next. They appear near the problem (next to the field, in the failed component), keep the user's input, use plain language instead of codes (include a reference ID for support when useful), and never blame ("You entered an invalid value"). Engineering must provide enough information — distinct error types from APIs — for specific messages. See Loading, Empty, and Error States.

Empty States, Confirmations, and Success

Empty states explain what will appear, why it is empty, and the first action to take; distinguish "nothing yet" from "no results for this filter".
Confirmations for destructive or costly actions name the object and consequence and use a specific button; prefer undo for reversible actions. See Interaction Design and Usability.
Success and status messages confirm what happened specifically and are announced to screen readers through live regions.

Terminology

Maintain a glossary of product terms — is it a "workspace", "team", or "organization"? "Delete", "remove", or "archive"? — with definitions and words to avoid. Inconsistent terms make people think there are different features. Include content patterns and terminology in the design system.

Writing for Localization and Accessibility

See Internationalization and Accessibility.

Testing Content

Comprehension tests: ask people to explain in their own words what a message means or what will happen.
Highlighter tests: participants mark words that help (green) or confuse (red).
Usability tests and support tickets: watch where people hesitate; read what they ask support.
A/B tests for high-traffic text such as signup and pricing pages.

Manage strings in resource files with keys, review content changes in pull requests, and use linters (such as Vale) to enforce terminology and style.

Best Practices

Write With the Design, Not After It

Draft real content early; lorem ipsum hides layout problems and unclear flows.

Make Every Action Name Its Outcome

Buttons and links should say exactly what will happen when they are used.

Design Errors With Engineering

Agree on error types and data the backend provides so messages can be specific and actionable.

Keep a Glossary and Pattern Library

Document terms, voice, and patterns for errors, empty states, and confirmations.

Common Mistakes

Generic Errors

"Are You Sure?" Dialogs

Concatenated Strings

FAQ

What is content design?

An approach that designs the words and information in a product based on user needs and evidence, treating content as part of the interaction design rather than decoration added at the end.

What makes a good error message?

It explains what happened and how to fix it in plain language, appears near the problem, preserves the user's input, and avoids blame and technical codes.

Should buttons say "OK" or "Submit"?

Generally no. Buttons work best when they name the action and its result, such as "Save changes", "Send invite", or "Delete project".

How do I prepare UI text for translation?

Avoid concatenation, use message formats with plural and gender support, leave room for text expansion, avoid idioms, and give translators context.

How can I test whether interface text works?

Run comprehension and highlighter tests, observe usability sessions, review support questions, and A/B test high-traffic text.