{"site":{"name":"Koji","description":"AI-native customer research platform that helps teams conduct, analyze, and synthesize customer interviews at scale.","url":"https://www.koji.so","contentTypes":["blog","documentation"],"lastUpdated":"2026-10-21T13:56:32.802Z"},"content":[{"type":"documentation","id":"ced53a1a-beb6-4d34-8047-eb571873c3f9","slug":"curse-of-knowledge-user-research","title":"The Curse of Knowledge in User Research","url":"https://www.koji.so/docs/curse-of-knowledge-user-research","summary":"The curse of knowledge is the difficulty of imagining not knowing something you know. Camerer, Loewenstein and Weber (1989) showed informed people cannot set their knowledge aside when predicting less-informed people's judgements; market trading reduced the bias by roughly 50% but did not remove it. In Elizabeth Newton's 1990 tapping study, tappers expected listeners to name about half the songs, but listeners named 3 of 120 (2.5%). Hinds (1999) found novices took about twice as long to learn a mobile phone as experts predicted. Steven Pinker calls it the main cause of incomprehensible prose. The guide shows where the curse appears in question wording, usability tasks, screeners, moderation, analysis and reports, how it differs from the false consensus effect, an eight-point checklist, pilot and read-back tests, and how Koji's interview preview, question editor, AI follow-ups and evidence-linked findings help.","content":"The curse of knowledge is the difficulty of imagining what it's like not to know something you know. In user research it creeps into the questions you write, the tasks you set, the way you read answers and the reports you hand over. You can't think your way out of it. You catch it by testing your materials on people who don't share your knowledge, before the real sessions start.\n\nThis guide covers where the idea comes from, the evidence that experts badly misjudge novices, where the curse shows up at each stage of a study, and a checklist for catching it.\n\n## What the curse of knowledge is\n\nThe term entered research through a 1989 paper by economists Colin Camerer, George Loewenstein and Martin Weber in the _Journal of Political Economy_. Economic models often assumed that a better-informed person could easily predict how a less-informed person would judge something. Their experiments showed that isn't true. Once people knew the real outcome, they couldn't set that knowledge aside when guessing what others without it would think.\n\nSteven Pinker later made it the centrepiece of his book on writing, _The Sense of Style_ (2014). His summary is the clearest one: \"The main cause of incomprehensible prose is the difficulty of imagining what it's like for someone else not to know something that you know.\"\n\nSwap \"prose\" for \"interview questions\" or \"usability tasks\" and you have the researcher's version of the problem.\n\n## The tapping study: 50% expected, 2.5% achieved\n\nThe best-known demonstration came from Elizabeth Newton, a Stanford psychology PhD student, in 1990. She split people into tappers and listeners. Tappers picked a well-known song and tapped its rhythm on a table. Listeners had to name the song.\n\nBefore the listeners guessed, tappers predicted they would get it right about half the time. Across 120 songs, listeners named 3. That's 2.5%.\n\n![Stat card showing listeners named only 2.5% of tapped songs, while tappers had expected about 50%](/visuals/curse-of-knowledge-tapping-study-stat/curse-of-knowledge-tapping-study-stat.png \"The gap between what you hear in your head and what others receive · Source: Elizabeth Newton, Stanford University (1990)\")\n\nThe tappers weren't careless. They could hear the melody in their heads while they tapped, and couldn't un-hear it. To the listeners it was just knocking. That is exactly the position a product team is in when it writes a task like \"Set up a workspace integration\" for someone who has never seen the product.\n\n## Experts are the worst judges of novices\n\nYou might expect the people who know a product best to be the best at predicting where newcomers will struggle. Pamela Hinds tested this in 1999. She asked people who sold mobile phones, people with some experience of the phones and people with none to estimate how long a novice would take to learn to use one. Then she had novices learn it from the written instructions.\n\nThe experts underestimated badly: on average the novices took about twice as long as the experts predicted. People with intermediate experience came closer. Hinds called it the curse of expertise.\n\nTwo more findings matter for anyone hoping to simply try harder:\n\n- **Warnings don't fix it.** In studies of the curse of knowledge, explicitly warning people about it hasn't stopped them projecting what they know.\n- **Feedback only helps partly.** In Camerer, Loewenstein and Weber's market experiments, trading reduced the curse by roughly 50%, but did not remove it.\n\nFor research teams the takeaway is uncomfortable. The more senior and experienced the person writing the discussion guide, the more likely the guide is to assume things participants don't know.\n\n## Where it shows up in a research study\n\nThe curse of knowledge doesn't stay in one place. It turns up at each stage of a study, usually in a slightly different form.\n\n**Writing questions.** Internal feature names, acronyms and team jargon slip into questions: \"How do you use Smart Sync?\" A participant who has never noticed the feature's name will guess, agree politely or describe something else.\n\n**Writing tasks.** Usability tasks that use the words on the button give the answer away, and tasks that assume a mental model (\"Go to the admin area\") test whether people share yours, not whether they can do the job. See [usability test tasks and scenarios](/docs/usability-test-tasks-scenarios) for how to phrase them.\n\n**Screening participants.** Screener questions written in insider terms filter for people who already talk like your team, which quietly skews the sample towards experts.\n\n**Moderating.** When you know the answer, a participant's confused silence feels like a pause rather than a sign of trouble, so you rescue them too early. Or you rephrase the question by explaining how the feature works, which changes what you're testing.\n\n**Analysing.** You fill gaps in a participant's explanation with what you know the product does, and code the answer as \"understood the feature\" when they didn't. Their workaround looks like an edge case because you know the intended path.\n\n**Reporting.** Findings written in the research team's shorthand (\"JTBD drift in the onboarding cohort\") don't land with the people who need to act on them. The curse works on your stakeholders too.\n\n## How it differs from the false consensus effect\n\nThe two are often mixed up because both involve projecting yourself onto others.\n\n- The [false consensus effect](/docs/false-consensus-effect-user-research) is about **preferences and choices**: assuming others would decide what you'd decide.\n- The curse of knowledge is about **information**: assuming others know what you know.\n\nIn practice they stack. A team that knows the product well (curse of knowledge) and also assumes users want what the team wants (false consensus) can design a feature that only makes sense to itself.\n\n## A checklist for catching it\n\nYou can't remove what you know, so the defence is process. Run this before a study goes into the field:\n\n![Checklist of eight ways to catch the curse of knowledge before a study goes live, from removing internal names to piloting with a newcomer](/visuals/curse-of-knowledge-research-checklist/curse-of-knowledge-research-checklist.png \"Run it on your discussion guide, tasks and screener before the first real session\")\n\n1. **Strip internal names.** Replace feature names, acronyms and team jargon with plain descriptions of what the thing does.\n2. **Use the participant's words.** If support tickets or reviews describe a feature a certain way, use their phrasing.\n3. **Describe goals, not paths.** Write tasks as outcomes (\"Share this report with a colleague\"), not as the steps or labels you know.\n4. **Ask a newcomer to read it.** Someone outside the team should read the guide aloud and say where they had to guess.\n5. **Pilot with a real participant.** One pilot session catches more than any amount of internal review. See [pilot studies](/docs/pilot-study-user-research-guide).\n6. **Note where you rescued someone.** After each session, list the moments you explained something. Each one is a finding.\n7. **Code what was said, not what you know.** If a participant didn't name a step, don't assume they took it.\n8. **Write findings for a newcomer.** Test the summary on someone outside research before you share it.\n\n## Testing your questions on people who don't know\n\nMost of the checklist comes down to one habit: put your materials in front of someone who doesn't know what you know, and watch.\n\n![Two colleagues reading through an interview guide together so one of them can point out where the wording assumes too much](https://images.unsplash.com/photo-1758518729908-d4220a678d81?crop=entropy&cs=tinysrgb&fit=max&fm=jpg&ixid=M3w5NDUzMDN8MHwxfHNlYXJjaHwyfHx0d28lMjBwZW9wbGUlMjByZWFkaW5nJTIwZG9jdW1lbnQlMjB0b2dldGhlcnxlbnwxfDB8fHwxNzkyNTYxODExfDA&ixlib=rb-4.1.0&q=80&w=1080)\n\n_Photo by [Vitaly Gariev](https://unsplash.com/@silverkblack?utm_source=koji&utm_medium=referral) on [Unsplash](https://unsplash.com/?utm_source=koji&utm_medium=referral)_\n\nA pilot session is the most reliable version. Recruit one or two people who match your participants but haven't seen the guide. Run the session exactly as planned and listen for three things: questions they ask you to repeat, answers that describe something other than what you meant, and long pauses before they answer. Each is a place where your knowledge filled a gap their knowledge couldn't.\n\nA cheaper version is the \"read it back\" test. Give a colleague from another team your interview questions and ask them to explain, in their own words, what each question is asking. Where their explanation differs from your intent, rewrite.\n\n[Cognitive interviewing](/docs/cognitive-interview-guide) is the formal method for this. It was built for survey questions, but it works just as well for an interview guide.\n\n## How Koji helps\n\nKoji runs AI-moderated interviews by voice or text. It doesn't make your team forget what it knows, but it makes the newcomer test cheap and gives participants room to say things in their own words.\n\n- **Test the guide as a participant would.** The Preview tab lets you take your own interview by text or voice, exactly as a participant would. Previews never count as responses or appear in the report, so you can run one with a colleague from another team at the keyboard and watch where they stumble.\n- **Spot jargon in the questions.** The question editor shows every question with its type and follow-up setting in one place, so a quick read for internal names is easy before you publish.\n- **Let participants explain in their own words.** Open questions get AI follow-ups, up to three per question, so a vague or puzzled answer gets another question instead of a moderator explaining the product.\n- **Keep the quotes verbatim.** Findings in the report link to the supporting responses, so anyone can check what participants actually said rather than the team's reading of it.\n- **Pilot cheaply.** Run a handful of interviews, read them, adjust the questions and carry on. You don't need to rebook a moderator for each round.\n\n![Koji question editor showing open ended, 1 to 10 scale and single choice questions with follow-up settings](/email/shots/shot-question-types.jpg \"Read every question in one place and swap internal names for the words participants use\")\n\n## Related Resources\n\n- [The false consensus effect: why you are not your user](/docs/false-consensus-effect-user-research)\n- [Writing interview questions](/docs/writing-interview-questions)\n- [Cognitive interview guide](/docs/cognitive-interview-guide)\n- [Pilot studies in user research](/docs/pilot-study-user-research-guide)\n- [Plain language research questions](/docs/plain-language-research-questions)\n- [Structured questions guide](/docs/structured-questions-guide)\n\n## Sources\n\n- Camerer, C., Loewenstein, G., & Weber, M. (1989). The curse of knowledge in economic settings: An experimental analysis. _Journal of Political Economy_, 97(5), 1232–1254.\n- Hinds, P. J. (1999). The curse of expertise: The effects of expertise and debiasing methods on prediction of novice performance. _Journal of Experimental Psychology: Applied_, 5(2), 205–221.\n- Newton, E. L. (1990). _The rocky road from actions to intentions_. Doctoral dissertation, Stanford University.\n- Pinker, S. (2014). _The Sense of Style: The Thinking Person's Guide to Writing in the 21st Century_. Viking.\n","category":"Research Methods","lastModified":"2026-10-21T05:50:11.895352+00:00","metaTitle":"Curse of Knowledge in User Research: Examples and Fixes (2026)","metaDescription":"What the curse of knowledge is, the tapping study behind it, where it distorts questions, tasks and analysis, and an eight-point checklist to catch it.","keywords":["curse of knowledge","curse of knowledge ux","curse of knowledge examples","curse of expertise","tapping study","jargon in user research","expert blind spot"],"aiSummary":"The curse of knowledge is the difficulty of imagining not knowing something you know. Camerer, Loewenstein and Weber (1989) showed informed people cannot set their knowledge aside when predicting less-informed people's judgements; market trading reduced the bias by roughly 50% but did not remove it. In Elizabeth Newton's 1990 tapping study, tappers expected listeners to name about half the songs, but listeners named 3 of 120 (2.5%). Hinds (1999) found novices took about twice as long to learn a mobile phone as experts predicted. Steven Pinker calls it the main cause of incomprehensible prose. The guide shows where the curse appears in question wording, usability tasks, screeners, moderation, analysis and reports, how it differs from the false consensus effect, an eight-point checklist, pilot and read-back tests, and how Koji's interview preview, question editor, AI follow-ups and evidence-linked findings help.","aiPrerequisites":["Some experience writing interview questions or usability tasks"],"aiLearningOutcomes":["Define the curse of knowledge and where the term comes from","Describe the tapping study and the curse of expertise findings","Recognise where the curse shows up in questions, tasks, screeners, moderation, analysis and reports","Tell the curse of knowledge apart from the false consensus effect","Use an eight-point checklist and pilot sessions to catch it"],"aiDifficulty":"beginner","aiEstimatedTime":"8 min read"}],"pagination":{"total":1,"returned":1,"offset":0}}