Clear microcopy tells people what something is, what action is available, what information is needed, and what consequence follows. Use familiar words, specific verbs, consistent terms, and enough context to support a decision. Test copy inside the interface and workflow because a phrase that reads well alone may fail beside neighboring controls or after an error.
Who this is for: Designers and content practitioners writing compact product language for controls, workflows, states, and recovery.
- Write from the person's immediate question and consequence rather than the system's internal vocabulary.
- Use specific action labels and consistent object names so people can predict what happens next.
- Review microcopy in every state, with realistic content, localization, accessibility, and support evidence.
Identify the communication job
Before drafting, state what the person needs to know or decide at that moment. A dialog may need to distinguish saving a draft from publishing, not merely ask for confirmation. Inspect the trigger, surrounding content, likely concern, consequence, and next state so the copy solves the actual uncertainty.
Separate product terminology from customer language. Research search terms, support conversations, interviews, and domain conventions. Use one name for the same object across navigation, forms, notifications, and help. If policy requires a technical term, explain it where the decision occurs rather than relying on a distant glossary.
Make actions predictable
Label buttons with the action and object when context is not obvious, such as 'Send invitation' or 'Delete draft.' Generic labels like 'OK' force people to reread surrounding text. Distinguish alternatives by consequence, and avoid using a positive visual treatment for a destructive action merely to emphasize it.
Put essential conditions before the action. If publishing notifies subscribers or deletion cannot be reversed, state that plainly before commitment. Do not hide material consequences in tooltips or links that keyboard, touch, or screen-reader users may not encounter at the necessary moment.
Write states and errors
Loading language should describe what is happening only when that knowledge helps. Success messages should confirm the result and provide the next useful action. Empty states should explain the specific condition. Avoid jokes during failure, payment, privacy, or data-loss moments where tone can obscure recovery and responsibility.
Error copy should identify the problem, preserve valid work, and explain a feasible next step. Name the affected object or field. Do not blame the person or expose internal error codes as the only explanation. When the team does not know the cause, be honest about what is known and offer a safe retry or support path.
Test copy in context
Place realistic names, dates, counts, and long content into the design, marking sample numbers as hypothetical. Review narrow screens, zoom, localization expansion, truncation, and repeated announcements. Read the flow aloud and with a screen reader where relevant to catch duplicated labels and missing context.
Use comprehension testing, usability sessions, support patterns, and behavior evidence according to the decision. Preference between two phrases is weaker than successful understanding in context. Maintain a terminology list and ownership process so later releases do not reintroduce conflicting names across the product.
Rewrite a hypothetical deletion dialog
Hypothetical dialog: 'Are you sure? Cancel / Confirm.' The action permanently removes a shared report.
- Name the object and consequence: the hypothetical 'Q2 Pipeline' report will be permanently deleted for all collaborators.
- Use distinct actions, 'Keep report' and 'Delete report,' rather than cancel and confirm.
- State that deletion cannot be undone before the destructive action and avoid unrelated reassurance.
- Test keyboard order, accessible names, narrow layouts, and the success message that follows deletion.
Microcopy context sheet
Draft and review interface language with the behavior it controls.
- Person, moment, likely question, intended action, consequence, evidence, and communication priority.
- Object names, approved terminology, customer vocabulary, required policy language, and terms to avoid.
- Trigger, label, instruction, primary action, alternative, confirmation, error, recovery, and next state.
- Tone, severity, localization, content expansion, accessible name, announcement behavior, and truncation.
- Review owner, comprehension method, usability evidence, support signal, version, and terminology update.
Common mistakes
- Using confirm and cancel where neither label explains the action or consequence it causes.
- Changing the name of the same object across navigation, forms, notifications, and support content.
- Trying to make an error charming while failing to explain what happened or how to recover.
Try one
Rewrite 'Something went wrong. Try again' for a file that exceeded the service's known size limit.
A strong answer names the file problem and available recovery, such as 'This file is larger than the allowed size. Choose a smaller file, then upload again.' The interface should state the actual maintained limit nearby if one exists and is appropriate. It should preserve other work, associate the message with the upload control, and avoid implying a retry will fix unchanged input.
Sources
- Nielsen Norman Group interface copy guidanceGuidance on making deliberate tone choices while preserving meaning and context.
- Nielsen Norman Group concise writing guideGuidance on concise, scannable, and concrete digital writing.