01Overview
The curse of knowledge is the cognitive bias that makes it extremely difficult to imagine what it was like to not know something you now know. Experts are cursed by their own expertise: they can no longer simulate the experience of encountering their domain for the first time.
For designers, this is the most pervasive, invisible bias in the entire discipline. The team that built the product is the worst possible judge of whether the product is intuitive — because they cannot see it as a new user sees it. They see the model, not the map confusion.
02Detailed explanation
Elizabeth Newton's 1990 Stanford experiment is the classic demonstration. "Tappers" tapped out the rhythm of well-known songs while "listeners" tried to guess the song. Tappers predicted that listeners would correctly identify the song 50% of the time. The actual rate: 2.5%. The tappers were genuinely surprised — they could "hear" the full melody in their heads while tapping, and couldn't understand why listeners couldn't reconstruct it from the taps alone.
- The effect scales with expertise: the more deeply someone knows a subject, the harder it becomes to remember the mental state of not-knowing it.
- In product teams, it manifests as confidence that features are "obvious" when user testing shows they're opaque; as help copy that uses jargon the writer no longer recognises as jargon; as onboarding flows that skip steps that seem "too basic to explain."
- It is distinct from arrogance — it's an honest failure of imagination. Experts genuinely cannot introspect their way to beginner-level understanding.
03Why it exists
When knowledge becomes automatic and procedural (through repeated use), the brain stops consciously representing the declarative "how-to" steps. The knowledge becomes transparent to the person who holds it — they can use it without seeing it, which means they can no longer show it to others who don't yet have it.
Expertise is achieved by making knowledge invisible to yourself. The curse is that you can't make it visible again long enough to explain it to someone who doesn't have it yet.
04Effects on users
- Onboarding copy that uses product-specific terminology as if it were common knowledge — "connect your workspace" when users don't yet know what a workspace is in this context.
- Documentation that explains "how" but not "why" — written by people who already understand the conceptual model and can't perceive that it needs explaining.
- UI labels that make sense to the team but require prior exposure to decode: "Syncs," "Integrations," "Spaces" — internally clear, externally opaque.
- Error messages written by engineers for engineers: "503 service temporarily unavailable" communicates nothing to a non-technical user with a task to complete.
05Effects on designers & teams
- Usability testing surprise: the most reliable sign of the curse of knowledge is genuine shock when users struggle with something the team considered trivial. "But it's right there" is the sound of the curse operating.
- Feature naming: names that are internally obvious ("the Pipeline" as a core concept) are often externally meaningless to new users without context.
- Design reviews: feedback from senior designers or PMs who deeply know the product is systematically biased toward "this is fine" on interactions that are opaque to new users.
06Practical takeaways
- Test with first-time users — consistently: the team's judgment about intuitiveness is structurally unreliable. External eyes are not a luxury; they're the correction mechanism for this bias.
- Hire writers who are slightly outside the product domain: someone who had to learn the product from scratch will write better beginner documentation than a domain expert.
- Audit every piece of UI copy for assumed knowledge: ask "what would a user who has never seen this before understand by this label?" — and answer honestly.
- Use "grandmother tests" for onboarding: can someone with no domain knowledge understand the first five minutes of your product? If not, the curse is operating.
- Treat "it's obvious" as a red flag: when anyone on the team says a feature is obvious, that's the curse speaking. Verify with testing, not confidence.
07Design examples
The unexplained concept
"Create your first Board" as the first onboarding prompt — without explaining what a Board is, what it does, or why you'd want one. The team knows. The new user has no idea. The curse is the gap between those two states.
The "simple" guide
Documentation labelled "simple" or "quick start" that assumes knowledge of terms introduced three steps later. The writer couldn't see the circularity because they knew the whole system simultaneously.
Technical error text
"Invalid OAuth token" is a perfectly clear error message to an engineer and completely opaque to a user trying to connect their account. The curse makes the engineer unable to feel the opacity.
Internal jargon as labels
"Flows," "Sequences," "Automations," "Journeys" — different products use different words for similar things. Each team is certain their name is intuitive; each is wrong for users who haven't absorbed the product's internal vocabulary.
08Ethical risks
The curse of knowledge isn't usually malicious — but its effects can be exclusionary. Products that assume prior knowledge create steeper barriers to entry for less technically experienced users, older users, users from different cultural backgrounds, and first-generation users of any kind of digital tool. "Intuitive" is almost always a claim about who the product was designed by and for.
Designing for beginners is not dumbing down. It is the discipline of understanding that expertise is not universal — and building accordingly.
10Suggested reading
Suggested reading is temporarily unavailable. Please check back later.