The Curse of Knowledge is a concept in a book called Made to Stick: Why Some Ideas Survive and Others Die. The curse of knowledge concept has generated quite a bit of buzz. Here’s an excerpt, which I got from 37 Signals:
People tend to think that having a great idea is enough, and they think the communication part will come naturally. We are in deep denial about the difficulty of getting a thought out of our own heads and into the heads of others. It’s just not true that, “If you think it, it will stick.”
And that brings us to the villain of our book: The Curse of Knowledge. Lots of research in economics and psychology shows that when we know something, it becomes hard for us to imagine not knowing it. As a result, we become lousy communicators. Think of a lawyer who can’t give you a straight, comprehensible answer to a legal question. His vast knowledge and experience renders him unable to fathom how little you know. So when he talks to you, he talks in abstractions that you can’t follow. And we’re all like the lawyer in our own domain of expertise.
Here’s the great cruelty of the Curse of Knowledge: The better we get at generating great ideas—new insights and novel solutions—in our field of expertise, the more unnatural it becomes for us to communicate those ideas clearly. That’s why knowledge is a curse. But notice we said “unnatural,” not “impossible.” Experts just need to devote a little time to applying the basic principles of stickiness.
JFK dodged the Curse [with “put a man on the moon in a decade”]. If he’d been a modern-day politician or CEO, he’d probably have said, “Our mission is to become the international leader in the space industry, using our capacity for technological innovation to build a bridge towards humanity’s future.” That might have set a moon walk back fifteen years.
This book is so relevant to technical writers. In my recent interview with Thom Haller, he mentioned how familiarity is one of the main things that gets in the way of clarity. This is a total paradox, though. The more you know an application, the better poised you are to write a good help file. But the more you know an application, the more familiar you are with it, and so you are less likely to write a good help file.
The trick is, how do you know what you do not know? How do you maintain the fresh perspective of one who is seeing for the first time?