How to evaluate a UX writer
By Sergio Gualda · 10 min read · Updated
Evaluate a UX writer on whether they fix the interface or just the sentence: whether they flag the broken flow behind a confusing message, how they handle a destructive action, what they do with a legal constraint they can't remove, and how they decide what not to say. A writing sample shows the final line. It never shows what the screen looked like before, or what they refused to paper over.
The request that reveals everything
“The error message is confusing. Can you make it friendlier?” It's the most common request a UX writer receives, and it's almost always the wrong one.
A confusing error message is usually a symptom. The flow asked for something impossible, or failed silently three steps earlier, or is reporting a problem the user can't act on. Rewriting the sentence makes the symptom pleasant and leaves the cause.
Give them that request, with enough context to see the flow, and watch whether they reach for the sentence or for the screen.
Destructive actions
Ask them to write the confirmation for permanently deleting something with no undo. It's a small brief that contains most of the craft.
Weak versions are either jokey, which is a catastrophe on an irreversible action, or so hedged that the user can't tell what will happen. Strong versions name exactly what disappears, say whether it can be recovered, and put the consequence in the button rather than in the paragraph nobody reads.
The constraint they can't remove
Every product has sentences that legal or compliance won't let you change. Give them one, badly worded and mandatory, and ask what they'd do.
Fighting it fails, and so does giving up. The good answer works around it: put the required wording where it's legally sufficient, and carry the meaning in the parts of the screen that are free, such as the heading, the button and the microcopy underneath.
Reader or brand?
Ask for a time the brand voice was wrong for the moment.
Every product has states where playfulness reads as contempt: a failed payment, a lost draft, a locked account. A UX writer who has never overridden the voice guide either hasn't been in those moments or wasn't allowed to be. You'll want to know which before you hire them.
What they decide not to say
Show them a screen with too much copy and ask what comes out.
This is the skill that separates the role from editing. Weak answers tighten every sentence, and the screen ends up shorter and just as busy.
Strong answers delete a whole element and can say why it was doing no work. It might be a label that repeats the heading, helper text for a field that should have been self-evident, or a reassurance nobody asked for.
Why this role is the hardest one to hire badly and notice
A weak engineer produces bugs. A weak designer produces screens someone will question. A weak UX writer produces copy that reads fine and slowly costs you conversions, support tickets and trust, and nobody on the team can point at the sentence responsible.
That invisibility cuts both ways in hiring. It's very easy to hire a writer whose portfolio reads beautifully and who can't work inside a system, and just as easy to reject one whose samples look plain because the product they worked on demanded plain.
So the evaluation has to target the decisions rather than the prose. Good product writing often looks like nothing at all, so judging it on how it reads comes close to judging it backwards.
The exercise that works, and it takes fifteen minutes
Take a real screen from your product. Strip nothing, fix nothing. Give it to the candidate with three pieces of context: who is on this screen, what they were doing immediately before, and what the business needs to happen next.
Then ask for two things: what they'd change, and what they'd choose to leave alone. The second half matters more, and almost nobody asks for it.
A weak candidate rewrites everything, because rewriting is the demonstration they think you want. A strong one changes two or three things, leaves the rest, and can tell you why each untouched line is already doing its job.
That restraint is the skill, and fifteen minutes on a live screen surfaces it more reliably than any portfolio review.
Run it identically for every candidate. You're running it to compare, and the moment you customise the screen for someone senior you've lost the comparison.
Five signals in what they hand back
Ordered by how much they predict, from what teams report after hiring.
- They asked a question before writing. What happens if this fails? What's the longest realistic string here? Who else writes in this product? A writer who starts producing copy without asking anything will do the same on your team.
- They wrote for the state that goes wrong as well as the happy path: empty, loading, error, permission denied. This is where product writing earns its salary and where most portfolios have nothing.
- They kept a constraint they weren't allowed to remove. If the legal line has to stay, does their solution work with it there, or does it assume it's gone?
- They noticed a conflict between what the reader needs and what the business wants, and named it instead of resolving it silently in the brand's favour. Naming it is the senior move.
- They can defend a deletion. Anyone can add a helpful sentence. Knowing which existing sentence is doing nothing, and being able to say why, is much rarer.
What to ignore, which is most of what gets presented
Three things look like evidence of a good UX writer and aren't.
Portfolio polish. A content designer's portfolio is a marketing artefact about a person who writes marketing artefacts for a living, and since 2024 it can also be generated end to end. It tells you they can present. It doesn't tell you they can work inside a design system with a legal team attached.
Voice and tone documents. Everyone has one, and they all use the same six adjectives. Writing one is easy; holding it across four hundred strings written by six people is hard. Ask how they enforced it.
Awards and long-form writing samples. Both show writing ability, which matters but isn't the constraint. The constraint is judgment about what to say inside forty characters when the developer is waiting.
Do you need a UX writer or a content designer?
Most companies use the titles interchangeably and a few mean different things by them. The difference matters when you write the job ad.
Where they differ, a UX writer is handed the flow and makes the words work. A content designer is expected to argue about the flow, to say that this screen shouldn't exist or the sequence is wrong, and to change the structure rather than the sentence.
The settling question is the same one that separates UX from product design: when the flow is wrong, is this person expected to say so?
If yes, you need someone who will push back on structure, and you should assess for that argument rather than for prose quality. If no, you're hiring for craft inside constraints, and the exercise above is most of what you need.
Frequently asked
- Can a product designer do the writing?
- Often, up to a point. A dedicated writer adds two things: noticing that a confusing screen is a broken flow rather than a wording problem, and having the standing to say so. If your designers are shipping copy nobody reviews, you don't have a writing problem yet. You will.
- Should I ask for a portfolio or a writing test?
- A portfolio shows final sentences, which is the least informative part. If you run an exercise, give them a screen from your product with a problem in it and ask what they'd change, including what they'd remove and what they'd escalate rather than write around.
- How do you judge writing if you're not a writer?
- Read the button. It's the hardest thing on the screen to get right and the easiest to judge: does it say what happens when you press it? Everything else about a writer's judgment shows up in that one string.
- Should a UX writing test be paid?
- If it uses a screen from your product and takes under twenty minutes, no. It's short and produces nothing you can ship. If it takes an afternoon, or if you'd use what comes back, pay for it. What decides it is whether you're getting work out of it.
- How do I evaluate a UX writer without one on the team?
- Weight the reasoning over the prose. You can't reliably judge whether a microcopy line is well made, but you can judge whether someone's explanation of a trade-off is sound, because that's a general skill. Ask them to explain each change and each line they chose not to change, and score the explanations.
- Is UX writing being replaced by AI?
- The drafting is, largely. Producing forty variants of a button label is now free. Deciding which variant is right for this reader, in this state, under this legal constraint didn't become free, and neither did noticing that the screen is asking the wrong question in the first place. That was always the job, and now it's more visibly the job.