Curse of Knowledge.

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.

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.

6Introspective view

Look inward. Once a team knows the product deeply they cannot imagine not knowing it, producing jargon-heavy, under-explained flows.

From an introspective perspective, ask how Curse of Knowledge may already be shaping your research, critique, planning, and interpretation — not only what users encounter in the finished interface.

7Extrospective view

Look outward. Expert authors overestimate what new users understand, so onboarding and microcopy must be tested against real novices.

From an extrospective perspective, Curse of Knowledge is a property of the product experience itself — visible in pricing, copy, defaults, layout, and the moments where users decide whether to continue, convert, or leave.

08Practical 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.

09Design examples

10Ethical 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.

11Related biases