The words in your product are part of the design. Most teams treat them as an afterthought.
UX writing is the practice of crafting every word inside a product — buttons, error messages, tooltips, empty states — to help users act with clarity and confidence.
What UX writing is — and what it isn't
UX writing is the practice of crafting every word that appears inside a product: button labels, onboarding flows, error messages, confirmation dialogs, tooltips, Empty States. It's not about brand voice or campaign copy. It's about helping users understand where they are, what they can do, and what's happening.
The discipline sits at the intersection of design and content strategy. A UX writer works directly in the product alongside designers and engineers — not after the UI is finalized. That timing matters more than most teams realize, because by the time designs are locked, the words get treated as decoration rather than structure.
UX writing vs. marketing copywriting
Marketing copy is designed to persuade. UX copy is designed to clarify. The goal isn't to sell — it's to remove friction at the moment a user needs to act.
A great headline can be provocative and ambiguous. A great button label is precise and immediate. This is why a talented marketing writer doesn't automatically translate to a product context. The instinct to make things catchy is often exactly the wrong instinct when a user is mid-task and just needs to know what the button does.
The content design practice codified by Sarah Richards at the UK Government Digital Service made this distinction mainstream: good product language is structured around user needs, not brand expression.
Where it shows up (and breaks down)
Every touchpoint in a product has words. Most of them were written by someone who wasn't thinking about users:
- Error messages: Usually written by engineers. They say things like "Error 422: Unprocessable entity." A UX writer turns that into something a user can act on.
- Onboarding flows: The language here sets expectations and determines whether users feel capable or lost on day one.
- Confirmation dialogs: The difference between a vague "Delete" and a specific "Yes, remove this permanently" is significant when something irreversible is about to happen.
- Tooltips and inline help: Short, contextual, precise — some of the hardest writing in a product to get right.
- Empty states: When there's nothing to show, what do you say? An empty screen with no guidance is a missed activation moment.
What separates good UX writing from bad
Good UX writing is clear before it's clever. It uses the language users use, not the internal vocabulary of the team that built the product. It's specific enough to act on and short enough to scan.
Bad UX writing is abstract ("An error occurred"), corporate ("Your request could not be processed at this time"), or passive when it should direct. Most teams don't realize how much of their copy falls into these patterns until they audit it.
The test is simple: can a user in the middle of a task read this and know exactly what to do next? If not, it's not done yet.
When it's worth investing in
Not every team needs a dedicated UX writer, but every product needs someone thinking about these things. If your designers are writing their own copy, check whether error messages actually describe the error, whether button labels use action verbs, and whether the onboarding flow reads like a legal document.
If your support queue is full of questions the UI should already be answering, that's a UX writing problem. It almost always costs less to fix the words than to keep answering the emails.
UX writing also compounds over time. Teams that take it seriously early build a shared vocabulary that speeds up design decisions, reduces back-and-forth in review, and makes the product feel coherent at scale rather than assembled from parts.