The Interface Is Mostly Words

Take any product screen and remove the text. Keep the layout, the icons, the colours, the beautiful spacing — just delete the words.

Nothing is usable. Not the navigation, not the buttons, not the fields, not the errors. Even the icons stop meaning anything, because most icons are only recognisable next to the label that taught them to you.

So the interface is largely a piece of writing. And in most teams it's the last thing done, in ten minutes, by whoever is free — usually a developer typing a placeholder that ships.

What microcopy is doing

The term for the small functional text of an interface is microcopy: buttons, labels, hints, errors, empty states, confirmations, notifications, tooltips. Kinneret Yifrah's work made the case that this is a design discipline rather than a writing chore, and the argument holds because microcopy answers exactly the questions a person has at the moment they're stuck.

Which makes rewriting it the cheapest improvement in this entire sphere. There's no engineering, no migration, no redesign. You change nineteen strings and the conversion rate moves.

The rules that carry most of the weight

Use their words. The research stage gave you a vocabulary — the words from interviews, support tickets, empty search queries. Ship those, not the internal ones. Nobody outside your company knows what an "entity," a "workspace object" or a "contragent" is.

Verbs on buttons, outcomes not mechanisms. "Create account," "Send invitation," "Delete 3 files." Never "Submit," "OK," "Yes." The test: read only the button and say what happens.

Front-load. The first two words carry the meaning — that's what the F-pattern article was really about. "Delivery takes 3–5 days" beats "Please note that delivery of your order will typically take 3–5 days."

Active voice, second person. "We couldn't process your payment" beats "The payment could not be processed." Someone did something; say who.

Numbers instead of adjectives. "Takes about two minutes" instead of "quick and easy." "Up to 25 MB" instead of "large files supported." Specifics are checkable; adjectives are noise.

Cut it, then cut it again. Most interface text has a preamble that can go entirely: "Please note that," "In order to," "You may wish to."

Error messages are the remembered moment

The peak–end rule from the first article said people remember the worst moment and the ending. Error messages are usually both.

A working error message has three parts:

1. What happened — in human language.
2. Why — if it helps them act.
3. What to do next — the actual next step, ideally as a button.

"Error: validation failed" has none of the three. "That email address is missing an @" has all three implicitly, in six words.

Three more rules:

Don't blame. "You entered an invalid date" makes it the person's fault. "We need the date as day/month/year" — or better, accept whatever they typed and parse it.

Never show raw codes alone. If a technical code has to be there for support, put it under human text, in small type.

Match the tone to the stakes. A cheerful "Oops! Something went wrong 🙈" is fine for a failed search and appalling next to a failed payment or lost work. The rule: the more serious the failure, the more plainly you write. Humour in an interface has a place, and that place is never the moment someone lost something.

Nobody has ever wanted a joke at the moment they lost their data.

Voice is constant, tone varies

The distinction that makes writing consistent without making it robotic: voice is who you are and doesn't change; tone is how you speak in a given situation and must. The same product can be warm on an empty state, brisk in a settings panel and completely plain in an error — while sounding like one product throughout.

The practical version is a short table: for each situation type — success, error, empty, destructive confirmation, waiting — one line on how you speak there. This is a fifteen-minute exercise that outperforms most style guides.

Length, plurals and other languages

If a product is bilingual, the text is not a translation problem but a layout constraint.

Text expands. Russian and German run noticeably longer than English — often 20–35% for short interface strings. A button designed to fit "Save" exactly will break on "Сохранить." Design with the longest language, or set widths that tolerate growth.

Never assemble sentences from fragments. Concatenating "You have" + n + "new" + item breaks in any language with grammatical gender, cases or non-trivial plural rules. Russian has three plural forms; a naive if (n === 1) produces wrong text for 2, 3, 22 and 101. Use proper plural rules, and give translators whole sentences, not pieces.

Words are not the only thing that's local. Date formats, number separators, currency position, name order, address shape and week start all differ. A form that insists on a five-digit postcode has already excluded several countries.

Plain language is accessibility

The accessibility article listed "understandable" as one of the four principles, and this is where most of it lives.

Short sentences, one idea each. Long conditional sentences are where readers with dyslexia, non-native speakers and tired people all fall off — which is nearly everyone at some point in the day.

No double negatives. The classic is the unsubscribe checkbox: "Uncheck this box if you don't want to not receive emails." Every product has one of these and nobody can parse it.

Beware negative checkboxes generally. "Don't send me updates," checked or unchecked, is a coin flip. State it positively: "Email me about updates."

Expand or drop abbreviations. Internal shorthand is invisible to the person who wrote it and opaque to everyone else — the curse of knowledge in its purest textual form.

In practice

Rewrite one error message properly. What happened, why, what to do next. Then find the other twenty and do them this week.

Read your screen with only the buttons visible. Cover everything else. If the buttons don't make sense alone, they aren't labelled with outcomes.

Delete the first three words of every hint. "Please note that," "In order to," "You can use this to." The sentence almost always improves.

Build the tone table. Five situations, one line each on how you speak there. Pin it where the writing happens.

Check your longest string in the other language. Take the widest button and see what its Russian or German label does to the layout.

Search your product for "Oops." Then check what has actually gone wrong at each of those moments, and rewrite the ones where the joke is inappropriate.

Check yourself

Close the article and answer in your own words:

1. Why is rewriting microcopy the cheapest improvement available to you?
2. What are the three parts of a working error message, and which is most often missing?
3. Why does tone need to change with the seriousness of the situation, and where is humour never acceptable?
4. What's the difference between voice and tone, and why does the distinction help?
5. Why must interface sentences never be assembled from fragments?
6. Give two examples of text that fails for accessibility reasons.
7. What's wrong with a checkbox labelled "Don't send me updates"?

In short

• Delete the words and nothing works — the interface is largely a piece of writing, usually done last by whoever was free.
• Microcopy answers the user's question at the moment they're stuck; rewriting it is the cheapest improvement in the sphere.
• Use the user's vocabulary, put outcomes on buttons, front-load the first two words, write active and second-person, prefer numbers to adjectives.
• Error messages need what happened, why, and what to do next — with no blame, no bare codes, and no jokes when the stakes are real.
• Voice stays constant, tone varies by situation. A five-line tone table beats most style guides.
• Other languages run 20–35% longer, plural rules differ, and sentences assembled from fragments break everywhere.
• Plain language is an accessibility requirement: short sentences, no double negatives, no negative checkboxes, no unexplained abbreviations.