Writing Interface Copy That Sounds Human

Good at words, bad at your words

Interface copy is one of the strongest uses of a language model in the whole design process. It is high volume, it is fiddly, it is the thing that gets left until Thursday afternoon, and it has a clear shape the model has seen endlessly.

It is also where the tool's personality is most obviously wrong, and where designers most often give up after one attempt.

Ask for an error message unbriefed and you will get something like: "Oops! Something went wrong. We're really sorry about that. Please try again later, and if the problem persists, don't hesitate to reach out to our friendly support team. Thanks for your patience!"

Every sentence there is doing something unhelpful. Let us name the pattern, because once you can name it you can prohibit it.

The four default sins

It over-apologises. Assistants are tuned to be agreeable, and agreeableness bleeds into product copy as constant sorrow. A failed upload does not require an apology, it requires an instruction. Excessive apology also reads as suspicious: a product that says sorry for everything sounds like one that fails often.

It over-explains. The default is to be complete rather than brief, so you get a subordinate clause covering every eventuality. Interface copy is read in a hurry by someone who is trying to do something else. Length is not thoroughness, it is friction.

It performs cheerfulness. "Oops!", "Uh oh!", "Let's get you sorted!", exclamation marks at the end of a sentence about a payment failing. Playfulness can be right, but it has to be a decision you made, not a default you inherited.

It hedges. "It looks like there may have been an issue." Either something happened or it did not. Vagueness in an error message is the copy equivalent of a shrug.

Briefing a voice

The fix is not a cleverer request. It is giving the model the brief you would give a copywriter, which means examples and prohibitions rather than adjectives.

Adjectives on their own are close to useless. "Friendly but professional" is a phrase that describes almost every product ever shipped, and the model will interpret it as its own default. What actually moves the output is three things: samples of copy you already ship and like, an explicit list of what is banned, and hard constraints on length.

The samples do most of the work, and it is worth understanding why. A model completes patterns, so three real strings from your product are a pattern it can extend. Any adjective you choose has to be translated into concrete sentences, and it will do that translation using its own defaults rather than yours. Give it your sentences and there is nothing to translate. Pick samples that are boring and typical rather than the two lines you are proudest of, because you want the register you ship every day, not your best day.

The banned list matters for a different reason: it is the only part of the brief that is unambiguous. "Do not be over-apologetic" invites interpretation. "Never use the word sorry unless the fault is ours" does not. Build the list from what actually annoys you in the output, add to it each time something slips through, and keep it in a note you can paste, because you will use it for years and across whatever tool you are using at the time.

Constraints it will get wrong

Give character limits anyway, but do not trust the count. Language models are unreliable at counting characters, because they do not process text as individual letters. Ask for forty characters and you will often get thirty-one or forty-six, delivered with total confidence that it is forty.

The practical answer: state the limit, generate several options, and check the fit yourself. The limit still helps enormously as a signal of intent, because "40 characters or fewer" produces a different kind of sentence from "keep it short". You are steering the register, and verifying the arithmetic.

Before I ask for any copy, here is the voice you are writing in.
Product: [what it is]. Reader: [who they are, and what mood they are
likely to be in when they see this].
Copy we already ship and like, so match this register:

[paste a real string]
[paste a real string]
[paste a real string]
Never use: exclamation marks, 'Oops', 'Uh oh', 'Sorry' unless the fault
is ours, 'simply', 'just', 'please note', 'in order to', em dashes.
Spelling: British. Contractions: [allowed / not allowed].
Sentence limit: [one sentence / two sentences].
For every request, give me three options at different lengths, shortest
first, and state the character count of each so I can check it.

Beyond errors

The same brief works across the rest of the surface, with one adjustment each.

Buttons. Ask for the verb the user would use, not the verb the system uses. Systems submit and process, people send and pay. Ask for options at one word and at three, and read them as they would appear next to the neighbouring button.

Empty states. The default output apologises for the emptiness. What you want is the one action that makes the emptiness go away, and a sentence explaining what will appear here once it does. Brief it explicitly: teach, do not sympathise.

Permission and access. This is where over-explaining does real harm. Say who can grant access and how to reach them. Do not speculate about why access was refused.

Confirmations for destructive actions. Insist that the copy names the specific thing being destroyed and whether it can be recovered. Generic confirmations train people to click through them.