What makes an idea difficult to explain
Communicating a complex idea means helping someone build an accurate mental model of how its important parts relate. Difficulty usually arises when the explanation assumes knowledge the audience does not yet have, introduces ideas in the wrong order, or overloads attention.
Understanding depends partly on how well the explanation matches the audience's prior knowledge, presents dependencies in a useful order, and manages cognitive load. Failure can result from excessive information, missing foundations, poor sequencing, or the absence of a usable organizing framework. Any of these can defeat an explanation that is otherwise linguistically clear.
Many explanation failures arise from design mismatch rather than lack of intelligence. Attention, motivation, accessibility, and context also matter, and none of them is fixed by better sequencing alone.
Why experts are often the worst explainers
Once people know something, they tend to underestimate how much background their explanation assumes. Raymond Nickerson's review of this tendency describes how readily we impute our own knowledge to others, and it is the single most common reason expert explanations fail.[4]
A practical countermeasure: before presenting, list every term, model, and causal step a newcomer would need in order to follow you. The items on that list that you have not planned to explain are the places your audience will silently lose the thread. We cover this effect in more depth in the curse of knowledge.
The WNF structural-alignment framework
The four elements below are a WhenNotesFly synthesis, not a single established model from the literature. They draw on cognitive-load theory (Sweller; Paas, Renkl, and Sweller), common-ground research in language use (Clark), multimedia learning (Mayer), and instructional scaffolding (Bruner; Vygotsky).[8][7][3][1]
| Element | Role in understanding |
|---|---|
| Intended action | What the audience must do with the idea afterward |
| Core structure | The minimum set of principles needed to avoid a materially false conclusion |
| Dependency order | A sequence that introduces prerequisites before what depends on them |
| Representations | Examples, analogies, diagrams, counterexamples, and formal models, each doing a different job |
| Cognitive load | The demand the explanation places on limited working memory |
Start with what the audience must do
Required depth depends not only on expertise but on the intended action. The same person needs a different explanation depending on whether they must recognise a concept, make a decision, operate a system, troubleshoot it, teach someone else, follow a proof, or comply with a safety procedure.
Deciding this first prevents the most common scoping error, which is explaining at the depth you find interesting rather than the depth the task requires.
Build the minimum accurate model
Good explanation simplifies representation without falsifying structure. It removes detail unnecessary for the audience's current goal while preserving the relationships and constraints needed for accurate understanding. That distinction separates useful simplification, which drops irrelevant detail, from false simplification, which drops constraints the conclusion depends on.
A practical test for what belongs in the core: remove one component at a time. If removing it causes the audience to draw a materially false conclusion, it belongs in the core structure. If removing it only costs precision the audience does not currently need, it can be added in a later layer.
An example of the difference. Saying "antibiotics kill infections" is easy to remember and falsely broad. "Antibiotics treat susceptible bacterial infections; they do not treat viral infections" is barely longer, and it preserves the constraint that makes the statement actionable. The first version produces confident misuse, which is worse than an admitted gap.
Arrange the dependencies
Few complex ideas have one objectively correct sequence. The useful question is which path suits this audience and purpose. Common patterns include:
- overview to detail, when the audience needs orientation before specifics;
- concrete example to abstraction, when the principle is unintuitive stated cold;
- problem to mechanism, when the audience already feels the problem;
- familiar system to unfamiliar system, when a good analogy exists;
- result backward to causes, when the outcome is already known and the reason is not.
What these share is that prerequisites arrive before the things that depend on them. What differs is the entry point, and the entry point should be chosen from what the audience already has.
Choose examples, analogies, and visuals
Representations are not interchangeable. Each does a specific job, and using the wrong one is a common source of confusion.
| Representation | What it does well |
|---|---|
| Example | Instantiates a concept in a concrete case |
| Analogy | Transfers relational structure from a familiar domain |
| Diagram | Makes spatial or causal relations visible at once |
| Counterexample | Reveals boundaries and prevents overgeneralisation |
| Formal model | Improves precision once the informal picture exists |
Analogies deserve particular care, because they can introduce misconceptions when surface similarity is mistaken for structural equivalence. Three rules keep them honest: state exactly what corresponds, state where the analogy breaks down, and return to the real mechanism once the analogy has established orientation.
Electricity is often compared to water flowing through pipes, which usefully conveys flow and resistance, but the comparison misleads on how circuits behave and should not replace the electrical model.
When words and visuals are combined, Richard Mayer's work on multimedia learning is the relevant guide: coordinate the words with the graphic they describe rather than separating them, signal the structure explicitly, cut decorative material that competes for attention, and avoid presenting identical information redundantly in narration and on-screen text at the same time.[6]
Manage cognitive load
Cognitive load concerns the demands a task places on limited working-memory resources. Some difficulty comes from the material itself. Additional difficulty can be created by unnecessary wording, split attention, poor sequencing, or redundant presentation. John Sweller's original work and the later instructional-design literature distinguish these, though terminology and treatment have evolved.[2]
The practical consequence is to chunk information, signal relationships explicitly, remove detail irrelevant to the current goal, and avoid introducing several new terms at once.
Jargon is useful compression when participants share its meaning. It becomes noise when the audience has not yet built the concepts being compressed. Within an expert community, the same terminology increases precision and saves repeated explanation, so the rule is not to avoid jargon but to introduce terminology only after the meaning it compresses already exists.
Communicate limits and uncertainty
Clarity is not the same as persuasion. A clear explanation should expose assumptions, limits, and uncertainty rather than merely make one conclusion feel intuitive. Rhetorical framing can make an idea memorable while quietly concealing how much is unsettled.
For subjects with genuine uncertainty, separating the layers keeps this manageable: what is well established, what is a useful approximation, what remains disputed, and what detail would change the conclusion. An audience that knows which layer it is standing on can act appropriately; an audience given uniform confidence cannot.
Check whether the model actually transferred
Audiences frequently remain silent while misunderstanding, so questions alone are weak evidence of comprehension. Nodding is weaker still.
Active checks work better than asking whether everyone followed. Michelene Chi's active-constructive-interactive framework distinguishes passive reception from activities requiring the learner to generate something, and the generative checks are the informative ones:[5]
- ask them to explain the idea back in their own words;
- ask for a prediction the model implies;
- give a new example and ask them to apply the concept;
- ask them to spot the error in a sample application;
- ask which part still feels uncertain, and compare their confidence with their actual performance.
For genuinely complex material, this feedback often reveals gaps that were not visible during the first delivery. Simple explanations to well-prepared audiences may land the first time; the harder the material, the less likely that is.
A worked example: public-key encryption
The same idea, explained for four different intended actions. Notice what stays constant and what changes.
For a child (recognise the concept): Imagine a padlock you can hand out copies of. Anyone can snap it shut on a box, but only you keep the key that opens it. So anyone can send you a locked box, and only you can look inside.
For a general adult (make everyday decisions): You have two matched keys. One is public and you publish it; the other is private and never leaves your device. Anything scrambled with the public key can only be unscrambled with the private one. This is why a website can receive your card details securely without you ever having agreed a shared password with it in advance.
For a manager (make a purchasing or risk decision): Security rests on the private key staying private, not on the algorithm being secret. That makes key storage, rotation, and revocation the real operational risks, and it is why certificate expiry and key handling appear in vendor assessments. The mathematics is rarely the weak point; the process around it usually is.
For a developer (implement correctly): Public-key operations are slow and size-limited, so in practice they establish or exchange a symmetric session key, and the bulk data is encrypted symmetrically. Signing inverts the direction: the private key produces a signature anyone can verify with the public key. Use vetted library implementations rather than composing primitives yourself.
Across all four the core relationship is constant: two mathematically linked keys, one published, one secret. What changes is terminology, level of detail, which edge cases appear, how much mathematical precision is retained, and what the audience is expected to do next. The child-level version is not a worse explanation; it is a correct one at the depth that supports its intended action.
Explaining across languages and access needs
Audiences differ in more than expertise. Non-native speakers benefit from shorter sentences and consistent terminology rather than elegant variation. Acronyms need expanding on first use. Diagrams that carry meaning only through colour exclude readers who cannot distinguish those colours, so encode the same distinction in labels or shape.
Recorded material needs captions or transcripts. Examples that depend on local culture, sport, or currency will not transfer, and reading level should be a deliberate choice rather than an accident of how you happen to write.
A pre-presentation checklist
- What must the audience do with this afterward?
- Which terms and models does my current draft assume?
- What is the minimum model that avoids a materially false conclusion?
- Does every prerequisite arrive before the thing that needs it?
- Is each representation doing a job only it can do?
- Where does my analogy break, and have I said so?
- How many new terms arrive at once?
- Which parts are established, approximate, or disputed?
- How will I check that the model transferred, other than asking whether it did?
Sources & Further Reading
- Clark, H. H. Using Language. Cambridge University Press, 1996. DOI: 10.1017/CBO9780511620539(Common ground and audience design.)
- Sweller, J. "Cognitive Load During Problem Solving: Effects on Learning." Cognitive Science, 1988. (Working-memory limits in instruction.)
- Paas, F., Renkl, A., and Sweller, J. "Cognitive Load Theory and Instructional Design: Recent Developments." Educational Psychologist, 2003. (Load created by presentation rather than material.)
- Nickerson, R. S. "How We Know - and Sometimes Misjudge - What Others Know: Imputing One's Own Knowledge to Others." Psychological Bulletin, 1999. (The curse of knowledge.)
- Chi, M. T. H. "Active-Constructive-Interactive: A Conceptual Framework for Differentiating Learning Activities." Topics in Cognitive Science, 2009. (Generative checks versus passive reception.)
- Mayer, R. E. Multimedia Learning. Cambridge University Press, 2001. DOI: 10.1017/CBO9781139164603(Coordinating words and visuals.)
- Bruner, J. S. The Process of Education. Harvard University Press, 1960. Harvard University Press(Revisiting ideas at increasing depth.)
- Vygotsky, L. S. Mind in Society: The Development of Higher Psychological Processes. Harvard University Press, 1978. Harvard University Press(Scaffolding within reach of current understanding.)
Part of This Series
Signal vs. Noise in Communication: How to Prioritize What Your Audience Needs
The Ladder of Abstraction: Moving Between Examples and Principles
The Curse of Knowledge Explained: Why Experts Misjudge What Beginners Know
Active Listening: What It Is, How It Works, and How to Practise It
Five Principles for Clear Communication
Understanding Communication Failures: The Framework
Framing Effects: How Presentation Changes Meaning
Narrative Transportation: How Stories Influence Beliefs and Behavior
Frequently Asked Questions
How do you simplify a complex idea without making it wrong?
Simplify the representation without falsifying the structure. Useful simplification removes detail the audience does not need for their current goal while preserving the relationships and constraints the conclusion depends on. False simplification removes those constraints, producing confident misuse rather than an admitted gap. Test each component by removing it: if that would lead the audience to a materially false conclusion, it belongs in the core and must stay.
What makes an explanation effective?
It matches what the audience already knows, introduces prerequisites before what depends on them, uses representations suited to the specific job, and limits how many new terms arrive at once. Above all it targets a defined intended action: what the audience must recognise, decide, operate, troubleshoot, or teach afterward determines the depth required. An explanation can be linguistically clear yet still fail if it assumes background the audience lacks.
How much detail should I include for a given audience?
Required depth follows the intended action rather than general expertise. The same person needs a different explanation depending on whether they must recognise a concept, decide about it, operate a system, troubleshoot it, teach someone else, or follow a proof. Deciding this first prevents the common scoping error of explaining at the depth you find interesting rather than the depth the task requires.
How do analogies help, and when do they backfire?
An analogy transfers relational structure from a familiar domain, useful for orientation when a principle is unintuitive stated cold. It backfires when surface similarity is mistaken for structural equivalence, so the audience imports features that do not hold. Three rules keep analogies honest: state exactly what corresponds, state where the analogy breaks down, and return to the real mechanism once orientation is established.
Why do experts often explain things badly?
Once people know something, they underestimate how much background their explanation assumes. Raymond Nickerson’s review describes how readily we impute our own knowledge to others, the most common reason expert explanations fail. The countermeasure: before presenting, list every term, model, and causal step a newcomer would need to follow you. Whatever is on that list and not in your plan is where the audience silently loses the thread.
How can I tell whether someone actually understood?
Not by asking whether they understood. Audiences often stay silent while misunderstanding, so questions alone are weak evidence, and nodding is weaker still. Use generative checks instead: ask them to explain the idea back in their own words, ask for a prediction it implies, give a new example to apply it to, or ask them to find the error in a sample application. Comparing their stated confidence with actual performance is often most revealing.