This week’s Tighten This! game exposed a pitfall that good technical writers learn to identify and avoid: the curse of knowledge. Let’s talk about how that plays out in our day-to-day work.
The curse of knowledge strikes when we become experts in the subject we’re describing, and we forget that others — especially our readers — don’t share our expertise. What’s become obvious to us, isn’t at all obvious to them.
Our subject-matter experts have the curse of knowledge. Our readers count on our not having it.
Mark Baker says that the antidote to the curse of knowledge is domain awareness:
Domain awareness means not only knowing the subject matter of your domain well, but also understanding your domain as a domain and its place in the universe. It is only in a state of domain awareness that you act as a useful and reliable tour guide to your domain.
In practical terms this means putting your subject matter into the context of what your readers already know. It means giving them stories and signposts so to help them relate the new ideas and new skills to what they already know..
As you move from novice to expert, you must never forget that your readers need those stories and signposts.
Day in and day out, how can you elude the trap of the curse of knowledge?
Remember how it was when you learned the subject matter. Remember the questions you had to ask. Remember the things you struggled with. Fortunately, it probably wasn’t too long ago, so the memories are fresh. Now, write the way you wish someone had written for you.
Get as much hands-on experience as you can with the subject at hand. If you’re writing about a bicycle, ride it. Change the tires. Take apart the gears. If you’re writing about software, use it to do the same tasks your readers will do. Write down every step, no matter how obvious or “intuitive” it might seem. (As experienced designers know, things designed to be intuitive rarely are.)
Get a trusted friend or colleague to review your work. Find someone who doesn’t have the same expertise you have. Encourage them to point out gaps in explanations, or missing steps in procedures. Those are the places where you forgot to provide a needed story or signpost.
Test your assumptions. As I develop expertise in a subject, I go through stages. First I’m a newbie and I know it. Then I find myself asking a ton of questions. Then I go “aha” and I think I’ve grasped it. Then, usually, I discover that I still have a ways to go — and I might progress through a series of “aha” moments until I finally arrive at full knowledge.
The first “aha” stage is a dangerous place for me: it’s where I make assumptions that later prove to be simplistic, if not totally wrong. That’s why I have to test my assumptions — usually by bouncing them off the true experts, the SMEs.
Do you run up against the curse of knowledge in your work? What techniques can you suggest for eluding its fell clutches?