The Curse of Knowledge in design: a bias that distorts communication
How knowing too much about a subject hinders your ability to communicate effectively.
Designers often find that knowing too much about our users can curse us.
We often observe people behaving unexpectedly during user testing, like deviating from expected workflows or voicing surprising opinions. While this knowledge is valuable for gaining user insights, using it effectively can be challenging.
You might hear an opinion about your users that you know to be wrong but fail to persuade your team to change their minds. Or you might speak excitedly about something you observed, only to receive a sea of blank faces.
This is known as the Curse of Knowledge, where a deep understanding of a subject hinders your ability to communicate effectively.
If you've ever encountered this, here's how to address it.
Why the Curse of Knowledge happens: facts vs opinions
The Curse of Knowledge often rears its' head because you assume other people have the necessary context or knowledge to follow what you're communicating.
You've seen users behave a certain way, so it couldn't be clearer that this is a fact: users do X, or they don't do Y.
However, an outside observer might think this is your opinion because you don't have the exact quotes, user insights, and links.
If what you are saying sounds like a Designer's opinion, your team may listen to it. However, your opinion doesn't outrank a product manager's or a HiPPO's (a highly paid person's opinion).
One of the first things you need to do is take a deep breath and show others that you're communicating based on user facts. Here's a three-step method for doing that.
Establish common ground: Summarize the "Why"
In Articulating Design Decisions, Tom Greever highlights one of the most essential things any Designer needs to do at the start of the conversation: Establish Common ground.
This action is necessary for communication to be cohesive and start on the right foot. One of the most important things to do here is to rephrase and summarize the problem in a design-neutral fashion.
For example, if your Product Manager says, "As a user, they're probably going to want some way to avoid accidentally deleting something, so let's add a triple confirmation to our Modal actions."
There are two parts to this statement, and we only want to talk about one:
The problem: We are concerned about users accidentally deleting something
The (poor) Design Solution: Let's add triple-confirmation to all of our Modal actions
If the team took the time to voice this problem because they feel something is important here, meeting them on this common ground would be essential. Jumping instead to "No, you're wrong" doesn't seem like an opinion: it feels like you're not hearing them.
The first step is to summarize the problem and show that you're listening to what the other person is saying (at least partially). For example, you can say, “So what I’m hearing is…"
“So what I’m hearing is that there are concerns that users will accidentally delete something."
After establishing that topic, we can then elaborate on the problem.
Frame the problem by asking the right questions
The next step is to frame the business problem in a way that helps you figure out the design solution.
Based on the problem you summarized about, there may be a couple of follow-up questions that you might want to ask:
Why would users want to delete something in the first place? What's the use case for having a Delete button?
Before deleting, can we not have a “Temporary Delete” option, like Moving files to Trash?
Is creating something hard (i.e., if it’s complex to set up, we don’t want to touch it)?
Does creating something involve dependencies, where accidental deletion can affect many other processes?
Etc
Asking these questions allows you to understand the business problem in more depth, frame it so that you can identify the right design solution, and reference targeted feedback.
For example, rather than linking all feedback related to “Deleting something,” understanding that this is primarily a dependency issue may help you find a User Quote or answer that speaks directly to this issue.
At this point, you might be able to provide this statement:
“So what I’m hearing is that there are some concerns about users accidentally deleting something. We’re mainly concerned about dependencies: if they delete the wrong thing, it can potentially affect dozens of other things as well.”
After that, it’s time to lead into talking as a mouthpiece for your user.
Fixing Cursed knowledge means knowing It’s not you, it’s the user
Remember, Cursed knowledge issues often stem from the fact that it seems like “Your opinion” rather than facts from the user.
So, one way to avoid this issue is to remove your ego: think of yourself as the mouthpiece of the “User.
You’re not voicing your opinion; you’re voicing what the user thinks in response to a poor solution. After all, you’re paid to advocate for the users who can’t attend every meeting or give feedback on every design decision.
Hopefully, the business problem is clear enough that you can find user quotes, findings, and other information that might clarify these ideas.
For example,
“I’m hearing some concerns about users accidentally deleting something. The main thing we’re concerned about is dependencies: if they delete the wrong thing, it can potentially affect dozens of other things.
We’ve heard some user feedback about the issue, and I can send detailed feedback to you later. However, our users aren’t going to appreciate that: we’ve heard too many times from our users that the process is already too long. Adding too many extra steps to the process will cause a lot of user friction.”
Doing this can help you avoid Cursed Knowledge issues.
You are the user expert: explain it to your team like novices
The most important thing to realize when you work and analyze user feedback is that starting this process will make you an expert.
It doesn’t matter if the analysis took 6 hours or six months; you’re speaking to people who are just seeing the data for the first time (or even hearing about it).
So, one of the most important things to do is always remember that you should explain it to your team as though they are hearing about this for the first time: sometimes, that is the case.
Instead, it would be best if you remembered to do your best to ensure that your knowledge about the subject doesn’t become a curse; it’s instead a boon that can help you and your team avoid being thought of as heavily opinionated people (without any thought about the user).
So, next time you hear an opinion or viewpoint that is wrong based on your users, take a moment before you speak up and check to see if this is the curse of knowledge speaking.
If so, you should always bring more context to the level.
Kai Wong is a Senior Product Designer and Creator of the Data and Design newsletter. His book, Data-Informed UX Design, provides 21 small changes you can make to your design process to leverage the power of data and design.