Wikipedia says that the curse of knowledge “is a cognitive bias that occurs when an individual, who is communicating with other individuals, assumes that they have the background knowledge to understand.”
I’ve suffered that curse on various occasions, but I think I might have a way to reduce its frequency.
Know your audience.
Thank you for visiting.
Just kidding. There’s more.
Knowing your audience is one of the first things we teach technical writers, but that advice doesn’t quite address the nuance required to vaccinate yourself against the curse of knowledge.
Here are few steps I’ve used.
Step 1. Empathize with your audience
It’s more than just knowing them; it’s understanding them in the context of reading your content. This interaction might be minor in your reader’s experience, but it’s the reason you’re writing technical documentation. It’s extremely helpful to understand your readers in the moments of their life in which they’re reading your documentation.
Know why they’ll be reading your documentation or even just a topic in your documentation. What brings them to that page? What’s their environment like? What pressures are they under? What are their immediate and long-term goals? What would they rather be doing instead of reading your doc?
The reality is that most readers would rather be doing almost anything else but reading technical documentation—so, how can you work with that (besides not writing it)?
Readers might want to do anything else but reading your documentation, but here they are, reading it for some reason. What is it?
Knowing why they are there can go a long way towards making their visit to your docs one worth making.
Step 2. Know how they know what you assume they know
The disadvantage of writing, especially technical documentation, is that the reader can’t [easily] ask you to clarify something in the way that they might in a conversation. You have to anticipate what questions might they ask. Do you know them? Do you answer them? Do you answer them at the point they would ask it? Will they know what you’re talking about? How do you know the answer to that? Can you trace that knowledge back to its source? Is that source of knowledge some other content of yours?
Assuming the reader knows what you’re talking about is the definition of the curse of knowledge. Knowing, instead of assuming, is a powerful antidote to the curse.
Step 3. Test your writing
If it’s at all possible, test your writing on someone with a background similar to your audience. Get their feedback on anything that wasn’t clear or that they didn’t understand. As Wernher Von Braun said, “one good test is worth a thousand expert opinions.”
Because you’re only bringing one expert opinion to this, if you do the math, that’s only 1/1000 the value of a test.
How I use this in real life
These are some of the practical ways I try to defend against the curse of knowledge while gaining the knowledge to write.
- How do the customers know what they know?
Ask the subject matter experts about how the customers know what they tell me they know. Sometimes they can tell me, sometimes they can’t. Whether or not they can tell me, I still need to collect more information on this. - Tell me more about the customers…
I’ll ask myself and other about how and where the readers will be using the information in the topics I’m researching. What are their goals? Use cases? Environments? If you have access to user research (preferred) or market research (better than nothing for this), that can give you some insight so you can ask better questions.
One thing to keep in mind is that interacting with the documentation is different from interacting with the product (except when the documentation is the product, but let’s assume that’s not the case for this). - Take my time
I try to allocate the time to do this. This process is more time consuming than making assumptions, unfortunately; however, it produces a better experience for the reader. Operating on assumptions is always faster, but not as often is it correct. - Walk a mile in the customer’s shoes
I put myself in the shoes of the reader. I imagine their situation, pressures, and goals while reading the content. For example, I’ll be impatient, and distracted if that’s how the customers will be reading the docs. Do they still work? Can you understand the topics and trace them back to where your research (or assumptions if that’s all you have to work with) suggest your readers are starting from? - This isn’t a test
If pressed to write content without knowing the audience, I assume they know less than I think they do (or what others have told me they know). Reading documentation shouldn’t feel like a test of the reader’s knowledge, so I try not to assume they have much. This is especially true for new products or features.
It’s the exception to the rule that a feature or product will have many experts (that didn’t work on building the feature) just after its release. - Testing! Testing! Does this thing work?
Finally, I’ll reach out to others to review and test the content. I also ask everyone I can ask to review it. New members on the team are great resources! - Get to know the people whose job it is to know the customer
I try to develop connections with the user research team and data to help develop my image of my audience. Ideally, meet a few, if I can. I’ve found that accompanying the user researchers in their user interviews is a big help.
This isn’t a guaranteed vaccination against the curse of knowledge, but I’ve found that it helps reduce the symptoms.