01

Think about what happens after the fix

Solving the immediate problem matters, but the same issue should not require starting from zero the next time it appears. A short record of what changed, where the settings live, and who owns the system can save a great deal of confusion later.

02

Write for the person doing the task

Documentation works best when it follows the actual steps someone needs to complete. I use plain language, specific labels, and enough context to explain why a step matters. The goal is confidence, not proving how technical the system is.

  • Name the exact device, account, or platform.
  • Put the steps in the order they will happen.
  • Explain what a successful result looks like.
  • Include who to contact when the normal steps do not work.

03

Keep the document close to the work

A perfect guide is not useful if nobody can find it. I prefer documentation that lives somewhere familiar to the team, uses a clear name, and identifies when it was last updated. That makes it easier to maintain as devices, accounts, and procedures change.

04

Pair instructions with a real explanation

Written steps are helpful, but people also benefit from seeing the process and asking questions. Training and documentation should support each other. Together, they turn a one-time repair or setup into something the team can use with less dependence on the person who first configured it.