UX Writing

For a long time the words inside a product belonged to nobody. Designers handed over mockups with "headline goes here" written in the box, and engineers invented whatever text was needed while they were in the code. A screen could fail in twenty different ways and still have exactly one sentence to describe all of them: something went wrong, please try again later.

What that sentence actually did showed up in support. Twenty tickets a day arrived saying a file wouldn't upload, and every time an agent opened the account the cause was the same — the file was over the size limit. Had the screen said the file is larger than 20MB and can't be uploaded, that person would have shrunk the file instead of writing in. One missing line of text was pulling a human being into the loop twenty times a day.

There was a second problem, quieter than the first. The same thing had a different name on every screen. Signup called it a workspace, settings called it a team, billing called it an organization. A user who reads all three stops to work out whether they are the same thing. Nobody wrote anything false; each screen was built by a different person in a different month, and the product as a whole stopped making sense.

Within the Design axis this term sits on the side that asks what is being designed. Everything a person goes through while using a product gets called user experience, and several materials make up that experience: the skeleton that decides how content is divided and what each part is named, the behavior that decides how the product responds when something is clicked or dragged, and the surface that uses size and color to decide what gets read first. UX writing takes the words. The skeleton needs menu names and the behavior needs a line that says something is in progress, so copy can't be settled apart from those three.

UX writing is what promotes those words into design objects, on the same footing as the components around them. Color and spacing get decided in advance and then applied; copy works the same way. Past a certain company size the work becomes a job — a UX writer — and before that it is split between designers and product managers. No title doesn't mean no work. It means the words get invented from scratch every time, with no standard behind them.

Nine terms sit under this one, in three groups. What gets written (the artifacts), what has been agreed in advance about how to write it (the standards), and how it survives a move into another language (the extensions). The first group is what a user sees on the screen. The other two are the rules that produce those words and the conditions those rules meet when they cross a language boundary.

There are five artifacts. Microcopy sits above the rest: it is the umbrella name for every short string scattered through a product, the one word on a button, the line under an input field. The other four are the spots that cause trouble often enough to have earned their own names.

1. Button label — tells a person what happens when they press it. "OK" doesn't say what is being confirmed. In a dialog asking about deletion, "Delete" is the safer text. Putting the outcome in a verb means that someone who presses without reading the explanation above still gets what they expected.
2. Error message — needs both halves: what went wrong and what to do about it. With the first half alone, people go to support. Even when the cause can't be stated, the message can still say whether to retry or take another route.
3. Empty state copy — the text left on screen when a list has nothing in it. "No documents" reports a fact and stops. This is usually the first screen a new account sees, so explaining how to create the first document turns the space into onboarding.
4. Placeholder — the faint example inside an input field. It disappears as soon as typing starts, so format instructions put there are gone at the moment they are needed. Instructions belong outside the field; this spot holds an example.
5. Notification and confirmation text belongs to the same group. A notification reaches someone who isn't looking at the product, so what happened and where it happened both have to fit in one line. A confirmation dialog asks about something irreversible, so the sentence names what disappears. "Three documents will be permanently deleted" and "Are you sure?" produce different levels of certainty in the hand about to click.

There are two standards, agreed in advance so that nobody re-decides them on every screen.

1. Voice and tone — voice is the attitude a product keeps everywhere, tone is how that attitude bends to a situation. The same person speaks differently at a funeral and at a birthday party without changing who they are. Deciding not to joke on a failed-payment screen is a tone decision.
2. Terminology consistency — the rule that one concept always gets one word. Pick one of workspace, team and organization, record it in a glossary, and check that list before building a new screen. The rule is simple; keeping it requires the written list to exist.

There are two extensions, and their order is fixed.

1. Internationalization — building the structure so more than one language can live in it. Strings hardcoded into the source can't be translated later, and German often needs more room than English for the same meaning, so a button with a fixed width breaks. Date and currency formats also get decided by settings rather than by code.
2. Localization — changing the wording on top of that structure to fit a language and a culture. Not only translation: the names and companies used in examples, the level of formality, and the order of fields in an address form all change.

Reversing the order is expensive. Shipping a second language on a product that skipped internationalization means opening every screen and pulling the strings out by hand, which usually takes longer than building the structure would have. Even while a product has one language, internationalization pays. With strings outside the code, the person who writes the copy can fix it without an engineer, so changing one word doesn't wait on a release.

Three questions cover most decisions about a piece of copy. What is the person in the middle of doing, what can they do after reading this, and does the rest of the product call the same thing by the same name. When the third one fails it can't be fixed alone — it becomes work for the glossary and the design system.

Standards don't remove the writing; each screen still needs its own words. So teams tend to fix an order. Before drawing a screen, list the ways it can fail, write one line for each of them, and then lay out the screen around those lines. Do it the other way and the words get forced into a width that was already decided, and what gets squeezed out first is the condition and the next action. Putting real sentences into a mockup follows from the same reasoning. Filler text means nobody checks whether the screen reads before it moves on.

Copy carries the most weight where a person is doing something for the first time or doing something they can't undo. The blank screen right after signup, the screen that takes payment details, the dialog before a deletion, the screen that hands over permissions. Fixing the words in those four places alone often visibly changes what support gets asked about.

"Let's make this button say 'Delete' instead of 'OK.' You can't see what's being confirmed."

Arguing to design for the person who reads only the button and clicks.

"The error text doesn't say what to do about it. This comes straight back to us as a ticket."

A message that names a cause without naming a next action pulls a human into the loop.

"If we call it a workspace here, we have to change the settings screen too."

Changing one word on one screen turns into a product-wide terminology decision.

At Pagedeck all three came up in the month when upload tickets piled up. Sofia sorted a week of ninety tickets by type and found forty in one spot: a file was uploaded and nothing happened. What had actually happened was a silent failure past the size limit, with "something went wrong" on the screen.

Noa went to fix the sentence and got stopped by Theo. The server was returning a single failure type, so the screen had no way to tell a size problem from a format problem. Writing the message properly meant splitting the causes on the server first, which is how one line of copy dragged three days of backend work behind it. The finished message ran two sentences: the file is larger than 20MB, compress it or split it and upload again.

The following month that ticket type dropped from forty to six. What Mia fixed on the spot wasn't a sentence, it was an order of operations. From then on, new screens started by listing the failure cases and writing a line for each one, and the layout came after. One more thing changed with it. Listing the failures up front settles what the server has to distinguish before anyone draws a screen, so Theo stopped losing three days after the fact.

The most common misreading is that UX writing means writing short. The word micro travels with it and the space on screen really is narrow, so the assumption is easy to make. But the test is not length, it is whether the next action is visible after reading. "The file is larger than 20MB and can't be uploaded" is twice as long as "something went wrong" and it removes tickets. Aim at shortness and the condition and the next action are the first things to fall out. The screen gets tidier and support gets busier. What should go first is not the condition but the greeting and the apology. Drop the line apologizing for the inconvenience, put what to do in its place, and the length is unchanged while the tickets go down.

The second is treating copy as something to fill in later. Unlike code or visuals it looks changeable at any time. In practice copy drags layout and backend work along with it. A button label growing from two words to six means redoing the arrangement, and an honest error message means the server has to distinguish its failures. Left alone, this assumption gets the words written the night before launch like blanks on a form, and words written that way arrive truncated to fit the screen or unable to name the cause. With translation in the chain, that one late day grows into several weeks.