The words in your interface are the interface. Everything else — layout, colour, motion — is arrangement around the words that tell someone what this is and what happens next.
People read labels, not layouts
Nobody has ever abandoned a checkout because of the grid. They abandon it because a button said something they did not trust, or a field asked for something they did not understand, or an error told them something was wrong without saying what.
Watch anyone use software they have not seen before and you will notice they are reading. Scanning for the word that matches what they are trying to do. If that word is not there, no amount of visual polish rescues the screen.
Most product failures are language failures first
A menu named after an internal team. A toggle whose two states are both plausible readings of the same label. A confirmation dialogue where ‘Cancel’ could mean cancel the action or cancel the cancelling.
These are not writing problems that happen to appear in a product. They are design problems that surface as writing, because naming a thing accurately requires understanding it, and vague copy is nearly always a symptom of a fuzzy model underneath.
The organisational reason it stays bad
Copy gets written last, by whoever is available, frequently by an engineer filling in a placeholder at the end of a sprint because the mock-up said ‘Lorem ipsum’ and something had to ship.
So the highest-leverage surface in the product is treated as the lowest-priority task, assigned to whoever has least context, at the point in the schedule with least time. Then everyone is surprised that support tickets cluster around three specific screens.
Specifics that reliably help
Error messages should say what to do next, not merely what went wrong. ‘Something went wrong’ is a shrug in a sentence.
Empty states are the best teaching moment you will ever get. The user is looking directly at a blank screen with nothing competing for attention, and most products waste it on an illustration.
Button verbs should match the user’s intent, not the system’s operation. People do not submit; they send, save, book or pay.
Never make someone learn your database schema. If a label only parses to whoever designed the tables, it is internal vocabulary that escaped.
Enterprise is the worst offender
Every enterprise product I have worked on had internal vocabulary leaking into the interface — terms that made complete sense to the team that built the module and none at all to the customer paying for it.
It is an easy problem to spot from outside and a very hard one to spot from inside, because everyone in the building has been fluent in that vocabulary for years. Naming things is where a fresh pair of eyes earns their keep fastest.
Write the copy at wireframe stage
I write real copy into wireframes rather than placeholder text. Not final copy, but honest attempts at the actual words.
It works as a diagnostic. If you cannot name the button, you do not yet understand the screen — and it is enormously cheaper to discover that in a wireframe than in a support queue.