We have seen a lot of process documentation. Some of it is excellent. Most of it is a 40-page PDF that lives in a shared drive folder called 'Operations' and has not been opened since the month it was created. The problem is almost never the content. It is the format.
The document is written for the person who wrote it, not the person who needs it ¶
Most process documentation is written by someone who already knows the process. That person includes context that makes sense to them and skips context that feels obvious. The result is a document that is useful to the author and confusing to everyone else. Before you write anything, identify the specific person who will use this document and what they will need to do with it. Write for them, not for yourself.
It tries to cover everything at once ¶
A document that covers an entire workflow from intake to delivery in one go is almost always too long to be useful. Break it up. One document per process, or even one document per role within a process. Short documents get read. Long documents get filed. If you need a comprehensive reference, build it as a set of linked short documents, not a single monolith.
Nobody owns it after it is written ¶
Documentation goes out of date the moment the process changes. If nobody is responsible for updating it, it will be wrong within a few months and people will stop trusting it. Every document needs an owner: one named person whose job it is to keep it current. That person does not have to update it alone, but they have to notice when it needs updating and make sure it happens.
The format does not match how people work ¶
A PDF is a bad format for process documentation. It cannot be searched easily, it cannot be updated without replacing the whole file, and it does not link to anything. Use whatever tool your team already checks daily. If your team lives in Notion, write it in Notion. If they use Confluence, use Confluence. The best documentation is the documentation that is one click away from where the work happens.
There is no summary at the front ¶
Put the most important information on the first page. A one-page overview of the process: the steps, the owners, the key decision points. Everything else goes behind it. People will read the summary every time. They will read the detail when they need it. Design for that reality, not for the ideal reader who reads everything from start to finish.
If your documentation keeps failing, the answer is probably not to write more of it. It is to write less, more clearly, in the right place. If you want help with that, the documentation sprint is a good place to start. See what we deliver for more on how that works.