Loading…
Loading…
People who know something find it nearly impossible to see things from the perspective of someone who doesn't.
stellae.design
The Curse of Knowledge was named by economists Colin Camerer, George Loewenstein, and Martin Weber in 1989, building on earlier research by Elizabeth Newton's 1990 'tappers and listeners' study at Stanford. Newton found that people who tapped a well-known song on a table vastly overestimated how recognizable the song was to listeners. In product design, this manifests when designers and developers create interfaces that make perfect sense to them but confuse users who lack the team's context and technical knowledge.
The curse of knowledge is a cognitive bias where people who possess specialized knowledge systematically fail to imagine what it is like not to know what they know, leading them to communicate in ways that are clear to experts but incomprehensible to their actual audience. In product design, this bias is responsible for jargon-filled interfaces, onboarding flows that skip foundational concepts, error messages that assume technical literacy, and documentation written by engineers for engineers. The curse is particularly insidious because it is invisible to the person who has it — the more expert you become in your domain, the harder it is to recognize which concepts need explanation and which terms need definition.
Stripe's documentation is widely praised for defeating the curse of knowledge — it assumes developers are intelligent but not necessarily familiar with payment processing, and it explains domain concepts alongside API concepts so readers can learn both simultaneously. Code examples are complete and runnable rather than abbreviated snippets that assume the reader knows how to fill in the gaps, and every technical term is defined in context the first time it appears. The documentation team explicitly tests their guides with developers who have never used Stripe before, which surfaces the curse of knowledge assumptions that internal reviewers miss.
Apple's HIG structures information so that a designer encountering a topic for the first time gets clear principles and visual examples before encountering technical specifications or edge cases. Each section begins with the 'what and why' before moving to the 'how,' ensuring that readers build the necessary mental model before they encounter implementation details. This progressive structure respects the reader's current knowledge level while still providing depth for experts who need it.
A healthcare startup builds a patient-facing insulin pump interface designed by endocrinologists, using terms like 'basal rate adjustment,' 'bolus calculator,' and 'insulin-to-carb ratio' without explanation because those terms are obvious to the clinical team. Patients who are newly diagnosed with diabetes cannot operate the device without extensive training, and preventable dosing errors increase because users misunderstand the interface. Usability testing with actual patients — rather than medical professionals — would have revealed that the interface needed plain language explanations, visual guides, and progressive disclosure of advanced features.
• The most common mistake is assuming that adding a glossary or tooltip solves the curse of knowledge, when the real problem is that the primary interface language, information architecture, and conceptual model were designed from an expert's perspective — tooltips are band-aids on a structural communication failure. Another frequent error is confusing the curse of knowledge with 'dumbing down' — the goal is not to remove complexity but to sequence information so that users build understanding progressively rather than being confronted with expert-level concepts before they have the foundation to interpret them. Teams also fall into the trap of testing only with existing power users, whose feedback reinforces the expert perspective and misses the comprehension barriers that new users face.
Was this article helpful?