Install any skill in seconds. Free to start, no credit card required.
Get Started Free →Use when writing the short interface text for a product screen — the label on a button, the message a user sees when something fails, the text on an empty screen with no data yet, or the copy in an onboarding step. Writes each to convention: verb-first sentence-case labels, failure messages that name a concrete next step instead of a bare apology, and empty or first-run screens that always offer an action so the user is never stranded. Do NOT use for marketing headlines, body/paragraph copy, email subject lines, deep CTA verb selection (see cta-microcopy), or rewriting raw stack traces for developers (see error-message-rewriter).
.claude/skills/ui-microcopy-conventions/SKILL.md| Test case | Without → With | Effect | Δ tokens | Δ turns |
|---|---|---|---|---|
| case-05 | ✗→✓ | ▲ Improved | 365% | 0% |
| case-11 | ✗→✓ | ▲ Improved | 426% | 0% |
| case-13 | ✗→✓ | ▲ Improved | 322% | 0% |
| case-07 | ✗→✗ | = Same ✗ | 315% | 0% |
| case-01 | ✗→✗ | = Same ✗ | 327% | 0% |
The handful of words that sit inside a product interface — on a button, in a failure message, on a blank screen, in a setup step. Base models write these on autopilot and reach for three defaults that all read as generic and leave the user stuck:
Save Changes, Create New Project).Oops! Something went wrong.).No projects yet.) with nowhere to go.The convention below replaces each default. One idea unifies all four surfaces: no dead ends — every piece of interface copy points the user at what to do next.
Activate when the user asks for the words that live inside a running interface:
Not for marketing headlines or body paragraphs, email subject lines, choosing the outcome verb and length of a marketing CTA (that is cta-microcopy), or turning a raw exception or stack trace into a developer-facing message across audiences (that is error-message-rewriter).
Four surfaces, four rules. Apply the matching rule; when unsure which surface, apply the one unifying rule — never leave the user with nothing to do next.
Start with the verb that names the action, and capitalize the label like a sentence: only the first word (and any proper noun) takes a capital.
Save changes — not Save Changes, not Changes.Create project — not Create New Project, not New, not OK for a create action.Delete account — not Delete Account, not Yes on a destructive confirm button.In a confirm dialog, the primary button restates the verb (Delete account) rather than a bare Yes / OK, so the button is readable on its own.
A failure message earns its space by telling the user what to do about it. State, in plain words, what happened and the one concrete next step. Do not open with Oops, and do not ship a message whose entire content is a generic apology like Something went wrong.
Login failed.Choose a file under 10 MB), notUpload error.
Payment failed.Be specific and non-blaming: point at the fix, not at the user.
When a screen has no data yet, do two things: say in one line what will appear here, then give the user the action that fills it. An empty screen is never a dead end — it is the best place to prompt the very next step.
Create project action, not just No projects.the search), not a bare No results.
Every setup step gives the user one clear action to continue, and a way to skip or dismiss so they are never trapped. One decision per step; never a screen the user cannot leave.
Turn on notifications and aNot now.
Before returning any interface copy, confirm:
Oops / Something went wrong alone.For a wider bank of before→after rewrites on each surface, see the catalog under references/ (buttons, errors, empty-states, onboarding). The rules above are complete on their own; the catalog is lookup depth for edge cases, not new conventions.
Other measured skills in the registry, with their headline benchmark lift.