Microcopy

For a long time the small text on a screen belonged to nobody. Designers drew grey bars where words would eventually sit, and whoever built the screen filled the gaps with "OK" and "Cancel". Specs listed which screens were needed without saying a single thing about what any of them would say.

The bill always came due in the same places. Deleting a document raised a dialog that asked whether you were sure you wanted to continue and nothing else. What exactly disappears, whether it can be undone, whether it vanishes from the screens of people you were working with — none of that was anywhere. So users either closed the dialog and wrote to support, or clicked and regretted it.

The name arrived once teams noticed that support staff were filling in for the missing words. Sorting the tickets showed that roughly half were not "this product doesn't work" but "I can't tell what state this screen is in," and those tickets tended to disappear when one line on the screen changed. Microcopy pulls those lines out, gives them a name, and moves the decision about them to before the screen gets drawn.

The text gets treated as a component of the interface rather than filler poured into it. Decide what each spot has to communicate, write the words for that spot, then size the spot to fit them.

Every piece answers three questions.

1. What state am I in — whether the change saved, is still processing, or failed outright.
2. What can I do next — retry the same thing, take a different route, or simply wait because nothing is required.
3. What happens if I do it — whether the action can be reversed, and whether anyone else sees the result.

Many teams fix the order of work because of this. Before drawing a screen, list the ways things can go wrong on it, write one line for each of those cases, then lay out the screen around those lines. Do it the other way around and the words get crammed into a width that already exists, and the first things squeezed out are the condition and the next action, which are the two parts a stuck person actually needs. "Payment failed" fits in a narrow button-width strip; "Your card limit was exceeded. Try a different card" does not.

Putting real sentences into a mockup follows from the same logic. Leave placeholder text in and nobody ever checks whether the screen actually reads, because placeholder text is always short enough to fit and real text is always longer.

Choosing a line comes down to three tests: what the person is in the middle of doing, what they can do after reading it, and whether the rest of the product calls the same thing by the same name. The third one can't be settled alone, which makes it a question of terminology consistency. Call something a workspace on one screen and a team on the next, and every individual sentence can be fine while the user concludes they are two different things.

The spots that cause trouble often enough have picked up names of their own. Four come up constantly.

1. Button label — tells you what happens when you press it. "OK" doesn't say what is being confirmed. In a dialog asking about deletion, the safer label is "Delete", with the outcome stated as a verb. Then even someone who skipped the explanation above the button gets the result they expected.
2. Error message — has to carry both what went wrong and what to do about it. With the first half and not the second, people go to support. Even when the cause can't be disclosed, the message can still say whether to retry or go a different way.
3. Empty state copy — what's left on screen when a list has nothing in it. "No documents" states a fact and stops. This is usually the first screen after signup, so describing how to make the first document turns the spot into onboarding.
4. Placeholder — the faint example inside an input. It disappears as soon as typing starts, so format rules put there are gone exactly when they're needed. Keep the explanation outside the field and leave only an example inside.

Confirmation dialogs count as the same family. They ask about actions that can't be undone, so the sentence has to name what disappears. A dialog saying three documents will be permanently deleted and a dialog asking whether you're sure produce very different levels of confidence in the hand doing the clicking.

"Change this button from 'OK' to 'Delete'. I can't tell what I'm pressing."

A request to put the outcome of the action on the button itself.

"This error only says what broke, not what I'm supposed to do about it."

The next action is missing and that line needs filling in.

"Put the real microcopy in the mockup. The lengths are different."

A screen drawn around placeholder text breaks the moment real sentences go in.

At Pagedeck the delete confirmation dialog was what forced the issue. Sofia was getting more than ten tickets a month saying "I deleted something and it vanished for my teammates too," and that was when anyone noticed the dialog said only "Delete this document?" Noa rewrote it as "3 documents will be deleted for the whole workspace. You can restore them from Trash within 30 days" and relabelled the button "Delete". The following month the same complaint came in twice.

Microcopy gets read as a writing-talent problem more often than anything else. The text is short and the output is prose, so handing it to whoever writes well seems reasonable. But what usually blocks the work is information, not phrasing. Writing the delete dialog means knowing how far the deletion reaches and how many days the undo window lasts, and those answers sit with product and engineering. Polish the sentence alone and you get the same ambiguous dialog in nicer words.

Believing shorter is always better is the other one. The screen looks cleaner and translation costs less, which makes the belief easy to hold. But cutting until the meaning blurs just stops people where they stand and routes them somewhere slower. Hesitating over a two-word "OK" button and then asking support takes far longer than reading "Delete 3 documents" and pressing it. The test isn't length — it's whether the line leaves someone certain about their next move.