Content Design

Words are the interface. People read labels, headings, buttons and errors. Nobody reads your layout. Which means the cheapest fix for most usability problems is a rewrite, not a redesign.

Content design is not writing that happens once the screen is drawn. A button needing a tooltip to be understood is a labelling problem disguised as a layout problem, and you will never find it in a mockup filled with lorem ipsum. Write the real words first. They will change the design.

The measure is not elegance. It is whether someone under time pressure, on a phone, half-distracted, knows what to do next.

UX Writing

Write in the user's words, not the system's. Internally the feature is called entitlement sync. The user is trying to add a teammate. Label it accordingly.

Lead with the verb on anything actionable — "Create invoice", not "Invoice creation". Make buttons name their outcome: a dialogue asking "Delete this project?" offers "Delete project" and "Cancel", never "Yes" and "No". And drop the filler — "please", "simply", "just". "Simply click here" tells a struggling reader that the fault is theirs.

Short is not the same as clear. "Manage" is shorter than "Manage billing" and leaves the reader guessing what it manages. Cut the words carrying no information, not the ones carrying the meaning.

Read it aloud. If you would not say it to someone sitting beside you, do not ship it.

Voice & Tone

Voice is who the product is, and it does not change. Tone is how it speaks in a particular moment, and it changes constantly.

Define voice as a set of trade-offs rather than adjectives. "Friendly" is useless, because nobody picks unfriendly. "Plain over clever, direct over cautious, warm but never jokey" actually tells a writer what to cut.

Tone follows the user's state, not the writer's mood. Someone finishing a first setup can take a light touch. Someone who has just lost an hour of work cannot: no exclamation marks, no mascot, no "Oops!". A jokey error message turns a minor failure into a screenshot posted publicly.

The worse the moment for the user, the plainer you speak.

Microcopy

Microcopy is the text nobody plans for: the helper line under a field, the tooltip, the placeholder, the error. It earns its keep by stopping a mistake before the user can make it.

"We'll email a code to this address", sitting under the email field, answers a question that would otherwise arrive as a support ticket. State password rules before the attempt, not after the rejection.

Never use placeholder text as a label. It vanishes the moment someone types, taking the instruction with it, and as an accessible name it is only a fallback — what gets announced depends on the browser and reader pairing. Give the field a visible label.

Find where people hesitate: the question every test session throws up, the field people abandon halfway, the ticket that arrives twice. Microcopy is what you put there.

Sign in to track your progress

Discussion

Sign in to ask a question

No questions on this lesson yet. Highlight a passage to ask about it, or use Ask a question.

Up next

Designing Responsibly

Build the Interface