You explain the thing. It does not land. You try again from a different direction. Still not quite. Then you say something — an analogy, a reframing, an example — and you see it arrive.
That third explanation is the valuable one. It took two failures to find, it is genuinely better than the one in the documentation, and by Friday it is gone. Next time you will start from the first explanation again, because that is the one that comes to mind.
Nobody writes these down, and they are among the cheapest and most reusable things anyone produces.
What to capture
Not the explanation — the third explanation, plus the two that failed.
The version that worked. In the words you used, not tidied up. The rough spoken version is the one that works; the written-up version is usually the documentation you already had.
What they misunderstood first. This is more valuable than the explanation itself, because it is a fact about how people encounter the topic. If three people make the same wrong assumption, the assumption is predictable and your explanation should start there.
The question they asked that you had not anticipated. Every subject has a small set of questions that arise reliably and appear in no documentation, because whoever wrote it had forgotten the question was askable.
The analogy, if there was one. Analogies are expensive to invent and cheap to reuse, and a good one is often the entire explanation.
The curse you are trying to work around
There is a specific reason this is hard, and knowing it helps.
Once you understand something, you lose reliable access to what it was like not to. The gap that needed bridging becomes invisible; the explanation that seems natural to you is one that only works for someone who already has most of the picture. This is why experts routinely explain things badly and are surprised by it.
You cannot fix that by trying harder to remember what confusion felt like. You can fix it by writing down, at the moment you observe it, what a specific person actually misunderstood. That record survives your own forgetting, and it is the only thing that does.
Which means the notes are most valuable when written by someone who has just learned it — the same window that makes the first ninety days at a job worth documenting, for exactly the same reason.
One note per thing you explain
Growing over time. Not a document you write, a note you add to.
Each time you explain the topic, add a line: who, what they misunderstood, what worked. After six or seven, the note contains something no first-draft document ever does — a map of how people actually get lost, ordered by frequency.
That is the point at which it is worth turning into real documentation, and the resulting document is dramatically better than one written from scratch, because it is organised around the misunderstandings rather than around the structure of the subject. Most bad documentation is bad because it is organised the second way.
Where teaching and onboarding are the same job
The pattern is identical whether you are teaching a class, onboarding a colleague, supporting customers, or answering the same question in a forum for the fourth time.
Something recurs. The same topic, the same confusion, more than twice.
The explanation improves with iteration, and the improvement is lost without a record.
The audience does not know what they do not know, so their questions are the only reliable signal about where the gaps are.
If you support people, the support queue is the best documentation backlog in existence and almost nobody treats it as one. The questions asked most often are the topics your documentation covers worst, in exactly that order, and that ranking is free.
Note the wrong answers too
An under-used move: write down the plausible-but-wrong understanding.
If everyone assumes the setting applies globally when it applies per-document, that specific wrong belief is worth recording, because your explanation should address it directly rather than describing the correct behaviour and hoping the contradiction is noticed. "It looks like it applies to everything — it does not, it is per document" corrects an existing model. "It applies per document" gets read straight past by someone who already believes otherwise.
Correcting a wrong model is a different job from describing a right one, and only the notes tell you which model people arrive with.
The reuse is the payoff
Where this pays back, concretely.
The written version. When you finally write the documentation, the note is the outline and the hard part is done.
The next person. Onboarding someone means re-explaining everything you explained last year, and the note is the difference between doing it well and doing it from scratch.
Your own understanding. Teaching something is the standard test of whether you understand it, and the record of your explanations is a record of your understanding improving — visible in a way that is otherwise entirely internal.
A talk, a post, a course. Almost all good explanatory writing is downstream of having explained the thing out loud several times to people who did not get it. The notes are the raw material and they accumulate whether or not you ever use them.
The honest version
This is a habit with no payoff for months. The first three notes feel pointless because there is no pattern yet, and the value is entirely in the sixth reading, which is a long way off.
If you explain the same things repeatedly — teaching, support, onboarding, management — it is one of the highest-return notes available, and it costs a line after a conversation you were having anyway.
Cyanote suits it because the note grows rather than being written: one note per topic, appended to each time, nesting into sub-pages when a topic gets big, [[ links tying an explanation to the system it is about, and ⇧⌘F finding "what was the analogy I used for this" a year later. It is one local database on your own Mac — which for explanations you developed and will take to the next job is where they should be, rather than in a wiki you lose access to.