Illusion of Explanatory Depth – when you think you understand until you have to explain
Do you think you understand how a fridge works but struggle to explain what happens inside? That’s Illusion of Explanatory Depth – the tendency to overestimate your knowledge of a topic until you actually have to explain it.
Examples and situations
- Technology – you believe you know how Wi-Fi works but get confused when trying to explain it.
- Economics & Politics – you’re sure you can describe inflation, but beyond a few phrases, your understanding is shallow.
- Medicine – you know vaccines are beneficial but can’t explain how they function.
Questions to check
- Try explaining in simple terms – if you can’t explain it to a 5-year-old, you don’t fully understand it.
- Be ready for questions – check if you can answer follow-ups rather than just repeating memorized statements.
- Develop real understanding – don’t stop at surface-level knowledge; dig deeper into the details.
Long-form guide
The Trapdoor Under Your Confidence: The Illusion of Explanatory Depth
You’re at a party, feeling bold. Someone asks how a zipper works. You smile, pinch your fingers together like a tiny machinist, and say, “The teeth interlock.” Then they ask, “But how do they stay locked under tension and unlock when you tug the tab? What’s the exact mechanism?” Your mouth opens. Your brain wheels spin. You realize you’ve been nodding at zippers for twenty years and have no idea how the little dragon actually breathes fire.
On this page
What Is the Illusion of Explanatory Depth — and Why It Matters
That moment has a name: the Illusion of Explanatory Depth. It’s the gap between thinking you understand something and being able to explain it precisely and completely when pressed. The Illusion of Explanatory Depth (IOED) is a well-established cognitive bias: people believe they understand ordinary phenomena much better than they actually do, until they try to explain them in detail (Rozenblit & Keil, 2002).
It matters because decisions live and die on explanations. We build product roadmaps, pitch strategies, approve budgets, and teach our teams based on our internal sense of “I get it.” But if “I get it” dissolves under simple questions, we ship the wrong thing, overpromise, underprepare, and lose trust.
What happens when it bites
Familiarity. If you handle something every day—coffee machines, code deploys, mortgage rates—it feels understood. Familiar ≠ explained; Fluency. Smooth reading or a slick talk tricks your brain into certainty. Fluent isn’t the same as true; Social pressure. In groups, we nod along to avoid friction. You get a warm bath of consensus and emerge pruney but unwashed; Partial models. You have one accurate chunk: “rainbows are refraction.” That’s real, but it’s not the full optical path with angles and apparent position.
Overconfidence. You green-light a plan you can’t implement; Fragile communication. Your team hears a vision without the gears. Execution stalls; Wasted cycles. You debug ghosts because your mental model never matched reality; Polarization. You argue positions you can’t explain. When asked for details, you double down instead of revising (Fernbach et al., 2013). The cure isn’t endless reading. It’s friction. The right kind: explaining, drawing, calculating, testing. The illusion hates friction.
The toilet handle test
Stories are X-rays. Here are moments we’ve lived or watched up close—where the illusion cracked and better work got done. A product lead said, “Our churn problem is obviously the onboarding friction.” The room nodded. Someone asked, “Can you describe the exact steps the user takes in their first 10 minutes?” Silence. We ran the “toilet handle” test: draw the flow without checking the product. After 90 seconds, we had three different maps and none matched reality.
We then watched three users. Two never found the core feature. Suddenly the fix was obvious: a single, prominent “create first item” prompt. Churn dropped 11% in a month. The illusion pretends “we all know the flow.” Replicas of reality beat gut diagrams every time.
The API that wasn’t a contract
Ask ten adults to draw a bicycle from memory. Most drawings won’t work: missing a chain, impossible frame geometry, wheels not connected to pedals. This isn’t hypothetical; controlled studies show we overestimate mechanical understanding for familiar objects (Lawson, 2006). The world runs even when we’re wrong, so our brains coast. In tech, that looks like “the data pipeline ingests → transforms → serves.” Try drawing it. Where’s the schema change handled? Where’s idempotency ensured? Where do late events go? If you can’t draw it, you can’t fix it.
An engineer wrote, “The partner hits /v1/charge. We validate and respond.” Shipping day: the partner sent nested JSON we didn’t support. Timeouts ensued. Their retries hammered our system. No one had written the response codes, timeouts, retry policy, or error boundary. We had a vibe, not a contract. An afternoon spent writing an explicit spec would have saved a week of firefighting. The illusion likes to hide in phrases like “the usual,” “standard,” and “typical.” Ask: standard where, by whose definition, documented where?
The parenting moment
Founder pitch: “Our LTV is # The Trapdoor Under Your Confidence: The Illusion of Explanatory Depth Numbers you can retrace beat numbers that feel heroic. A nine-year-old asked: “Why does the moon change shape?” The parent said, “Earth’s shadow.” That’s a common—but wrong—answer.
Lunar phases are the relative positions of sun, Earth, and moon—earth’s shadow is a lunar eclipse. The parent looked it up, returned with a lamp and a ball, and a kitchen demo. The kid learned. The parent learned. Everyone remembered. Asking kids for the steps often reveals how many steps we’re missing.
The rainbow outside your window
Team: “Customers aren’t using the new dashboard because the UI is cluttered.” We asked, “Explain the sequence users take from landing to value.” The sequence had two paths: one fast, one stuck behind permissions. Users without a key permission saw a blank state. We fixed permissions and docs; adoption jumped. The UI wasn’t bad. Our model was. “The UI” becomes a scapegoat when our explanation is mush. “Step-by-step path” clears the fog. Friend: “Rainbows are water plus sun.” You ask: “Why is it a circle?
Why a fixed angle? Why double rainbows?” The IOED flickers. The quick answer is real—water plus sun—but incomplete. You don’t need to be a physicist, but try: “It’s light refracting and reflecting inside drops. We see it at about 42 degrees from the antisolar point. The double rainbow happens from a second internal reflection.” That’s a model with teeth. You can predict where to look. The difference between “water and sun” and “42 degrees” is the difference between vibes and predictions.
The deployment everyone “knew”
We said, “We need social sharing.” We drew a quick flow. Then we forced ourselves to write the copy: what exactly would a user share, why would their friend care, what happens after the click? The illusion deflated. There was no strong reason to share. We killed the feature and shipped better onboarding instead. Saved two sprints. Gained users, not buttons. Explanations that survive the copy-edit often survive reality. A new engineer asked, “How do we deploy?”
The senior said, “You run the script.” The new hire asked, “Which script, with what flags, what happens on failure?” The senior blinked, then wrote the steps. Two contradictions surfaced. A race condition appeared. We wrote a doc, added a dry-run mode, cut deploy failures in half. Ritual hides ignorance. Writing collapses rituals into steps. Here’s the good news: the cure is concrete. You don’t need a whiteboard PhD. You need friction. Set up little obstacles that force details into daylight.
The practical playbook
Start small. Use one or two of these each day for a week. Write it out longhand. Explain the thing to your future self in full sentences. No slides. No bullets. If you hesitate, circle it. That’s a seam; Teach a rubber duck. Speak your explanation aloud to a plush toy, a voice memo, or a teammate. If your mouth stumbles, your mind was bluffing; Draw the mechanism. Even ugly rectangles and arrows surface missing steps: inputs, outputs, transforms, dependencies, delays. If you can’t draw it, you don’t have it; Do a Fermi step. Estimate one key number (orders, latency, cost). Force a magnitude. This breaks fog into parts you can check; Challenge with edge cases. Ask, “What breaks if the input is empty, huge, malformed, late?” Edge cases expose fake understanding; Pin a contract. When you say “we’ll integrate,” write the interface: fields, types, codes, timeouts, retries. A contract is an explanation with consequences; Run the “five why” drill. Ask “why” until you hit mechanism, not labels. “Slow page” → “network latency” → “payload too big” → “uncompressed images.”; Build a tiny simulation. Doesn’t need to be code. Spreadsheets count. If your logic can’t survive a toy environment, it won’t scale; Ask for disconfirmation. Invite someone to break your explanation. Reward them when they do; Timebox reality. Spend 30 minutes with the actual thing: click through the flow, spin up the service, talk to a user, open the log. Reality is the best solvent.
These are “desirable difficulties”: they feel harder but improve learning and memory (Bjork, 1994). Testing yourself beats rereading the doc; retrieval strengthens understanding (Roediger & Karpicke, 2006). If you get stuck on two or more, you’re in the illusion. Good. Now you know where to work.
Curse of knowledge
Cousins and look-alikes matter because they nudge us in similar ways. Beginners overestimate competence; experts underestimate gaps (Kruger & Dunning, 1999). The illusion of explanatory depth can happen at any skill level, but it sings in beginners. The fix is similar: feedback, testing, and concrete tasks. Information that’s easy to read feels more true and better remembered. It isn’t. Smoothness fools us. Struggle—the right kind—cements learning. That’s why writing out your explanation beats scanning a summary.
When you know a thing, it’s hard to imagine not knowing it. You compress explanations and leave beginners lost. The tapping study—tappers think listeners will guess songs from taps far more often than they do—shows this gap (Newton, 1990). IOED is about you fooling yourself; curse of knowledge is about you fooling others.
Knowledge illusion (shared minds)
After events, everything feels inevitable. “Of course the market corrected.” The illusion makes us think we understood all along. Keep date-stamped predictions to fight this. If your explanation didn’t predict, it didn’t explain. We overrate our accuracy. IOED is one engine of overconfidence: if explanations feel easy, confidence swells. Being explicit with mechanisms is a pressure release valve.
We often outsource knowledge to others—friends, search engines, teams—and mistake that shared pool for our own depth (Sloman & Fernbach, 2017). That’s not wrong; it’s how society works. But when you need to act alone, you need your own gears.
Use the Feynman loop
Explanations have a right size. You don’t need to turn into a walking textbook. You need just enough mechanism to predict and act. Executive view: what it does, what it costs, where it fails. You should still be able to answer “how” in one layer; Architect view: inputs, outputs, contracts, failure modes, backpressure; Operator view: commands, logs, runbooks, exact thresholds; Mechanic view: the forces, transforms, code paths, algorithms.
For any decision, pick the level deliberately. Don’t hide behind abstraction to dodge ignorance. Learn it; Teach it to a 12-year-old, in your words; Find gaps. Go back. Simplify without losing correctness; Repeat. The Feynman Technique isn’t magic; it’s a structured IOED trap.
Practice micro-postmortems: Illusion of Explanatory Depth
Before the meeting, write a question you think is too basic. Ask it anyway. “What exactly triggers the retry?” The room will exhale. Three people will say “good question.” Progress will start. Define what would count as a good explanation. Examples: Predict the error code a failing request returns in three scenarios; Estimate CPU use after the change within 20%; Name the three most common user paths and their completion rates. If you can pass your own test, good. If not, keep digging. When something surprises you, spend 10 minutes writing “What was my model?” and “Where did it mismatch reality?” Save the note. Patterns will emerge: you skim logs, ignore edge cases, misestimate by 10x. Fix the pattern, not just the event.
Flip the order. First, one person explains the underlying mechanism step by step, including uncertainties. Only then do you discuss options. This keeps decisions tied to reality, not personalities. Depth isn’t the goal; fit-for-purpose is. For low-stakes calls, “good enough” explanation wins. For high-stakes calls, demand specifics. Tie depth to impact, not pride.
Wrap-Up: Trade Wobble for Grace
That zipper moment—the wobble under your confidence—hurts. We’ve felt it in code reviews, investor meetings, and late-night “why is this broken” triage. But wobble is an invitation, not a verdict. When you step into it—write, draw, estimate, test—you replace bravado with competence and defensiveness with grace. Explaining well isn’t about sounding smart. It’s about making the world predictable enough to move through it. It’s building little ramps for your team. It’s saving your future self from 2 a.m. mysteries. Below is a final checklist to tape to your monitor. Use it. Modify it. Make it yours.
Rozenblit, L., & Keil, F. (2002). The misunderstood limits of folk science; Fernbach, P. M., Rogers, T., Fox, C. R., & Sloman, S. A. (2013). Political polarization is reduced by inducing people to explain; Kruger, J., & Dunning, D. (1999). Unskilled and unaware of it; Roediger, H. L., & Karpicke, J. D. (2006). Test-enhanced learning; Bjork, R. A. (1994). Memory and desirable difficulties; Lawson, R. (2006). The science of cycles: drawing bicycles and the illusion of knowledge; Sloman, S., & Fernbach, P. (2017). The Knowledge Illusion. References (for the curious):
Decision checklist
- Can I explain it to a smart friend who works in a different field?
- Can I draw the key steps and label inputs/outputs?
- Can I name assumptions and how I’d test them?
- Can I handle three edge cases without hand-waving?
- Can I attach two concrete numbers (scale, cost, time)?
- Can I state where this breaks and where it does not apply?
- Can someone else follow my steps and get the same result?
- If challenged, can I change my mind with dignity?
- State the goal in one sentence. No buzzwords
- Explain the mechanism in 5–7 sentences. Use verbs that do work
- Draw the flow. Inputs, outputs, transforms, failure paths
- Write the interface or contract. Fields, codes, limits, timeouts