UX writing: what's breaking your interface and how to fix it

A site that users don't understand has the same problem as a site that doesn't rank on Google. In both cases someone didn't get where they were supposed to go. The difference: poor SEO shows up in Analytics. The copy that reads "An error occurred. Please try again." gets reported by nobody.

UX writing is the text the interface shows instead of you: buttons, error messages, field labels, tooltips, loading states, empty screens. Each one is a point at which the user either understands what to do, or doesn't. There's no middle ground. Copy that introduces doubt does it every time.

Why it matters more than it seems

Even a well-designed interface can't save itself if the button label says the wrong thing. Design removes visual friction. Copy removes cognitive friction. One without the other is only half the job.

The principles behind useful interface messages were formalised by Nielsen Norman Group and are straightforward: interface copy should help users recognise a problem, understand it, and know what to do next. Heuristic #9 in the standard UX evaluation list describes this directly as "Help users recognize, diagnose, and recover from errors," and it has been the benchmark for interface evaluation for decades.

In practice: a user who gets a message that says "Error" with no context doesn't go back to the task. They leave. A user who sees a button labelled "Submit" just before sending a registration form doesn't know what will happen after clicking. Uncertainty before an irreversible action is one of the main reasons people abandon processes halfway.

Where the problem comes from

The most common scenario looks like this: the designer builds screens with Lorem Ipsum where the text should go, because the content "gets added later." The developer fills in button labels from memory because something has to go there. If the company has someone in marketing, they add a welcome message along the lines of "We're so glad you're here." Nobody reads it all together before it reaches the user, and nobody checks whether the 3 people writing for the same page are writing in the same tone.

The result is predictable. A site that says "Your account" in the menu, "Welcome!" in the footer, and "Please enter your email address" in the form sounds like 3 different companies glued together. Users don't analyse this. They just feel that something's off.

Then there's translating from English. Products launched in other markets often start from English patterns and are localised sentence by sentence, without stopping to think about what the target language actually requires. English has one "you." Other languages have formal and informal registers, and the decision between them has to be made once, at the start, for the entire product. When it isn't, every page comes out differently.

What this looks like in practice

One concrete example. You fill in an order form, click the button, and instead of confirmation you get: "Error. Operation failed." What happened? No idea. What do you do? Also no idea. Most people close the tab and don't come back.

The same message written differently: "We couldn't process the payment. Check that the card number has 16 digits." The situation is identical, but the user now has something they didn't have before: an instruction. That's the difference between copy that describes a system state and copy that tells a person what to do.

The same pattern plays out everywhere else in the interface. An empty screen that says "No data" looks like a crash to someone who just created an account. "Your orders will appear here once you place your first one." isn't more information. It's just information given with context. A button that says "Submit" before a quote form says nothing, because you don't know what's being submitted or what you'll get back. "Request a free quote" removes that uncertainty with one phrase. A dialog that asks "Are you sure you want to delete?" with buttons labelled "Yes" and "No" forces the user to translate an abstract question into a concrete decision. "Delete permanently" and "Go back" don't.

These aren't things users notice and comment on. They're things that either work or don't.

How to fix it

The first change is in process. Interface copy has to be part of the design from the start, not something you fill in at the end once the visuals are approved. When someone designs a screen, they should know immediately what will appear on it, not leave a placeholder hoping someone will fill it in later.

It starts with one decision: whether to address users formally or informally. That sounds trivial, but if you don't decide it before you start building, everyone writes according to their own instinct. Add a few terms on top of that: what you call the main object in the system, which words you avoid, what you never write. It doesn't need to be a long document. 2 pages is enough to get everyone writing in the same voice.

Then, for every screen that can show something other than "everything is fine," an error, an empty list, a deletion confirmation, a loading state, plan the copy with the same care you'd plan the layout. What does the user see? What does it tell them? What's their next step? If that's written into the design, someone will write it with their head on. If it's not, someone will type the first thing that comes to mind.

And the last thing, without which the rest won't hold: there has to be one person responsible for what's written in the interface. It doesn't have to be a UX writing specialist. It can be the designer or the PM. The important thing is that someone has the final say. Without that, every copy change is a decision made from scratch, by a different person, every time.

An interface without an owner for its copy always shows it. And you can always feel it.