Good documentation is written for the moment someone is stuck, not for the moment someone is writing it. I work from the assumption that the reader is capable but busy — so the goal is always the shortest path to clarity. Plain language, logical steps, and enough context to be genuinely useful without being exhausting to read.
In practice that means testing the logic of a process before writing a single word about it. If the steps don’t hold up under scrutiny, no amount of clear writing will fix that. The documentation and the process improve together.