Your How-To Note Was Written by the One Person Who Doesn't Need It

A how-to note is usually written by the one person who no longer needs it. The author cannot un-know the steps, and neither rereading nor imagining a beginner brings the gaps back into view. What does is watching a few real readers follow the note aloud — one at a time, fixing it between sessions.

On 11 October 2026, the developer Terence Eden published a cheap version of that test. To check the install guide for his open-source project ActivityBot, he wrote, "I was prepared to pay them €25 for an hour of their time." Volunteers shared their screens and talked while they worked. His bill, in his words: "In total, I paid out around €150" — about six hour-long sessions, by his own figures.¹

Eden's note was a README. The problem he named is not specific to software. Any note that says do this, then this — restore the backup, renew the domain, reset the router — was written by someone who already knew the answer.

Why does a how-to note feel finished when you write it?

Because it is finished — for its author. Every step on the page matches a step you remember doing, so rereading confirms the note instead of testing it. The usual fix is to reread it later with fresh eyes, or to rehearse the steps yourself. That fix is sensible. It simply runs the test on the one reader guaranteed to pass.

Eden had already given developers the rehearsal advice: spin up a fresh machine and follow your own README. Then he named its limit. "But it is really hard to ignore your own biases. Of course you know that certain commands require sudo and obviously when you wrote -foo you meant --foo and everyone knows that you have to reboot afterwards."¹

Rereading is a memory test, and you wrote the answers.

A household note fails the same way. Restore from the backup drive is a complete sentence to its author. You know the drive is the grey one and its password lives in the password manager. You know the restore wizard asks one question you always answer no. None of that is on the page. All of it is in your head, where the note's next reader cannot reach it.

Why can't the author see what is missing?

Because knowing something changes what you can imagine not knowing. In 1989 the economists Colin Camerer, George Loewenstein and Martin Weber measured the effect and named it the curse of knowledge — a term they credit to Robin Hogarth. Their better-informed subjects could not set what they knew aside, even when doing so paid.

The paper's abstract states the finding plainly: "Better-informed agents are unable to ignore private information even when it is in their interest to do so; more information is not always better." A footnote on the term itself reads: "This term was suggested by Robin Hogarth."²

Paying people for accuracy did not fix it. In the authors' words, "incentives and feedback do not reduce the bias, but market forces do." Comparing individual judgments with judgments made in experimental markets, they found "that market forces reduce the curse by approximately 50 percent but do not eliminate it."²

Halved, under market pressure. Not gone.

The same mechanism turns up wherever experts write for people who are not experts. A 2026 paper in Patient Education and Counseling by Tsuyoshi Okuhara, Emi Furukawa and Hiroko Okada asks why patient leaflets stay hard to read. It is a critical interpretive synthesis — a re-reading of existing studies, not a new experiment. One of the patterns it names is "the invisibility of tacit knowledge in procedural guidance."³

That phrase describes a how-to note exactly. Tacit knowledge is the step you do without noticing — which drive, which button, which warning to ignore. It is invisible to the writer for the same reason it is essential to the reader.

Why doesn't imagining a beginner fix it?

Because the imagined beginner is built from the expert's own knowledge. In two studies, the researcher Pamela Hinds found that people with more expertise were worse at predicting how long novices would take. Their predictions resisted methods designed to correct the error. The simulation inherits the bias it is meant to remove.

In Hinds's first study, experts, intermediate users and novices predicted how long novices would need for a complex task. In the second, she manipulated expertise experimentally. The result held in both: "In both studies, those with more expertise were worse predictors of novice performance times and were resistant to debiasing techniques intended to reduce underestimation."⁴

One detail is useful. The abstract adds that "those with an intermediate level of expertise may be more accurate in predicting novices' performance."⁴

If you must guess, a half-expert may guess better than you do.

The standard advice — read it as if you knew nothing — asks the author to run a simulation that the research says the author runs badly. That is not an argument against explaining things simply.

The Feynman Technique asks you to explain a concept in plain language and mark the sentence you cannot finish. It is a sound test of your own understanding, and you can run it alone. A how-to note needs a second test: whether someone else can carry out the steps. That one needs a second person.

What does watching someone follow the note reveal?

Mostly things the author could never have listed in advance. A reader who thinks aloud shows where they hesitate, what they misread and which step they assumed was optional. Eden's sessions found a broken link, a missing explanation, a confusing order and a section that interested only him — gaps no amount of rereading had caught.

His method fits in one sentence: "I asked the volunteer to share their screen and, crucially, to speak aloud."¹ Among the findings he listed:

• "The link to the demo tool was wrong."
• "How do you rename a hidden file?"
• "The ordering of the different sections was confusing."
• "I hadn't actually explained what the software would do."
• "A whole section which was technically interesting to me was utterly confusing to everyone else."

Read that list as someone who keeps notes. A wrong link. An unexplained step. The right steps in the wrong order. No sentence saying what the procedure is for. Each is ordinary in a personal how-to, and each is invisible to its author, who never needs the link, the step, the order or the purpose.

The technique has a name in usability research: thinking aloud. Jakob Nielsen of the Nielsen Norman Group describes how little it takes: "To run a basic thinking aloud usability study, you need to do only 3 things: Recruit representative users. Give them representative tasks to perform. Shut up and let the users do the talking."⁵

He is also forgiving about technique: "unless you blatantly bias users by putting words into their mouths, you'll still get reasonably good findings, even from a poorly run study."⁵ Think-aloud protocols have a long history in writing research too, a thread picked up in Writing Is the Best Thinking Tool Ever Invented.

How many readers does a note need?

More than one, fewer than you fear, and never all at once. Nielsen's model says a single tester surfaces about 31% of usability problems — but only among comparable users, and he warns against relying on one person. The pattern that works is a few readers in sequence, with the note fixed between each session.

The model behind the number comes from Nielsen and Thomas Landauer's 1993 paper, which found that across 11 studies, problem-finding "is well modeled as a Poisson process."⁶ Nielsen's later article puts a figure on a single tester's share: "The typical value of L is 31%, averaged across a large number of projects we studied." The headline of the curve is simpler still: "zero users give zero insights."⁷

Then come the caveats, and they matter for notes. "The formula only holds for comparable users who will be using the site in fairly similar ways."⁷ Your partner, your parent and your colleague are not comparable users. Read 31% as an engineering heuristic, not a forecast for your household.

Nielsen also argues against stopping at one. "There is always a risk of being misled by the spurious behavior of a single person who may perform certain actions by accident or in an unrepresentative manner." His alternative is modest: "Even 3 users are enough to get an idea of the diversity in user behavior and insight into what's unique and what can be generalized."⁷

The familiar rule that five users are enough deserves its counter-evidence. Laura Faulkner tested 60 users and sampled random groups from them. "Some of the randomly selected sets of 5 participants found 99% of the problems; other sets found only 55%." Larger groups narrowed the spread: "With 10 users, the lowest percentage of problems revealed by any one set was increased to 80%, and with 20 users, to 95%."⁸

One reader is far better than none. It is not the same as enough.

A household note will never get 20 readers, and it does not need them. Nielsen's own recommendation is iterative: test small, fix, test again, "running as many small tests as you can afford."⁷ Eden did exactly that: "After each session I updated the README based on what people found difficult, then I re-tested it with the next person."¹ Each fix clears the way for the next reader to find something new.

Can an AI follow the note instead?

It can do part of the job. A language model can attempt the steps or answer questions from the note, and some developers report that this catches instructions that cannot be carried out. What it cannot give you is a particular person's hesitation. We found no measured comparison of AI and human testers of written instructions.

Eden saw the question coming. "I know someone is going to say "why not just ask an LLM to simulate a range of users?" The answer is very simple - I want to speak to real people." Part of his reason came from his time doing technical writing for GOV.UK, where another person reviewed his drafts: "I could hear the frustration in their voice - that's the thing which lets you know a mistake needs to be corrected."¹

The fair counterpoint came from a reader of the Hacker News discussion. An agent, the commenter wrote, "will tell you if your instructions can be followed or not - which was the main thing the author wanted to test against".⁹

Both are right, about different things. Executability is checkable by machine. Frustration is heard by a person.

Even the curse-of-knowledge synthesis splits the work. Okuhara and colleagues recommend "institutionalizing patient and public involvement (PPI) as an external cognitive audit that surfaces experts' implicit assumptions" — and, separately, "leveraging AI as a cognitive bridge to retranslate specialized knowledge into lay-accessible frameworks."³

A sensible order follows: a machine pass for steps that cannot run, then a human reader for steps that cannot be understood. One caution applies to household notes. An emergency note is the last document to paste into a third-party service.

What does this look like for a household note?

Pick the note someone else will need when you are not there to explain it — the backup restore, the domain renewal, the page for a hospital stay. Hand it to the person who would actually use it and watch them run a safe version of the task. Their questions are your edits.

What belongs in that kind of note — the inventory, the contacts, why live passwords stay off the page — is covered in The Digital Legacy Notebook. This piece is about something that post leaves open: whether its reader can follow it. As with that post, nothing here is legal advice.

Choose the reader by Nielsen's first rule — a representative user. For a note written for your partner, your partner is the representative user. A tech-savvy friend will sail past the steps your partner would stop at.

Make the task safe to fail. Restore one file to a new folder rather than the whole drive. For the access plan, test whether the reader can find where the emergency access is set up, not whether they can open anything. A rehearsal should never touch a live secret.

Family members get nervous when they are watched. GOV.UK's service manual has the right instruction for the start of a session: "let them know that you’re testing the service, not them - reassure them that they are not being judged or assessed".¹⁰

The note is on trial. The reader is not.

A protocol to run this week

Choose one note, one reader and one safe task. Ask the reader to follow the note aloud while you stay quiet and write down every pause, question and wrong turn. Fix the note before the next session, then repeat with a different reader. Stop when a session finds nothing new.

1. Pick the note and a safe task. Plan for under an hour — GOV.UK puts a usability session at "between 30 and 60 minutes."¹⁰
2. Choose a reader who matches the note's real reader. Not the most capable person you know; the one who would actually be holding the note.
3. Set the rules out loud. They talk as they go; the note is being tested, not them.
4. Stay quiet and take notes. GOV.UK's advice is to "try to stay quiet - mostly just watch and listen", and to "help the participant get back on track if they get completely stuck".¹⁰ Every point where you had to help is a missing sentence.
5. Fix, then test with the next reader. Edit the note the same day, then hand the new version to someone else.

Date the note when it passes. A note that passed last year was tested against last year's router.

Frequently asked questions

How do I test my written instructions?

Give them to someone who matches the intended reader and ask them to carry out the task while thinking aloud. Stay quiet, note every pause or misreading, and help only if they are completely stuck. Fix the instructions, then repeat with a different reader. Nielsen's think-aloud method needs only representative users, representative tasks and an observer who stays silent.

Why can't anyone follow my instructions?

Usually because the instructions rely on knowledge only you have. Camerer, Loewenstein and Weber called this the curse of knowledge: better-informed people cannot set aside what they know, even when it pays to. The missing pieces are the steps you do without noticing — a password location, a hidden file, a reboot — so rereading your own text will not reveal them.

What is the curse of knowledge in writing instructions?

It is the difficulty an expert has imagining what it is like not to know something. Measured by Camerer, Loewenstein and Weber in 1989, it shows up in instructions as skipped steps, unexplained terms and a missing statement of purpose. Pamela Hinds found experts underestimate how long novices need and resist techniques meant to correct this.

Who coined the term curse of knowledge?

The term entered the research literature through Colin Camerer, George Loewenstein and Martin Weber's 1989 paper in the Journal of Political Economy. A footnote in that paper credits the name itself to another researcher: "This term was suggested by Robin Hogarth." Credit the measured effect to the three authors and the term to Hogarth.

How many people do you need to test documentation?

More than one, tested in sequence. Nielsen's model has one tester finding about 31% of problems among comparable users, and he warns against relying on a single person. Faulkner found random groups of five finding as little as 55% of problems. For personal notes, test with a few readers and fix the note between each session.

Why not just ask an LLM to simulate a range of users?

An AI can check whether steps can be followed, and some developers use it to find gaps. Terence Eden, who paid volunteers to test his README, gave his reason for using people instead: "I want to speak to real people." A person shows you hesitation and frustration. No measured comparison of AI and human testers of instructions was found.

The author is the one reader a how-to note can never fail. Test it on the others.

mnmnote.com keeps notes as plain Markdown files on your own device, so the version your reader marked up is a file you can print, hand over or open in any text editor.