The best time to document a workflow is while the awkward details are still fresh. You do not need a polished tutorial to leave something useful for your future self.
Start with the outcome
Write one sentence describing what the process achieves. Add the tools, versions and starting conditions that matter. Someone reading later should be able to tell whether the note applies to their situation.
Use this template
- Problem: What were you trying to accomplish?
- Starting point: What files, access and tools did you need?
- Steps: What did you do, in order?
- Decisions: Why did you choose this approach?
- Verification: How did you know it worked?
- Recovery: What would you do if a step failed?
- Next time: What would you change?
Capture the useful evidence
A screenshot, a folder tree or a before-and-after example can explain more than a long paragraph. Remove passwords, account tokens, private client information and anything that does not belong in a public tutorial.
Separate instructions from observations
“This worked on my setup” is useful information. It is also different from a universal rule. Keep notes on the environment and unresolved questions so readers can make informed decisions.
Run it once more
Follow your own instructions from the beginning. Fill the gaps that felt obvious when you wrote them. Then date the note and revise it when the process changes.