Curse of Knowledge
Once you know how something works you cannot accurately imagine not knowing, which is why teams misjudge their own interfaces.
Definition
A bias in which better-informed people find it difficult to reason about a problem from the perspective of a less-informed person. Camerer, Loewenstein and Weber demonstrated it economically in 1989; Newton's 1990 tapping study is the best-known illustration.
Established research. Originates in published research and has been replicated. The effect is real. Its size in your product still needs measuring.
On this plate
Reach for this when
- Reviewing your own product for clarity.
- Writing documentation or onboarding.
- Deciding whether research is needed.
- Reviewing copy, naming or documentation written by the people who built the thing.
Common mistakes
- Treating team consensus as evidence.
- Testing only with people already familiar with the domain.
- Explaining away observed failures as participant error.
Why internal review is not usability testing
A team that built the product cannot evaluate its learnability. They know the vocabulary, the model and the location of everything, and that knowledge cannot be suspended by intending to. Confidence that something is obvious is not evidence that it is.
This is the strongest single argument for testing with five people who have never seen the product, and for treating any internal claim that a label is clear as a hypothesis rather than a finding.
Countermeasures
- Test with people outside the team, however informally.
- Watch a new user's first five minutes without helping them.
- Read support tickets and search logs directly, not summarised.
- Have someone unfamiliar with the domain review the copy.
- Ban internal vocabulary from user-facing text unless research shows users use it.
Where it shows up, and the cheapest countermeasure
| Symptom | Countermeasure |
|---|---|
| Labels that use the internal noun | Read every label aloud to someone outside the team |
| Documentation that starts at step three | Have a new joiner follow it exactly, changing nothing |
| An error message that assumes the cause is obvious | Write it as though the reader has never seen the product |
| Confidence that a control is discoverable | Five minutes of watching one person look for it |
| Onboarding that explains the model, not the task | Test with someone who does not yet want the product |
In practice
- i.
The obvious button nobody found
Usability testingTeams routinely watch participants fail to find a control the team considers unmissable. The reaction is usually disbelief, which is the bias operating in real time.
- ii.
Missing first steps in documentation
Developer docsSetup guides commonly omit a prerequisite the author has had installed for years. New users stall at step zero, and the fix is a literal walkthrough by someone starting clean.
- iii.
The step that was missing from the guide
DocumentationEvery instruction assumed the project had already been created, because everyone who wrote them had one. The first sentence for a new reader was a dead end, and no internal review caught it for a year.
Local chart
BIAS·008 · Region I · Grid A1
This entry and the entries it is stated to connect with. Each line is labelled with what the connection means.
Sources
Where a source establishes something narrower than the popular reading of it, the note says so.
- [1]
The curse of knowledge in economic settings: an experimental analysis
C. Camerer, G. Loewenstein and M. Weber, Journal of Political Economy, 1989
- [2]
The rocky road from actions to intentions
E. Newton, Stanford University doctoral dissertation, 1990
The tappers and listeners study.
Continue from here
Each link says what the connection is, so you can tell a principle from an alternative from a thing people mix this up with.
Explains
The mechanism underneath these entries.
- Help and DocumentationHEUR·010 · Heuristic
- Match Between System and the Real WorldHEUR·002 · Heuristic
Why this works
The reasoning this entry rests on.
- Usability TestingRES·001 · Research method
Testing exists because you cannot un-know your own interface.
Applied through
Where this shows up as a concrete interface decision.
- Screenshot to UX AuditAI·001 · AI workflow
- Guerrilla TestingRES·016 · Research method
- Heuristic EvaluationRES·002 · Research method
- MicrocopyWRT·001 · UX writing
- Design CritiqueFLOW·001 · Workflow
Often used with
These usually appear in the same screen or the same decision.
- Design CritiqueTPL·012 · Template
- Usability Test ScriptTPL·007 · Template
Practical example
A worked decision where this was the deciding factor.
- Fixing a Search That Returned NothingCASE·006 · Case study
Short definition
The one-paragraph version, for when that is all you need.
- Design CritiqueTERM·111 · Term
Related concept
Connected closely enough to change how you apply this.
- Confirmation BiasBIAS·009 · Cognitive bias
- Mental ModelsMOD·001 · Mental model
- Paradox of the Active UserPSY·007 · Psychology