Writing interface copy that sounds like a person
The words in your product are part of the design. A few habits that make buttons, errors and empty states clearer and kinder.
Most interface copy is written last, in a hurry, by whoever is closest to the ticket. It shows. “An error has occurred.” “Submit.” “No data available.” Each one is technically true and completely unhelpful.
Good copy is cheap to write and pays for itself in fewer support tickets. These are the habits I come back to on every project.
Say what will happen
A button should describe its result, not the mechanics. “Submit” tells people nothing; “Send invoice” tells them exactly what they’re about to do. If a label could fit on any button in the product, it’s too vague.
Write errors that help
A useful error message answers three questions: what happened, why, and what to do next.
- Bad: Invalid input.
- Better: That date is in the past. Choose a date from tomorrow onwards.
Never blame the person. “You entered the wrong password” and “That password doesn’t match” contain the same information, but only one of them sounds like a colleague.
Make empty states useful
An empty screen is often someone’s first impression of a feature. Instead of “No projects”, explain what the space is for and give them the first step: “Projects keep your files and feedback in one place. Create your first one.”
Read it out loud
The simplest test there is. If a sentence would sound strange said to a person across the table, rewrite it until it doesn’t. Contractions are fine. Short sentences are better. Nobody has ever complained that an app was too easy to understand.