The error message said: “Something went wrong.” Below it was an “OK” button. The user clicked OK. The thing went wrong again. There was no explanation of what had gone wrong, no indication of which action had caused the error, no suggestion for what to try next. The user opened the support chat. The support agent sent a documentation link. The documentation link described the error: “This error occurs when the request payload exceeds the maximum size of 5 MB.” That information should have been in the error message.
This is where UX writing and documentation meet: at the point where the product fails to explain itself.
UX writing is the text inside the product. Button labels, error messages, empty states, confirmation dialogs, onboarding flows, tooltips. These are the words users encounter while using the product. Their job is to guide the user through the experience without requiring them to leave the product and go find an answer somewhere else.
Documentation is what users reach for when the product’s own text doesn’t answer their question. Reference guides, tutorials, troubleshooting pages, API docs: these exist outside the product, for users who need more than the product can explain in context.
The distinction matters because the two types of writing serve users at different moments and with different levels of context. A button label has three words and needs to communicate exactly what happens next. A documentation page can take a paragraph to explain the same thing. Getting the balance wrong in either direction costs you: too-terse UX writing sends users to documentation for things that should have been self-explanatory; too-verbose in-product text clutters the interface.
But the overlap is real and significant. A well-written error message that explains what went wrong, what caused it, and what to do about it is both UX writing and documentation. It reduces support tickets. It reduces documentation lookups. It keeps the user in the product instead of sending them elsewhere. The best products do this well.
When UX writing fails — vague error messages, empty states that don’t explain what to do next, onboarding flows that skip the step that confuses everyone — documentation has to compensate. Support documentation gets written to explain what the interface should have explained. This is documentation as technical debt.
When documentation fails, support tickets absorb the cost. Support engineers answer the questions that good documentation would have answered, and good in-product text would have prevented from arising in the first place.
The practical implication: if you’re a technical writer, talk to your UX writers. If you’re a UX writer, talk to your technical writers and to your support team. The questions that land in the support queue are often a direct record of where the product text and the documentation both fell short.
UX Writing Hub is a useful resource if you’re working at this boundary and want to understand the UX writing side of the equation more deeply.