Your help center is lying, and everybody knows it
Documentation drift is the silent tax on every software company. Here is how to measure it, and why the fix is structural rather than editorial.
Pick a random article from your help center. Open your product beside it. Follow the steps exactly as written.
In our experience of doing this with customers, roughly one article in three fails within the first four steps. A button has moved, a label has changed, a screen has an extra confirmation dialog that was not there when the article was written. Nothing is catastrophically wrong. It is just slightly, consistently untrue.
Drift is a rate, not an event
Documentation does not become wrong all at once. It decays at a rate that is a function of two things: how fast your product changes, and how expensive it is to update a document.
Most teams try to solve this on the first term — freeze the UI, batch the changes, coordinate release notes with the docs team. This never works for long, because shipping less is a bad solution to any problem.
The second term is the one you can actually move. If updating an article costs forty minutes of a technical writer's time, you will update the ones that generate tickets and leave the rest. If it costs ninety seconds, you will update everything.
A number worth calculating
Take the number of customer-visible changes you shipped last quarter, multiply by the number of articles each one touched, and multiply by your cost to update an article. That is your drift debt. Most teams have never computed it.
Screenshots are the expensive part
Text is cheap to update. A writer can fix a sentence in seconds. Screenshots are what make documentation expensive, because updating one means opening the product, reproducing the state, capturing the frame, cropping it, annotating it, redacting anything sensitive and re-uploading.
This is why so many help centers have accurate text sitting above an out-of-date image — the writer updated what was cheap and skipped what was not. Customers notice this immediately, and it is worse than having no screenshot at all, because it actively misleads.
The structural fix
The fix is to stop treating documentation as a document and start treating it as a derived artifact. If the article is generated from a recording of the flow, then updating the article means re-recording the flow — which takes ninety seconds and produces correct text, correct screenshots and correct annotations simultaneously.
This is a different mental model than most documentation tooling assumes. It means your source of truth is a capture, not a page. It means diffs happen at the level of the flow rather than the paragraph. And it means the video and the article cannot contradict each other, because they came from the same take.
What changes when the cost drops
- You document the edge cases, because documenting them is no longer a project.
- You localize, because localization is a derived operation rather than a vendor engagement.
- You update after every release rather than every quarter.
- Support stops writing shadow documentation in macros because the real documentation is current.
- Product starts reading the analytics on your guides, because they turn out to be a good signal about which parts of the product are confusing.
That last one is the underrated effect. When documentation is current, the places where people get stuck reading it are a reliable map of the places where they get stuck using the product. Stale documentation cannot tell you that, because you can never separate confusion about the product from confusion caused by the document being wrong.