The Curse of Knowledge

Jared Turner
This article is also available in: español

Ever played Charades and acted out the perfect mime to ‘James Bond’, only to be met with blank stares? That moment when you wonder “Are my friends fools!?”, that’s the curse of knowledge.

Your friends witness your mime without any additional information and are confused. But you act it out already knowing it’s James Bond. In your head you see a debonair Daniel Craig, tuxedo on and martini in hand. It’s so obvious, you think, why don’t they get it? Shocking, positively shocking.

We are all cursed

The curse of knowledge. Once you know something, it’s hard to remember what it was like to not know it.

This leads to a huge amount of communication frustration. You’ve encountered the curse of knowledge if you’ve ever directed someone to the official documentation to solve their problem, only to have them return scratching their head. They are lacking the extra context that you have built up, possibly over years, that allows you to see the answer in the documentation.

Here, there, and everywhere

The curse of knowledge is pervasive. Once you see it, you will notice it all over:

  • Jargon, idioms and colloquialisms: Telling a colleague with English as their second language that you think their idea is “the bee’s knees!
  • UX: Jump into your new car and try to adjust the air conditioning. There’s always a learning curve while you adapt to the new UI. A month later, shake your head when a friend joins you in the passenger seat and can’t, for the life of them, work out how the air conditioning works.
  • Pairing: Working through a codebase without verbalising your thoughts and actions leaves out a tonne of context and will leave your pairee confused.
  • Code: Encountering working code for which you have no idea what it does. The author certainly knew at the time, but their implementation belies understanding.
  • Note taking: Looking back at a note you wrote from last week and having no clue what you meant. You lack the context you held in your mind at the time the note was jotted down.
  • A special mention for corporate websites that use language that seems so vague as to be meaningless. The C-level team have, over decades, built up a notion of what this extremely vague phrasing means, but to outsiders it is completely useless.

What’s the cure?

While there is no single cure, there are a bunch of techniques we can use to try and avoid the curse of knowledge:

Examples

When we spot a pattern, we reach for abstractions as a way to generalise. When everyone understands these abstractions it allows us to take shortcuts and communicate faster! But if someone doesn’t understand the abstraction they may feel lost.

Perhaps this whole discussion about abstractions is confusing to you? But what if I give a couple of examples?

  • We don’t talk about “bipedal mammals that aren’t apes”, we say “humans”.
  • Teams may talk about ‘Boring solutions’ but this 2-word phrase actually encapsulates an entire ethos about choosing technology that is mature, stable, and not the 'new hot thing’.

Abstractions are great, but giving clear, concise examples helps to get everyone on the same page (to be ‘on the same page’ means to have the same amount of knowledge. Aaaah, when does it end!?).

Tests & feedback loops

If you’re writing a How To guide, ask a few users to go through it. Watch them, take note of where they struggle, improve the guide, test again.

A lot of our best practices around user testing are born from our learnings around avoiding the curse of knowledge. When watching a user test it’s easy to fall into the habit of: “Why don’t they know where to click? It’s so obvious. The problem is definitely the user and not my UI.” But this completely avoids the value of the user test. The user is confused; we have an opportunity to make things better!

How it feels to watch a user test your product for the first time.

Code review is another great example. It can be humbling to push up a PR you’re really proud of only to have a colleague comment saying, “I don’t get this”. Humbling, but rewarding, as it gives you the opportunity to produce even clearer code!

Empathy, audience and context

A lot of this can be encapsulated in the idiom ‘know your audience’. Don’t assume the other person knows what you’re talking about. Consider what they know and what they might not know. When in doubt, over-communicate and over-explain.

Continuously look to improve your communication

When you explain something to someone and they look confused, it’s easy to become frustrated and think, “Why don’t they get this?”. Instead, dig into why they don’t get it and think about how you can explain it to avoid the confusion. This all comes down to ensuring the right level of context. Too much and you’ll end up explaining the English language, too little and you’ll have confused faces.