This is so obvious, yet at the same time it seems to me that people rarely really understand what is at stake.
"Most of the breakdowns in a product don’t come from bad intentions or bad work. They come from the way teams divide responsibilities. Engineering focuses on the system behavior. Design focuses on screens and interaction. Product focuses on requirements and scope. Each group works inside its own boundary, and no one is responsible for checking whether all those boundaries line up.
That’s how you end up with a feature that technically “works,” but only if the user magically knows the right order of steps, or already understands a concept that was never explained, or follows a path that only makes sense inside one team’s mental model.
The writer is the first person who has to confront that reality. Not because we’re smarter—because documentation forces us to walk the entire experience in the same order the user will. No shortcuts. No inherited assumptions. No internal knowledge. Just: If I follow this from beginning to end, does it hold together?
That’s when the real gaps surface:
- Prerequisite steps that were never shown in the UI, but the system silently requires.
- Terminology drift where three teams named the same thing differently and nobody noticed.
- Logic branches that exist in engineering’s head, but not in the design or the workflow.
- Error states with no recovery, dropping users into dead ends no one tested.
- Hidden dependencies, like expecting users to configure something before they even have access to it.
- Contradictory steps created by teams working from different assumptions about how something is “supposed” to work.
None of these are “documentation problems.” They’re structural problems that documentation exposes because documentation is the first time anyone tries to describe the system as one connected experience."
https://brandihopkins.com/involve-writers-early/
#TechnicalWriting #SoftwareDevelopment #SoftwareDocumentation #DocsAsProduct #UX
