Cora Byrne · Founder, The Ór Standard · April 2026
The documentation debt that no one is counting
Technical teams track code debt. They don't track documentation debt; they should.
Code debt is the cost of shortcuts taken now that increase the cost of change later. Documentation debt works the same way however, it accumulates invisibly. It's visible in support tickets answered manually instead of by documentation, in onboarding sessions repeated because the getting-started guide doesn't exist, in integration failures that are caused by API reference documentation that describes the endpoint as it was designed instead of how it currently behaves.
How is documentation debt invisible? It's crafty. Documentation debt hides so well because it's paid in other people's time. The engineer answers the Slack message, the customer success manager walks the new client through the setup, the developer advocate runs the webinar that explains what the documentation should have covered. None of these costs appear on the documentation line of the budget. They appear on the engineering line, the success line, and the marketing line; distributed and therefore uncounted.
Documentation debt has three components:
* The first is completeness debt: the documentation that should exist but doesn't. This is the most visible component because the gaps are at least identifiable, even if they aren't filled.
* The second is accuracy debt: the documentation that exists but describes a product that no longer exists or has evolved. This is more dangerous than absence, because it creates active misinformation. A developer that follows outdated documentation fails in a way that looks like their failure, not the documentation's.
* The third is structural debt: the documentation that is complete and accurate but organised in a way that prevents or taxes users from finding it. This is the most expensive component and the least discussed, because it requires architectural thinking instead of writing effort to resolve.
Organisations typically attack completeness debt (write more docs) while ignoring accuracy debt (update existing docs) and structural debt (rebuild the architecture). This is why documentation investment frequently fails to produce the expected reduction in support load or improvement in developer experience. It addresses the visible symptom rather than the structural cause.
The Ór Standard uses a six-part audit framework to show all three problem areas at the same time. This helps focus on fixing the issue with the greatest business impact, instead of the issue that is easiest to document.
If your team is answering questions that should be answered by documentation, the documentation debt is already compounding. The question isn't whether to pay it; you're already paying it. The question is whether to pay it in engineer time, or in a structured remediation that eliminates the debt rather than services it indefinitely.
Cora Byrne is the founder of The Ór Standard, a specialist documentation systems consultancy based in the United Kingdom.
Cora Byrne · Founder, The Ór Standard · April 2026
Your documentation excludes people. I'm one of them.
I've dyslexia, I've dyscalculia, and I've dyspraxia. I'm also a Technical Author and Linguist that has spent years building documentation systems for some of the most technically demanding products in the industry. These two facts live together in me every day, and the tension between them is what drives everything I do.
This blog post exists because from my experience, documentation — technical documentation, specifically — is one of the most inaccessible forms of writing that exists, and almost nobody in the industry treats that as the systems failure it is.
Let me tell you what it's like to be a documentation specialist who struggles with the documentation that most of our industry produces.
A wall of unbroken text isn't neutral. It's a barrier. When text has no visual hierarchy, no headers that tell me where I am, no short paragraphs that give me a place to pause, and no clear signposting between concept and instruction, I lose my place. I re-read the same line. I lose my place again. I close the page because the cognitive load is too high and I need to be tactical with my time management. For someone without dyslexia, this might register as mildly annoying. For me, and for the estimated one in ten people who share this, it's the difference between being able to use a product and not being able to use it at all.
Passive voice isn't just stylistically weak. It's cognitively expensive. For example:
- "The configuration file should be modified" costs more to process than "Modify the configuration file."
That additional processing matters when your brain is already working harder to decode the letters on the page. I feel it every time I encounter documentation written in passive voice. My brain stumbles. I re-read. I lose my place. The instruction fails to land.
Inconsistent terminology isn't a minor style issue. It's a cognitive load problem. When a product calls the same thing a "workspace" in one section and a "project" in another, my brain has to hold both labels, and also decide whether they mean the same thing, and then also continue reading while carrying that uncertainty. For someone with a working memory difference that's a significant additional burden. It's one of the reasons I care so intensely about terminology governance. It's not an abstract documentation principle. It's the difference between a user who can follow a process and one who cannot.
Numbered sequences presented without structure are something that I find genuinely difficult to hold. A 12-step process written as a numbered list isn't automatically clear. The steps need to be short. Each step needs to be a single action. The numbering needs to be unambiguous. When documentation contains steps that bundle multiple actions ("Configure the environment and ensure the permissions are set correctly before proceeding"), I lose count, lose sequence, lose my place in the process. My dyspraxia affects sequencing. It affects planning. Documentation that doesn't respect sequence, that buries the order of operations inside prose paragraphs, is documentation that I can't follow reliably, regardless of how technically accurate it is.
I am telling you this not to describe a personal inconvenience but to describe a structural failure. These are not edge cases. The estimates vary by study, but something in the range of fifteen to twenty percent of the population is neurodivergent in some form. Dyslexia alone affects around ten percent. That is not a small segment of users. It is a large portion of the developers, operators, and customers that are attempting to use your product right now, failing, and either escalating to support or giving up entirely.
Here's what I know from building documentation systems for technical products: the patterns that exclude neurodivergent users are the same patterns that make documentation harder for everyone. Short sentences are clearer than long ones for every reader. Active voice is faster to process for every reader. Consistent terminology reduces cognitive load for every reader. Clear hierarchy helps every reader navigate more efficiently. Accessible documentation is better documentation. Not adapted documentation. Not documentation with an accessibility appendix.
Better documentation, for everyone who uses it.
The documentation industry has a habit of treating accessibility as a checkbox. Alt text on images... Sufficient colour contrast... A skip navigation link... These are important! They are also the absolute minimum. Cognitive accessibility rarely appears in documentation audits, style guides, or governance frameworks.
It appears in The Ór Standard's.
When I audit documentation, I look at whether the information architecture maps to how users actually think, not how the internal team has organised the product. I look at whether terminology is consistent enough to be held in working memory. I look at whether procedural documentation is broken into genuinely discrete steps. I look at whether headers communicate content rather than tease it. I look at whether the reading level is calibrated to the actual audience rather than the assumed audience. None of these are specialist accessibility considerations. They are the baseline of documentation that works.
I built The Ór Standard to raise that baseline. I did it partly because I have spent my career in a field that produces a product I often can't use myself. Without pulling punches, I find that professionally unacceptable. I also did it partly because every organisation I have worked with has the same fundamental problem: they have documentation that was never designed to be used, only to exist.
Accessible documentation is not a feature you add at the end. It is a structural property of documentation that was designed correctly from the beginning. And it begins with the architecture. This is where The Ór Standard always begins.
Cora Byrne is the founder of The Ór Standard. She is dyslexic, dyscalculic, and dyspraxic — and has built a career in documentation precisely because of what those experiences have taught her about what good documentation actually requires.
