Product microcopy: who writes it and when it ships

Product microcopy is the text that makes an interface work: field label, error message, empty state, confirmation of a destructive action, waiting text. It is part of interaction design, not marketing copy. Who writes it matters less than when it is written and how it is reviewed.

Three kinds of text, three different owners

Microcopy is the shortest text in the product, and the only one that changes a state.

Editorial content is the long text: article, help page, release note. It lives in a CMS, is read in sequence, and can change without a deploy.

Marketing copy belongs to the campaign: ad, landing page, email. It lives in a calendar and dies with the campaign.

The trouble starts when the three get mixed. A landing page headline inside an empty state turns a next step into a pitch.

Carbon states that its content guidelines are for everyone who writes or reviews copy in IBM product interfaces (Carbon, Content). That makes sense. Interface text isn’t a job for a separate department.

Why microcopy is part of the interaction design

The text isn’t a caption of the component. It is the component in a state.

Material Design says every text field should have a label, always visible and never truncated (Material 3, Text fields). WCAG requires labels or instructions that identify the controls of a form (W3C, 3.3.2 Labels or Instructions).

Nielsen Norman Group describes the division of labor in one line: writers use words instead of pixels to communicate with users (NN/g, UX Writing Study Guide).

GOV.UK adds the test. If you find yourself explaining how the interface works, the interface is the problem (GOV.UK, Writing for user interfaces).

When the text enters the process

The text comes before the layout, not after.

Text that arrives after the screen is designed becomes a caption for decisions already made. A state nobody can name is usually a state nobody designed.

Carbon asks the questions in that order: what the page looks like without content, and which steps the user can take to fill it (Carbon, Empty states).

GOV.UK asks teams to know why they ask every question and to drop what they don’t need (GOV.UK, Question pages).

Writing the text first is a scope test. The sentence that can’t be written is usually a state that doesn’t exist. The same order appears in the work on loading and empty states and on single-field forms.

Who writes when there is no UX writer

The person who owns the state writes the text. Not the designer by default, and not the best writer on the team.

In most teams the product designer writes the label and the empty state. Support writes the error text it already explains in tickets, and engineering writes the message the system throws.

Ownership per surface beats ownership per job title.

A team without a writer doesn’t need a new role. It needs the text to enter the process with the same owner as the state it describes.

Error message

GOV.UK requires the message to explain what went wrong and how to fix it (GOV.UK, Error message).

The same system requires both an error summary at the top of the page and a message next to the field in error (GOV.UK, Error summary).

WCAG asks for the error to be described in text, with the item in error identified (W3C, 3.3.1 Error Identification).

NN/g adds placement and timing: show the message close to the source, and don’t show it before the user finishes (NN/g, Error-Message Guidelines).

The hard part is where specificity stops helping. A message that lists every possible cause is longer than the action it blocks.

Material advises replacing supporting text with error text, so the layout doesn’t jump when the message appears (Material 3, Text fields).

Empty state

Carbon warns that empty states are often treated as an afterthought, and asks for a title written as a positive statement (Carbon, Empty states).

The same page also sets a limit. More content isn’t a better solution, because there is a cognitive cost for every line on the page.

NN/g treats the empty state of complex applications as its own problem, with three guidelines (NN/g, Designing Empty States in Complex Applications).

The empty state is the one place where a longer text usually pays. It has room, the user has nothing to read, and the next action is the message. How much a person actually reads on screen has its own measurements, gathered in typography and reading on screen.

Field label

Material keeps the label visible, aligned with the input text, short and never truncated (Material 3, Text fields).

GOV.UK asks for one question per page and marks optional fields as optional (GOV.UK, Question pages).

The label is also the accessible name of the field, which is why WCAG requires it (W3C, 3.3.2 Labels or Instructions).

The limit: a label that needs a paragraph of explanation is a field that shouldn’t exist. GOV.UK states the rule as start with less (GOV.UK, Writing for user interfaces).

Confirmation of a destructive action

Material states that dialogs are purposefully interruptive, so they should be used sparingly (Material 3, Dialogs).

NN/g warns against routine confirmations, because a dialog everyone dismisses protects nobody, and asks for specificity through the name and the number of records (NN/g, Confirmation Dialogs).

WCAG asks for legal, financial and data submissions to be reversible, checked or confirmed (W3C, 3.3.4 Error Prevention).

The button label is the cheapest control. “Delete 3 records” prevents more than a dialog that repeats the word “delete”.

Waiting text

NN/g measured three limits: 0.1 second for direct manipulation, 1 second for an uninterrupted flow, and 10 seconds for attention (NN/g, Response Time Limits).

Under one second, feedback text only adds noise.

Carbon places skeleton states on containers, a progress indicator when the wait passes a moment, and a notification when the process takes minutes (Carbon, Loading).

The rule: the text exists to answer a question the interface can’t answer visually. When the screen already shows movement, the word “loading” is decoration.

The review criterion

Review against criteria, not personal taste. Four checks catch most of the bad text in an interface.

Does the text name the state? “No results” names it, and “Something went wrong” hides it.

Does it say the next action? A message without a next step is a dead end with good manners.

Is it the shortest version that still works? GOV.UK states the rule as start with less (GOV.UK, Writing for user interfaces).

Does it survive translation and a screen reader? Text that only works in one language isn’t finished, which is the same problem described in building a design system after launch.

The tone question comes after these four, not before.

When the generic message is the right answer

Four cases where short and generic wins.

The cause is unknown, or the list would be wrong. A message that guesses teaches the user to distrust every other message.

The specific text would confirm information the system shouldn’t confirm. Login, recovery, whether an account exists.

The state is already learned. A user who has seen the same error three times doesn’t read the fourth.

The specific text is longer than the action it protects. “Your session expired, please sign in again with the credentials you used before” loses to “Session expired, sign in”.

GOV.UK states there is no need to say sorry in a validation message, and no place for humour in a service people use under stress (GOV.UK, Writing for user interfaces).

The rule is about cost, not tone.