UX Writer

For a long time the words inside a product belonged to nobody. They got written wherever they became necessary while a screen was being built, and whatever an engineer typed as a placeholder shipped. Design mockups carried gray boxes labeled "guidance text here," which meant the real sentence was written for the first time as it went into the code.

The result came back as support volume. A user who sees "an error occurred" after a failed upload doesn't know what to do and writes to support. A user who sees "this file is over 20MB and can't be uploaded" shrinks the file and tries again. Same feature, same code, and one becomes a ticket while the other becomes a resolution.

Naming drift piled up too. The same place is a workspace on one screen, a team space on another, and an organization in settings. The people who built it know all three point at one thing; someone arriving for the first time is trying to learn three separate concepts. That's why the words got a seat of their own.

The day is filled with finding the words attached to a screen, rewriting them, and checking whether the rewrite actually works. The work comes in five bundles.

1. Building the inventory — pull out every piece of text on a screen. Buttons, item names, guidance, error notices, the screen shown when there's nothing to display, confirmation dialogs, and the subject line of the email that leaves from there. Treating short strings like buttons and notices as their own material is called microcopy. Laid out as a list, three spellings of the same word on one screen become visible at a glance in a way they never are while reading the screen.
2. Writing — the goal isn't brevity, it's that the next action becomes obvious. An error message, which tells a user the problem and the way out, carries three things: what happened, which condition caused it, and what the user can do. The third is the one most often missing, and its absence is what generates tickets.
3. Maintaining the glossary — fix one name per thing. Pick one of workspace, team space, or organization, write it down, and align every screen to it. Voice and tone, the product's settled attitude and its register per situation, lives in the same document. Announcing a failed payment and welcoming a first document in the same register means one of the two is wrong. The glossary is also what lets somebody else write a screen without introducing a fourth name for the same thing.
4. Testing — confirm the rewrite is better. An A/B test, which shows two versions to randomly split groups and compares the outcome, is the most conclusive when only the copy differs; with low traffic, showing users the screen for five seconds and asking what they understood works instead.
5. Leaving room for other languages — a button that takes twelve characters in one language can take twenty-eight in German. Even if localization, adapting expression to a language and culture, comes later, failing to leave generous width now means redrawing the screen then. The same applies to sentences assembled from fragments, which reorder themselves differently in other grammars.

The words have to be settled at the same time as the screen, and they stop being reachable the moment they go into code. So this role moves interlocked with five seats.

1. Designer — the closest one. Copy has to go in while Noa is drawing the mockup, so that widths and line counts line up. Draw gray boxes and drop the text in later, and a thirty-character sentence ends up not fitting a two-line slot.
2. Engineer — when strings are scattered through the code, changing one word means waiting for a release. Once Theo pulls the strings into a separate file, the writer edits and ships them directly, and how fast this role can work is largely set by whether that structure exists.
3. Product manager — the one deciding what has to be communicated. Mia explains how a new feature behaves, and only the part a user needs to know becomes a sentence. Most of that conversation is about what to leave out.
4. Customer success and support — the ones who report which copy generates tickets. Thirty instances of the same question reaching Sofia in a month means that screen's text isn't answering it.
5. Legal — payment and privacy notices contain sentences whose wording can't be changed. Copy that goes through Grace's review has its editable range fixed in advance, so the work there is arranging fixed clauses in a readable order rather than rewriting them.

"This error message doesn't say what to do about it. That's why we get tickets."

The way out is missing from the notice.

"We standardized on workspace, so change 'organization' in settings too."

Finding a screen that drifted from the name in the glossary.

"Widen the button a little. It goes to two lines in other languages."

A request calculated for a future translation rather than the screen in front of them.

Pagedeck has no dedicated writer, so Noa and Mia split the work. Their glossary holds about thirty terms and gets consulted before any new screen. Last quarter they rewrote twelve upload error messages, and after a line about what to do was added to each one, tickets about that screen halved. Nothing about the upload feature itself changed in that quarter.

The most common mistake is assuming anyone who writes well can do it. The output is sentences, so the assumption comes easily. But words inside a product require knowing how a feature behaves under which conditions. Not knowing whether an upload fails on size, format, or permission leaves nothing to write except "an error occurred." The direction differs too. Promotional copy has to be noticed; product copy should pass without the reader registering that they read it. A clever line inside a screen starts grating the second time someone sees it, and people see these screens hundreds of times.

Believing copy can be slotted in at the end is the other one. Once the screen is settled, the words inside it look like they'll follow. But writing the sentences frequently exposes that the screen's structure is wrong. If you can't name in one word what a button does, that button is doing two things. Twisting the copy to fit both actions into one sentence buries a structural problem under a sentence, and the user only learns what happens after pressing it. That's why UX writing, the design of a product's words as a whole, belongs at the same moment as screen design.