Writing Interfaces People Actually Read

Write for Scanning, Not Reading

Nobody reads an interface like an article. People scan for the word that matches the job in their head, click, and move on. Your most important words are verbs and nouns: Save, Invoice, Download report. A button labelled 'Submit' asks for trust; one labelled 'Send invoice' explains itself. Specific beats clever every time.

Consistency is what turns a collection of screens into a product. Pick one word for each action and use it everywhere: if the button says 'Add client', the success message should say 'Client added', not 'Customer saved successfully'. Build a small vocabulary list for your product and treat it like a design token. Capitalisation, punctuation, and tone all belong on that list. When two teams name the same thing differently, users assume they are different things, and support tickets are born. We keep the vocabulary beside the component library, versioned with it, reviewed with it.

Error Messages Are Tiny Conversations

An error message is a conversation at the worst possible moment, so write it like a calm human, not a status code. Say what happened, say how to fix it, and never blame the user. 'That password needs at least ten characters' will always beat 'Invalid input'. Keep the message beside the field that caused it, in plain sight, and let people fix the problem without losing the work they already typed. Nothing in software feels worse than a form that clears itself to deliver bad news.

An empty state is not a dead end; it is the first thing a new user reads. Treat it as an invitation with one clear next step. Good empty states explain what belongs here, why it matters, and offer a button that starts the job. A blank screen with a grey icon teaches nothing and suggests the product is broken.

“People forgive a product almost anything except confusion. Every unclear label is a small withdrawal from a trust account you cannot see, and the balance runs out faster than you think. Clear words are not a finishing touch; they are the product, experienced one sentence at a time.”

Cut Half, Then Cut Again

The fastest editing technique in interface writing is deletion. Most labels survive being cut in half; many improve. 'Click here to view your recent invoices' becomes 'Recent invoices'. 'Are you sure you want to permanently delete this item?' becomes 'Delete this item permanently?' Short text is not rude text; it is respectful of the reader's time.

Finally, write for the people your analytics forget: the new hire on their first day, the customer in a hurry on a train, the user whose first language is not yours. Plain words travel well. Avoid idioms, jokes that need cultural context, and clever references in anything functional. Save the personality for the places designed to carry it: the brand pages, the celebrations, the empty states with room to breathe. The interface itself should sound like a good colleague: clear, calm, and brief. When we audit a product, the strings we rewrite most are never the marketing lines. They are the hundred small instructions nobody owned. Give them an owner, and the whole product starts to sound like one thoughtful team made it.

Keep a Voice, Skip the Script

Document three or four voice principles, not a script. Ours are: be plain, be brief, be kind, and never make the user feel stupid. Principles survive new features and new writers; scripts do not. Review them twice a year, with real examples from your own product, and your interface will keep one voice as the team grows. Keep the principles where the team can find them, pinned beside the component library. When a new writer joins, have them rewrite ten real strings and review the results together. Voice is what a hundred small decisions sound like when nobody is checking.

‍