Documentation should describe what the product actually does. Test procedures wherever reasonably possible. A guide should not rest on instructions that merely sound plausible or that appeared in an older version of the docs.
Accuracy includes currency. A procedure can be technically correct for an older version and still be the wrong documentation today.
Every draft ships with a verification list
Each procedural claim on the page is tagged as one of:
- Tested. Someone followed the steps and got the stated result.
- Confirmed. The product team stated it, and we have that in writing.
- Unverified. Neither of the above.
No page is published with an unverified claim still on the list. Either it gets tested, it gets confirmed, or it comes out of the page.
A claim that sounds plausible, appears in older documentation, or was inferred from the interface without being run is unverified. So is anything a writing tool produced that nobody has checked.
Treat product changes as documentation changes
A product update rarely affects only one sentence. When a feature changes, review the full affected page and everything related to it. Do not assume that fixing the visibly changed instruction completes the work.
| Impact check |
|---|
| Has the workflow changed? |
| Has navigation changed? |
| Have settings, defaults, labels or permissions changed? |
| Have prerequisites changed? |
| Are screenshots still current? |
| Do warnings and edge cases still apply? |
| Does troubleshooting still match the product? |
| Have related how-to guides changed? |
| Have reference entries changed? |
| Do internal links still point to the best destination? |
| Does terminology still match the current product? |
| Does any version-specific documentation now need updating? |
