cognitive psychology
Curse of knowledge
What is the curse of knowledge?
The curse of knowledge is the difficulty experts have imagining what it's like not to know what they know. Once something is obvious to you, you can't easily un-see it, so you overestimate how clear your explanations are and skip the very steps and terms a beginner needs - because to you they go without saying.
Also known as: curse of knowledge, expert blind spot, curse of expertise
Prefer to watch?
Watch the recap 0:53
The demo
You've never used this app before. Here's the setup instruction its engineer wrote. Try to actually follow it - tap any word you'd get stuck on. Then see it rewritten for someone like you.
What this demo shows (text version)
The same setup instruction is shown two ways. The version "as the expert wrote it" is full of unexplained jargon and skips steps that feel obvious to someone who already knows the system - and you, cast as a first-time user, can tap the words that stop you, revealing how many there are. The "rewritten for a newcomer" version uses plain language, defines terms and includes the skipped steps, and suddenly the task is followable.
That gap is the curse of knowledge: the expert genuinely couldn't feel which parts were unclear, because their own knowledge filled the blanks automatically. Since you can't reliably simulate not-knowing from the inside, the fix is external - test with real newcomers, write in plain language, and treat your own sense of "this is obvious" as unreliable.
When you know something well, you lose the ability to feel how confusing it is to a newcomer. So experts write jargon-filled instructions, label buttons with insider terms, and skip "obvious" steps that aren't obvious to anyone else. This is why the people who build a product are the worst judges of whether it's understandable - the knowledge that makes them competent also blinds them to the gaps. The cure isn't trying harder to be clear; it's testing with real, uninformed users and writing in their words, because you cannot reliably simulate not-knowing from the inside.
The expert version felt perfectly clear - to you, because you already know the words. Drop into a beginner's shoes and it falls apart: undefined jargon, skipped steps, assumed context. That's the curse of knowledge. You can't reliably feel a newcomer's confusion from the inside, which is exactly why the only real fix is to watch actual newcomers try, and write for them.
The curse is that knowledge can't be switched off. Once you know how something works, that knowledge contaminates your judgement of how hard it is to grasp, so you assume others share context they don't. The famous "tappers and listeners" study captures it: people tapping a well-known tune wildly overestimate how recognisable their tapping is, because they hear the full song in their head while the listener hears only knocks.
In product work it produces jargon-laden copy, interfaces labelled in internal language, onboarding that skips "obvious" steps, error messages that assume technical context, and documentation pitched over users' heads. The team's fluency is exactly what hides these gaps from them - they read their own words and fill the blanks automatically, so the writing seems clearer than it is.
Because you can't reliably simulate ignorance, the fixes are external: usability-test with people who don't already know, use plain language and define terms, draw vocabulary from real user research rather than the org chart, and have someone outside the project read things cold. Treat your own sense of "this is obvious" as unreliable evidence - it's the symptom, not the test.