UX Writer

I start by figuring out what the user is actually feeling in that moment, usually frustration or uncertainty, and I write toward that rather than toward the system's internal logic. For an error message I want three things in as few words as possible: what happened, why it matters to the user, and what to do next. I avoid blaming the user or hiding behind technical codes like 'Error 403' unless a support team specifically needs that reference, in which case I tuck it into a details link rather than the headline. For empty states I treat the moment as an invitation rather than a dead end: instead of 'No results found' I write something that tells the user what to try next, like adjusting a filter or adding their first item. I always read the copy out loud before shipping it, because writing that looks fine on a Figma frame often sounds robotic when spoken, and that's usually the giveaway that it needs another pass.

I treat the voice and tone guide as a constraint that makes my job faster, not a cage. Before I write anything new I check whether a pattern already exists for the situation, because consistency matters more to users than a clever new line every time. When a guideline doesn't fit a new use case, I don't just quietly break it. I flag the gap to whoever owns the content system and propose an addition, with examples, so the next writer doesn't hit the same wall. I've also pushed back the other way, when a guideline was written for marketing tone and got copy-pasted into product surfaces where it read as too casual for something like a data deletion warning. Working inside a design system also means building copy as reusable components where it makes sense, string patterns with variables rather than one-off sentences, so engineering can implement them consistently without coming back to me for every instance.

Brevity is a means, not the goal, so I never cut a word just to hit a character limit if it costs the user's understanding. My rule of thumb is to write the clear version first, then look for words that are doing no work: hedging phrases, redundant nouns, anything the interface already communicates visually. A button next to a bin icon doesn't need to say 'Delete this item permanently', it can say 'Delete', because the icon and the context are already carrying meaning. Where I hold the line is on ambiguity: if shortening 'Your session will expire in 5 minutes' to 'Session expiring' saves space but leaves a user unsure whether to save their work right now, I keep the longer version. Space constraints on mobile push this the hardest, so I usually write a full-length version and a truncated version together, and test which one still lets a user act correctly without re-reading.

I write every string assuming it will be read by a screen reader and translated into a language with a very different sentence structure, because both of those things are true for a meaningful share of our users. That means avoiding copy that relies on visual position, like 'click the button on the right', since a screen reader user has no sense of layout, and using accessible labels that describe the action, not just decorative link text like 'click here'. For localisation I avoid idioms and wordplay that don't survive translation, keep sentence structure simple so word order changes don't break the meaning, and never concatenate strings around a variable, since grammar rules around gender and plurals differ enough by language that a sentence built from fragments in English usually breaks in French or Spanish. I also flag character limits to translators early, because a word that fits in English routinely runs 30 percent longer in German or French.

We had an onboarding step asking users to 'Confirm your workspace', and in testing, three out of five participants paused and asked what a workspace was, since we hadn't introduced the term anywhere earlier in the flow. I'd assumed the word was self-explanatory because the product team used it constantly internally, which is exactly the trap: I was writing from inside the product's vocabulary instead of the user's. I rewrote the step to explain the concept in plain terms first, something closer to 'This is where your team's projects will live. Sound right?', and reran a quick moderated test with five new participants. All five understood it immediately and moved through the step without hesitating. The bigger change I made afterward was adding a rule to our style guide: any internal product noun needs a plain-language definition the first time it appears in a user-facing flow, not just in documentation.

An engineer wanted to ship 'Invalid input' as the error message for a phone number field because it matched a validation library's default output and required no extra work. I pushed back because it doesn't tell the user what's actually wrong: a missing area code versus extra characters versus a typo all produce very different fixes, and a generic message just leaves people guessing. Rather than arguing on tone alone, I asked what specific validation cases the library already distinguished internally, and it turned out three distinct error states existed under the hood but were all being collapsed into one message. I wrote three short, specific replacements and showed the engineer that the extra implementation cost was maybe twenty minutes, since the logic already existed, just wasn't surfaced. That reframing, from 'my copy preference' to 'here's the support ticket volume this creates', got it shipped. We saw a drop in support tickets tagged for that field the following month.

When I joined, tone decisions lived in individual writers' heads and in scattered Slack threads, so every new feature reinvented rules that already existed somewhere. I started the style guide with the highest-friction patterns first: how we write error states, how we refer to the product itself, capitalisation rules, and how we handle numbers and dates, rather than trying to document everything at once. I built it as a living reference in our design system tool, next to the components it applied to, so a designer dropping in a button component would see the copy rule right there instead of searching a separate wiki. I also set up a lightweight review step: any new pattern that came up twice in a sprint got proposed as an addition to the guide rather than staying a one-off decision. Six months in, new writers and even non-writers on the product team were referencing it unprompted when drafting their own strings, which was the real signal it had become useful rather than decorative.

I start by making sure the test is actually testing one variable, since it's easy to accidentally change tone, length, and call to action verb all in one variant and then have no idea which change drove the result. For a recent test on a subscription cancellation flow, we isolated just the framing of the retention offer, keeping button copy and layout identical, and ran it until we hit the sample size our data team calculated for statistical significance rather than peeking early. The variant that named a specific benefit the user would lose outperformed a generic 'Are you sure?' by a meaningful margin, but I also checked the downstream metric, whether users who stayed because of that message actually kept using the product a month later, because a copy trick that only delays churn isn't a real win. I care about the metric that matters past the immediate click, not just the win in the test tool itself.

I try to get into a project before wireframes are final, because copy written after layout is locked is copy fighting for space it was never given. With designers, I sketch rough content alongside their early flows so we're solving word count and information hierarchy together rather than me retrofitting sentences into boxes afterward. With researchers, I sit in on usability sessions myself rather than only reading the summary report, since tone of voice and hesitation on a specific word choice often get smoothed over in a written summary but are obvious when you watch someone read a screen out loud. I also ask researchers to include a couple of comprehension-specific questions in their test scripts, like asking a participant to explain in their own words what a screen just told them, because that surfaces confusing copy that a simple task-completion test would miss entirely.

The core job of that copy is making the consequence concrete and specific, since scary alone doesn't tell anyone what's actually at stake. 'This action cannot be undone' is true but forgettable, so I'd name exactly what disappears: saved projects, billing history, team access, whatever actually applies, so the user is deciding based on real stakes rather than a vague warning they've seen a hundred times on other products. I'd also match the friction of the confirmation to the severity of the action: a single confirm button is fine for deleting a draft, but for something as permanent as account deletion I'd want the user to type the account name or a confirmation phrase, both to slow down an impulsive click and to make sure it isn't an accidental double-tap. I'd keep the actual button label specific too, 'Delete account' rather than a generic 'Confirm', because in a moment of high stakes, ambiguity is the last thing you want between the user and an action they can't reverse.