Write your UI copy for one named customer

Interface copy written for "users" always lands in the same register: confident, abstract, and slightly hollow. Streamline your workflow. Powerful yet simple. Everything you need to ship faster. Nobody decided to write that. It is what you get when the audience is everybody, because everybody is nobody in particular.

Copy written for one specific person lands somewhere far more useful, and it takes less effort, not more.

Give the person a name and a bad afternoon

Not a demographic. A person.

Dana runs operations at a forty-person logistics firm. She lives in a spreadsheet that three other people also edit. She has been burned by two tools that promised to replace it and delivered a dashboard. She distrusts anything that calls itself a platform. It is 4pm, a shipment is wrong, and she is trying to work out who changed a value on Tuesday.

That is enough. The bad afternoon matters most — a persona describing someone calm and curious is a persona that never has to make a decision.

The practice has a long lineage in interaction design; Nielsen Norman Group's overview of personas covers where it came from and the ways it goes wrong. The usual failure is a persona built for a research deck rather than for writing: three paragraphs of demographics and a stock photo, no opinions, no vocabulary, nothing you could disagree with.

Now every microcopy decision has an answer

The value shows up in the small choices, which is where most product copy actually lives:

• Does Dana know what "orchestration" means? No — so the empty state does not say it.
• Would she read a 40-word empty state? Not at 4pm. Two sentences, one of which is a link.
• Does she need reassurance or speed here? On the destructive-action dialog, reassurance. On the search field, speed.
• What does she call this thing? If she says "the sheet" and your nav says "Workspace", one of you is going to lose, and it will be her.

Notice that these are answerable. "What tone should the empty state have?" is unanswerable in general and trivial once there is a specific person on the other end. That is the whole mechanism: the persona does not make the copy better by magic, it makes the questions decidable.

The GOV.UK writing guidance is the best public example of what falls out of this discipline at scale — plain words, short sentences, and a ruthless preference for the reader's vocabulary over the organisation's.

Keep the persona next to the visual decisions

Here is the part that is usually got wrong, and it is a filing problem rather than a writing problem.

The persona lives in a research document. The palette and typefaces live in a design file. The two are updated on different schedules by different people, and within a quarter they describe different products. Voice and visuals fail together when they are stored apart: a warm, plain-spoken voice paired with a cold, dense interface reads as dishonest, and neither half looks broken on its own.

This matters more when an agent is doing the assembling. Handed a palette and no persona, an agent will produce competent house-style SaaS copy — the exact hollow register above, because that is the average of everything it has read. Handed both, it writes for Dana. Ask for a pricing page and the FAQ answers the question Dana would actually ask, in the words she would use.

That is why the persona belongs on the same canvas as the type and the colour rather than in a separate doc — the same argument as how to teach a coding agent your design taste, and the reason a palette needs job descriptions rather than hex codes. It is also the difference between an app that sounds like your product and one that sounds like every other vibe-coded app.

A test

Take three pieces of microcopy from your product — an empty state, an error, a confirmation dialog. Read them as Dana, at 4pm, with a shipment wrong.

If any of them would annoy her, you have found a decision nobody made. If all three would annoy her, you are writing for "users".

Further reading

• Personas — Nielsen Norman Group, on doing this without producing a deck nobody reads
• Writing for GOV.UK — plain language as an enforced standard
• Apple Human Interface Guidelines — voice treated as part of the interface, not a layer on top