Here’s the thesis up front: data visualization most often fails through well-intentioned distortion; knowledge visualization most often fails through fluent misunderstanding.

These two failures look nothing alike, yet teams routinely treat them as one problem — the same process, the same checklist, the same person signing off. The result: one kind gets caught repeatedly, the other slips through indefinitely.

1. Data Visualization Fails by Misleading

Definition: the data is true, but the presentation leads readers to a wrong conclusion.

Six common patterns, each with a real case:

① Truncated axes

To “make the differences visible,” a bar chart’s vertical axis doesn’t start at zero. Ratios get visually inflated.

Real case: a 2017 Xiaomi product launch compared benchmark scores with the axis starting at 40,000 instead of zero. The actual figures were roughly 180,000 versus under 70,000 — less than a 3× difference — but the visual impression suggested more than 5×. (Reported by The Paper’s visualization fact-checking desk.)

② Arbitrary classification thresholds

To make colors look good or the distribution even, objects of wildly different magnitude land in the same bucket.

Real case: for the same day’s pandemic data (2020-02-14), the BBC assigned the deepest red to every province above 500 cases — meaning Chongqing at 529 cases and Hubei at 51,986 cases were the same color. Another outlet binned by powers of ten, producing a completely different impression. Same data, opposite conclusions. (Same source.)

③ Dual axes

To “fit two lines on one chart,” metrics with different units get plotted together. Readers instinctively compare where the lines cross or diverge — and that crossing is often meaningless.

The UK Office for National Statistics published a piece on this specifically, calling it “confusing and potentially misleading,” and demonstrated that the same dataset can tell different stories purely by manipulating the axes.

④ 3D added for “tech appeal”

When data is encoded by length alone, readers nonetheless interpret by volume — the enlarged bar looks bigger than it is.

⑤ Circles and bubbles encoded by radius

Encoding values by radius rather than area squares the visual impression. Double the radius reads as quadruple the value.

⑥ Selectively cropped time ranges

Showing only the period that supports the conclusion, cutting the rest.

What these six share: most arise from good intentions.

The chart author usually isn’t trying to deceive. They’re trying to “make the difference clearer,” “even out the colors,” “save space,” or “add visual polish.” Every motive is reasonable. Every result distorts the data.

2. Knowledge Visualization Fails by Misunderstanding

Definition: the presentation is fluent, clear, and attractive — but the mechanism it teaches is wrong.

Seven common patterns:

① Reversed mechanism

Tree rotations drawn the wrong direction. Recursion shown executing breadth-first. Pointer movement that doesn’t match the code. Everything animates smoothly, and what’s learned is wrong.

② Step order rearranged for smoother animation

Real algorithms have strict dependency ordering. To make an animation flow — say, having all elements move simultaneously — serial steps get drawn as parallel. The temporal model students build is incorrect.

③ Oversimplification that drops the reason something exists

Reducing the TCP three-way handshake to “a friendly greeting” discards the problem it actually solves (preventing delayed duplicate connection requests from arriving). Students memorize three steps and still can’t answer “why not two?”

④ The side effects of metaphor

Current as water flow. Memory as a set of lockers. Metaphors help early on, but students later need to actively unlearn them — and for many, the misconception came from the metaphor in the first place.

⑤ Distorted time scales producing wrong intuition

Demonstrating a logarithmic-complexity algorithm at roughly the same speed as a linear one. Students build a “these are about the same” intuition — precisely the intuition algorithm analysis exists to dismantle.

⑥ Only the happy path

Demonstrating the successful execution path while skipping empty inputs, duplicate values, and degenerate cases. Students conclude the algorithm “always runs like this.”

⑦ Insufficient interaction freedom

Allowing only a few preset values, leaving students to assume the algorithm applies only to those, or that intermediate anomalous states never occur.

What these seven share: readers are almost incapable of spotting them.

3. Why the Second Kind Is More Dangerous

This is the core of the article. The severity of the two failures is asymmetric — and the asymmetry runs opposite to intuition.

First: detection difficulty is completely asymmetric.

A truncated axis is visible to any informed reader at a glance (“why doesn’t this start at zero?”). A wrong execution order inside an animation is visible only to someone who already understands the algorithm — precisely the capability the target audience lacks.

You cannot expect the people who came to learn to audit your teaching material for you.

Second: fluent narrative actively lowers readers’ criticality.

This isn’t speculation — it’s empirical. Willett et al. ran an experiment on narrative visualization using Gapminder materials and found:

Participants in the narrated presentation were less critical about the data, and no one spotted the data errors.

In other words: the smoother and better narrated it is, the less readers doubt it. And knowledge visualization pursues smoothness by definition.

Third: cognitive errors outlast decision errors.

When data visualization fails, the consequence is usually “that decision was wrong.” The next report corrects it, and people re-evaluate.

When knowledge visualization fails, the consequence is “this person’s understanding is now wrong.” Once formed, correcting it is extremely costly — it requires them to notice the problem on their own, and that moment may never arrive.

4. A Shared Root

The two failures look unrelated, but the root is the same:

Substituting “how it looks” for “whether it’s correct.”

• In data visualization, “attractive / clear / space-efficient” replaced “faithfully reflecting the data”
• In knowledge visualization, “smooth / impressive / easy to follow” replaced “faithfully reflecting the mechanism”

The correction methods, however, differ:

	Data Visualization	Knowledge Visualization
Can a non-expert spot the error?	Yes (check the axis, check the legend)	No (requires domain judgment)
Who must sign off?	The chart author + a release checklist	A domain expert
Can a fixed checklist solve it?	Yes	No
Cost of correction	Fixed by the next report	Very high; possibly permanent

The last two rows are the point: the first can be process-driven; the second cannot.

5. Two Different Checklists

Because correction differs, the two content types need two independent review processes.

Data visualization: a mechanizable pre-publication checklist

• [ ] Do bar and area charts start their axis at zero?
• [ ] If truncation is unavoidable, is there an explicit axis break and a written note?
• [ ] Are circles and bubbles encoded by area rather than radius?
• [ ] What is the basis for the classification thresholds, and is it stated in the caption?
• [ ] Is the dual axis necessary? Can it be split into two charts?
• [ ] Is 3D necessary? Is information lost without it?
• [ ] Is the chosen time range justified? Is it “only the favorable period”?
• [ ] Are elements still distinguishable in grayscale and under colorblind simulation?
• [ ] Do the charts and the prose conclusion agree?

This checklist requires no domain expert. Anyone can run it. That’s exactly why it works.

Knowledge visualization: expert review only

A checklist won’t do, because every item depends on professional judgment:

• [ ] Does the execution order match the real algorithm exactly? (Requires frame-by-frame comparison against the code or specification.)
• [ ] Was the true ordering altered to make the animation flow?
• [ ] Do the omitted details include the mechanism’s reason for existing?
• [ ] Will the metaphor become an obstacle later?
• [ ] Are time scales and proportions schematic — and do readers know that?
• [ ] Are edge cases demonstrated (empty input, duplicates, degenerate cases)?
• [ ] Is the interaction freedom sufficient to prevent “only applies to preset values” misconceptions?
• [ ] Has someone who understands the domain but did not build it reviewed it independently?

That last item matters most and is most often skipped. Once a production team understands a mechanism, they can no longer see where a beginner would misread it. That requires an uncontaminated pair of eyes.

6. Three Recommendations

One — manage the two content types separately. Don’t use the same acceptance criteria, the same process, or the same reviewer. Their failure modes differ, so their correction methods must too.

Two — data visualization runs on checklists; knowledge visualization runs on people. The first can be delegated to process. The second must go to a domain expert — specifically one who wasn’t involved in building it.

Three — be suspicious of smoothness. In knowledge visualization, the smoother it is, the more suspicious you should be — because fluency erodes reader criticality, making errors easier to accept wholesale. After production, schedule a dedicated “find the errors” review, not a “check the look” review.

Conclusion

Data visualization fails by misleading — the data is true, the presentation distorts it. These errors are visible, checkable, and processable. The cost is a wrong decision.

Knowledge visualization fails by misunderstanding — the presentation is fluent and the mechanism is wrong. These errors are invisible, hard to find, and impossible to process away. The cost is a person whose understanding is now wrong, who doesn’t know it’s wrong.

The responsibilities are entirely different. The first is accountable to readers, and must intercept the error before it misleads them. The second is accountable to students — and students lack the ability to check your work.

Building knowledge visualization means forming someone else’s understanding on their behalf. That weighs considerably more than drawing a chart.

---

Real cases cited here come from The Paper’s visualization fact-checking coverage, the UK Office for National Statistics’ chart guidance, and Willett et al.’s experimental research on narrative visualization.