Content Design

Interface copy is a control surface, not prose. Every string either helps the user act or gets in the way. These rules produce copy that reads like a product built by people who use it.

Content is designed with the structure, not painted on after

Write the real labels, errors, and empty states while the flow is being wireframed, because the words change the design: an error that takes three sentences kills the toast the flow assumed, a label that needs qualifying reveals a confused object model, an empty state with no possible action exposes a dead-end screen. When the copy is hard to write, the flow is usually wrong. That's a finding, not a writing problem.

One concept, one word, everywhere

Pick one term per concept and never vary it: if the nav says "Projects", the empty state doesn't say "workspaces" and the API errors don't say "repos". Synonym variety is a virtue in essays and a bug in interfaces. Build the vocabulary from the product's existing domain language before writing anything new.

An action keeps its label through its whole lifecycle. The button says "Invite member", the progress state says "Inviting…", the confirmation says "Member invited". Never "Invite member" → "Sending…" → "Success!". The user tracks one verb, not three.

Buttons and actions

• Verb first, object second: "Delete project", not "Project deletion" or "Confirm".
• The button label answers "what happens when I click this", exactly. "Save changes" saves changes. "Continue" is acceptable only mid-flow where the destination is visible.
• Never "Yes" / "No" / "OK" on destructive confirmations. Repeat the action: "Delete 12 files" / "Keep files". A user skimming the dialog reads the buttons only.
• Sentence case everywhere: "Add payment method", not "Add Payment Method". Title Case Is Marketing.

Errors: the problem, then the way out

Every error message carries two parts: what went wrong, in the domain's words, and what the user does next. An error without a recovery action is a dead end you designed.

• Bad: "Something went wrong." (nothing to act on)
• Bad: "Error 422: Unprocessable entity." (the machine's problem, not the user's)
• Good: "This subdomain is already taken. Try another, or claim it from your other workspace."

Errors are inline and attached to the failing element, not floated as a toast that disappears while the user is still reading. Never blame the user ("You entered an invalid email"), never apologize theatrically ("Oops! Our bad!"). State the fact, offer the path.

Empty states are onboarding

"No data" is a shrug. An empty state answers three questions: what belongs here, why it's empty, and what to do first. Use the domain's language:

• Bad: "No items found."
• Good: "No deployments yet. Connect a repository to run your first deploy."

An empty state with no possible action (empty search results) still explains: "No invoices match 'acme'. Try the company's billing name."

The filler test

Delete every adjective and adverb from the sentence. If no information remains, the sentence was filler. "Supercharge your workflow with seamless, next-gen automation" fails the test. "Deploys finish in under 90 seconds" passes. Generated copy fails this test at maximum frequency; run it on every marketing-adjacent string.

Banned words in UI copy: seamless, supercharge, unleash, unlock, elevate, next-gen, revolutionize, effortless, empower, magic. If the product does the thing, name the thing. This is the single banned list; the review skills point here.

Numbers and names read as real or fake

• Round numbers read as invented: "99.99%", "1000 users", "50% faster". Organic data has texture: "47.2%", "1,847 users". No real number? Say "thousands", don't invent a tidy decimal.
• Placeholder people signal template: "John Doe", "Sarah Chan", "Acme Corp". Demo data uses names matching the product's actual audience, industry, and geography, and keeps them consistent across screens.

Density of information, not of words

Microcopy is as short as it can be while still carrying its information, and no shorter. "Changes saved" beats "Your changes have been successfully saved!" but "Saved" beats both only when the context shows what was saved. Cutting the noun to save four characters costs the meaning.