A customer reaches the last step of your checkout, hits a red box that says "Error: invalid field", and leaves. The buttons were fine. The layout was fine. What broke them was a sentence, one that named a problem without naming the fix. That sentence was a design decision, and on most teams nobody decided it on purpose. Content design and UX writing are the disciplines that decide it on purpose.

The quick version

  • Content design starts from a user need and meets it in whatever form serves it best; UX writing is the closely related craft of the words inside an interface, buttons, labels, errors, empty states.
  • The discipline was named at the UK's Government Digital Service, where Sarah Richards' team consolidated 400-plus sites into GOV.UK by starting with what users came to do, not what departments wanted to say.
  • People barely read. Nielsen Norman Group estimates users take in around 20% of the words on an average page visit, so every word has to earn its place.
  • The words that pay off most are the smallest: microcopy. A button verb or an error message that names the fix can move a metric more than a redesign.

The idea in depth

Strip the jargon and the definition is humble. The GOV.UK guidance, the founding text of the field, puts it plainly: "Content design starts by taking a user need and meeting it on GOV.UK in the best way possible." The move there is the word need. You don't begin with the message you want to push; you begin with the task someone arrived to complete, renew a passport, cancel a subscription, understand a bill, and you work backwards from that. Sarah Richards, who led the content work at the UK's Government Digital Service and later wrote Content Design (2017), defines it as "a way of thinking" that uses "data and evidence to give the audience what they need, at the time they need it and in a way that they expect." Notice what's absent: brand voice, clever phrasing, persuasion. Those come later, if at all.

So write the user need as a sentence before you write a single label. "As a customer, I need to know whether my refund has been processed, so I can stop worrying about it." Tape that to the top of the screen you're working on. Every word you then add either serves that need or it doesn't, and the ones that don't are the first to cut. It's the same discipline as a good product brief, just dropped to the altitude of a paragraph.

flowchart LR
    A(["User need
the task someone arrived to do"]) --> B(["Content design
what to say, in what form"])
    B --> C(["UX writing
the exact words on screen"])
    C --> D(["The interface
obvious, or not"])
    D -.feedback.-> A
Content design decides what a screen needs to say; UX writing decides the words. The user's success feeds back into the need. Leaders Loop

People don't read, they scan, and act

The reason words carry so much weight is that almost nobody reads them. In a 2008 analysis of more than 45,000 page views, Jakob Nielsen of Nielsen Norman Group concluded that "users have time to read at most 28% of the words during an average visit; 20% is more likely." The shorter the page, the larger the fraction read, only pages of roughly 111 words or fewer get about half their text read on a typical visit. People scan for the word that matches their goal, click it, and move on. They are foraging, not studying.

That changes what good writing is inside a product. Front-load the point. Use the words your users use, not the ones your org chart uses ("payments" not "remittance disbursement"). Cut the warm-up clause. Make the one action verb the most prominent word on the screen.

"Good content design helps people quickly find out what they need to know or do.", GOV.UK content design guidance

The practical upshot: label a button with the verb of its action, never the generic. "Submit" and "OK" tell a scanning user nothing; "Send invitation", "Delete account", "Pay £40" tell them exactly what is about to happen. Torrey Podmajersky, in Strategic Writing for UX (O'Reilly, 2019), frames UI text as patterns with jobs to do, titles, buttons, descriptions, errors, each "purposeful, concise, conversational, and clear." A button's job is to say what the click does. Generic verbs are a job left undone.

The error message is the cheapest fix you're not making

If content design has a signature win, it is the humble error message. A good one does three things: it says what went wrong, in plain language; it says why; and it shows the way out. "Error: invalid field" does the first badly and the other two not at all. "Enter your card's expiry date as MM/YY, we've highlighted the field" does all three. Nothing about the layout changed; the friction simply evaporated.

This matters because errors arrive at the worst moment, when a user is already stuck, already irritated, already half out the door. UX writing meets them there. The principle of content-first design that Podmajersky and others advocate is to write the words for these hard moments before the screens are built, because the words often reveal that the flow itself is wrong. If you can't write a clear error, the form is probably asking for something it shouldn't.

So draft your empty states and your error messages first, in a plain text file, before anyone opens a design tool. List every way a screen can go wrong, no results, no connection, no permission, bad input, and write the human sentence for each. An hour of that routinely catches flow problems that would otherwise have cost a sprint.

flowchart TD
    E(["Something went wrong"])
    E --> W(["What happened
plain language, no codes"])
    E --> Y(["Why
the likely cause"])
    E --> F(["The fix
the exact next action"])
    W --> R(["User recovers,
stays in the flow"])
    Y --> R
    F --> R
A usable error message answers three questions; most failing ones answer only the first. Leaders Loop

Where this breaks down

Two honest limitations. First, the evidence base is uneven. The reading and scanning research is solid and replicated, but much of the "this microcopy lifted conversion by X%" canon is single-case study work from agencies and vendors, useful as illustration, weak as proof. Treat individual conversion claims (including the worked example below) as directional, not as laws, and A/B test the words that actually matter to you. Second, content design can curdle into bureaucracy: endless terminology spreadsheets, style-guide debates, and a content team that becomes a gate rather than a craft. The point was never process for its own sake, it was the user's task. When the rituals stop serving the task, drop them. As with information architecture, the tool is a lens, not a law.

A worked example

Take a mid-market SaaS company, call it illustrative, because the figures here are invented to show the shape of the work, not drawn from a real study. Their trial-to-paid flow stalls at the "Add payment method" step. The instinct is a redesign. A content-design pass instead starts with the need: "I need to add my card without fearing I'll be charged today."

Reading the screen against that need, three things jump out. The heading says "Billing information" (org-speak, not the user's worry). The reassurance that the trial is free until day 14 is buried in grey text below the fold. And the button says "Continue", which, to a nervous user, reads like "charge me now."

The fixes are all words. Heading becomes "Add a card to keep your account after the trial". The free-until-day-14 promise moves directly under it, in normal weight. The button becomes "Save card, no charge today". No new components, no new layout. In this illustrative scenario the team frames it as a content fix, ships it in a day, and runs it as an A/B test rather than declaring victory, which is exactly the discipline the thin evidence base demands. The lesson generalises even if the percentage wouldn't: the cheapest lever on this screen was always the sentences, and nobody owned them.

Frequently asked questions

Is content design just a fancy name for copywriting?

No. Copywriting persuades, it's pitched at selling and brand. Content design starts from a user's task and decides what information they need and in what form (text, table, diagram, video) to complete it. The two overlap, but a content designer might conclude the best "copy" is a table with three rows, or no words at all.

What's the difference between content design and UX writing?

They're close cousins and many people do both. The common split: content design is the broader practice of what a product should say and how information is structured to meet needs; UX writing is the focused craft of the words inside the interface, buttons, labels, error messages, empty states, tooltips. Think strategy and structure (content design) versus the exact sentences on screen (UX writing).

We're a small team with no content designer. Where do we start?

Start with error messages and button labels, the cheapest, highest-payoff words you own. Make buttons name their action ("Pay £40", not "Submit") and make every error state what went wrong and how to fix it. You don't need a hire to do that this week; you need someone to take responsibility for the words.

Does this actually move business metrics, or is it polish?

It can move metrics, clearer flows reduce drop-off and support tickets, but be sceptical of specific percentage claims, which are usually single-case and unverified. The defensible position: words are part of the product, users barely read them, so the words that are read carry disproportionate weight. Test the ones that matter rather than trusting a case study from someone else's product.

How does this connect to accessibility?

Directly. Plain language, clear labels and meaningful link text are core accessibility wins, they help everyone, and they're essential for people using screen readers or with cognitive differences. Good content design and good accessibility are largely the same discipline pointed at the same goal: an interface that's obvious.

Related in the Toolkit

Where to go next