Once you know the answer to something, it seems obvious. If you’ve ever played a party game where the goal is to decipher the unspoken rule, you know this. If you’ve been in this situation, you also know how frustrating it is when you can’t figure out the secret.

I once played a game where you had to draw invisible lines across the room. Some of them “worked,” and some of them didn’t. Only two people knew the rules that made certain lines work, and everyone else had to figure it out. One by one, everyone figures it out, watching how the game is played and proposing line placements to test different theories. Frustration mounts as more people crack the code until only one player remains. The people who know how the game works begin speaking slower and louder, attempting to make the answer more obvious, but it doesn’t help. They have what Steven Pinker calls “the curse of knowledge.”

Pinker says, “the curse of knowledge” is “a difficulty in imagining what it is like for someone else not to know something that you know.” Psychologists call the same phenomenon “mindblindness.” In the setting of the party game, once you’ve figured it out, you can’t believe it took you that long because the answer was right there the whole time. In other settings, like UX/UI design, this can result in interfaces that seem easy to use but baffle the user, making them frustrated and feeling like the last person playing the game to decipher the rules.

In UX/UI, recognizing the curse of knowledge is vital to positive interactions with the user, and it applies to far more than just the interface. When teams develop specifications for a project, they often establish specific language that applies to its unique features. While the team quickly adapts to its use, they forget that the user has no prior experience. Words and phrases that have become commonplace for the team are foreign and confusing to the user.

Userpeek.com offers multiple strategies to prevent the curse of knowledge from negatively impacting user experiences. Their main points, knowing your user, asking for feedback, and test running, are variations of the Design Thinking process.

Knowing your user comes with the very first step of Design Thinking; empathizing. Rusul Alrubail from Edutopia.com explains that empathy helps us understand and feel the same feelings that someone else is having about their problem, circumstance, or situation. Taking the time to empathize with the user reminds us what they know (or don’t) and how that will impact their experience.

The second suggestion from userpeek.com is asking for feedback. Gathering feedback can occur during multiple phases of the Design Thinking process but most commonly occurs when defining and testing. In the define stage, the goal is to understand the problem in as much detail as possible while distilling it into a single statement. One of the most effective ways to generate a problem statement is to observe users interacting with the interface (or other problem), watching their reactions, and asking them to talk through what they’re thinking.

Designers can take a similar approach in the testing phase to refine the interface further. Interfaces are more efficient and require less refining after the test phase if feedback from the defining step is considered throughout the process.

The more measures taken to understand the user’s point of view and amount of knowledge, the more time, money, and frustration will be saved. The last thing any designer wants is their user to feel like the last person at the party to figure out the unspoken rules of the game.