UX Microcopy Rules

Microcopy is read in the middle of a task, under time pressure, by someone who wants to be done — not read for its own sake. Every word that doesn't help the user complete the immediate step is friction, and every ambiguous word costs a support ticket or an abandoned flow somewhere downstream.

Buttons

• Start button labels with a verb describing the exact action taken, not a noun or a vague label — "Save changes," "Delete account," "Send invite," never "Submit," "OK," or "Continue" when a more specific verb is available.
• Make destructive and reversible actions visually and verbally distinct — "Delete" should never share styling or vagueness with "Cancel"; a user should never have to guess which button undoes something.
• Keep button labels short (2-4 words) but never at the cost of specificity — "Confirm" is shorter than "Confirm cancellation" but tells the user less about what they're about to do.
• Match the button label to the exact outcome, not a step in a process — "Create project" not "Next" on the final step of a multi-step form; "Next" is fine mid-flow but misleading on the step that actually commits.

Error messages

• State three things in every error message where possible: what happened, why (if useful to the user, not internal detail), and what to do next. "Something went wrong" states none of these and forces the user to guess or contact support.
• Write the "what to do next" as the most important part of the message, not an afterthought — "Your card was declined. Check the number and try again, or use a different card" gives the user a path forward; "Payment failed" does not.
• Avoid technical error codes and internal terminology in user-facing messages ("Error 500," "null reference," "constraint violation") — if a code must appear for support purposes, put it in small text below the human-readable message, not as the message itself.
• Never blame the user in error copy — "Invalid input" and "You entered this wrong" read as accusatory. "That email doesn't look right — check for typos" states the same fact without blame.
• Be specific about which field or step failed in multi-field forms — a generic "There were errors in your submission" at the top of a long form forces the user to hunt for what's actually wrong.

No jargon

• Avoid internal team or system names in user-facing copy — a user should never see "the ingestion pipeline failed," only what that means for them: "We couldn't process your file."
• Avoid technical precision that doesn't help the user act — "Rate limit exceeded (429)" means less to most users than "You're doing that too fast — try again in a minute."
• Test unfamiliar terms against the actual target audience, not the team that built the feature — what reads as plain language to engineers is often jargon to end users.

Placeholder vs. label

• Never use a placeholder as the only label for a form field — placeholder text disappears the moment the user starts typing, and if it was carrying the field's identity, the user loses that context mid-entry.
• Use a persistent label for what the field is ("Email address") and reserve placeholder text for an example of the expected format ("you@example.com") — the two serve different purposes and shouldn't substitute for each other.
• Keep placeholder text short and clearly example-like (often via an example value or a light gray tone) so it's never mistaken for a pre-filled answer.

Empty states

• Use empty states to tell the user what will appear here and how to make that happen, not just "No items found" — an empty state is often a user's first encounter with a feature, and it's a missed onboarding opportunity if left blank or generic.
• Include a clear next action in the empty state (a button or link to create the first item) rather than only description — describing what's possible without a path to do it adds friction right when the user is most likely to bounce.
• Distinguish a genuinely empty state ("You haven't created any projects yet") from a filtered-to-empty state ("No results match your filters") — the second needs a way to clear filters, not a call to create something new.

Confirmation copy

• Confirm destructive or irreversible actions with a message stating the specific consequence, not a generic "Are you sure?" — "This will permanently delete 12 files. This can't be undone." tells the user exactly what's at stake.
• Match the friction of the confirmation to the severity of the action — a low-stakes toggle needs no confirmation dialog at all; a permanent account deletion may warrant typing a confirmation phrase, not just a click.
• After a successful action, confirm what happened in plain terms ("Changes saved," "Invite sent to jane@example.com") rather than a generic "Success" — specific confirmation reassures the user the right thing happened, not just that something happened.