User experience design and an outside perspective can help your team overcome the curse of knowledge.

What is the curse of knowledge?

The curse of knowledge is a cognitive bias that occurs when, in predicting others’ forecasts or behaviors, individuals are unable to ignore the knowledge they have that others do not have, or when they are unable to disregard information already processed.

How do you know if you’re suffering from the curse of knowledge?

It happens to all of us. The longer you and your team work on a problem, the more everyone learns about the subject matter. Over time, you cross the threshold from newbie to expert. Your head is filled with a wealth of information about your area of expertise. You’ve been immersed in the subject for so long that you may forget that not everyone has the same level of understanding that you do. When it comes to product design, the key to success doesn’t rest only on expert knowledge, but having empathy with your users.

If you’re not careful, the curse of knowledge can choke out empathy and lead to some negative effects for your end users. It can be tough to diagnose, so it helps to invite an outsider into the picture. Bringing in research, design, and usability experts helps your team look at things from the user’s perspective. A methodical, scientific approach to user experience design can help you overcome some of the common problems. Here’s how I and the rest of the team at Visual Logic help our clients:

Look at Things with Fresh Eyes

When you’re working on a hard problem, it’s easy to get stuck. In those moments, it’s very helpful to have an outside perspective. At first, it may feel counterintuitive to stop and slow down to explain a complicated problem to someone else, but it really does pay off. A fresh set of eyes can often quickly point out alternate ways to proceed. As an outsider, I’m not constrained by the knowledge of what was done in the past. I’ve also learned to not be afraid to “ask the dumb questions”. Assumptions are the foundation for the curse of knowledge. Even if I think I know the answer, it’s important for me and everyone else to challenge those assumptions. Everyone needs to be aware of the “why” behind what we’re trying to accomplish. I like to think of this process almost like detective work. We’re investigating things from all angles, talking to all the witnesses and making sure we have a full understanding. Once we break down the assumptions and look at the big picture objectively, we start to notice opportunities. These breakthroughs can lead to innovation.

Do you remember what cell phones were like before 2007? They were covered with buttons, the software was clunky and complicated, and the experience was dominated by the interests of the network providers. I remember how annoying it was to switch phones. The carrier would often charge you to move your contacts to your new phone. Since I didn’t want to pay, I always had to manually re-enter my contacts. Think about voicemail and how you had to listen to the menu options and press 1 to delete, 2 to replay.

A Blackberry phone from 2008.

In 2007, everything changed when an industry outsider released the iPhone. Apple reimagined what a phone could be by focusing on the user. They addressed many of the pain points that phone users were experiencing. Now your contacts are saved in the cloud, so switching phones is simple. They introduced visual voicemail to make checking your messages easier. The user interface was intuitive, the design was appealing, and suddenly people were willing to wait in long lines and pay actual money for their phone (do you remember getting a flip phone for a penny?). Apple gave the entire phone industry a set of fresh eyes when they released the iPhone. Up until that point, the phone industry wasn’t focused on helping their users. They were sticking with what they knew, protecting their interests and propping up the status quo.

If you stay vigilant and fight off the curse of knowledge you can avoid being surprised by innovations from your competitors. Stay focused on your users, and your product will be the one leading the way.

Speak the Language of Your Users

Industry jargon is fairly common in software design. At some level, your team of experts probably communicates using jargon, acronyms, and abbreviations. If you’re surrounded by people who speak that same jargon, over time everyone forgets that users may not speak about things in the same way. If your internal jargon makes its way into your product, you may be needlessly confusing your users. You end up creating a new language system that users have to learn.

A few months ago, I opened a new IRA account with Fidelity. It was fairly easy to create my account, but after that, things got confusing for me. I wasn’t familiar with a lot of the terminology being used. I’m not a complete newbie to investing, but I sure felt like one as I tried to figure out the system. It was clear that it was not designed with me in mind. The jargon was a roadblock for me. In fact, I still haven’t finished setting everything up (I need to get on that).

I’m not trying to pick on Fidelity. A lot of financial institutions are in the same boat. It’s a complicated industry. If I were to work with them, I would start to address these problems by doing some usability tests on some of the common tasks. Interviewing and testing 3-5 new users would clearly identify whether people understood the language used in the system. The discussion would also give the product team valuable insights into how users view and interpret things. Once the team becomes aware of these communication barriers, they can start to make better design decisions.

Always Pursue Simplicity

Experts often lobby for highly-advanced tools with tons of options and customizations, and they’re very vocal about their wishes. As an expert in your product’s domain, you probably identify with those advanced customers. The curse of knowledge could lead you to believe that everyone else wants those advanced features too.

Complying may make a handful of advanced users very happy. The problem is that you end up designing to account for a host of incredibly rare situations or a very small audience. If you follow that path, you may end up missing the mark with a majority of your users by giving them a bunch of [expensive] features they don’t really need. Plus, the learning curve of your product will be steeper; you’ll probably spend a lot of time fielding support calls and writing help documentation.

Recently, I read a transcript from a conversation between UX professionals Jared Spool and Jeff Gothelf. Jeff was was describing his favorite photo of a customized guitar and how it was a perfect metaphor for overly complicated product design. Here’s how he explained it:

“It was a guitar that was custom made for Pat Metheny. It has dual necks, and 18 or 20 different strings on it [actually 42 strings], a variety of knobs and controls and so forth. I always reference it as the Microsoft Word version of a guitar. 95 percent of the things that are included in this particular guitar are useless to 95 percent of the population. Only a couple of people can actually use a hundred percent of these things.

Microsoft Word is exactly the same way. We all use the same 10 features. There’s a thousand other ones that only five other people use.”

The “Pikasso”, a 42 string custom guitar built for Pat Metheny.

Pat Metheny is an expert guitar player. He’s on a different level than most players. Can you imagine handing this guitar to someone who was just starting out? Even most experienced players would be intimidated by this guitar. Jeff’s example is the perfect illustration of what can happen to your product if you’re taking direction from the Pat Metheny of your industry. You end up with a design that works for a handful of experts or advanced users. If your product intimidates most people, they will probably look for a different solution.

Make Data-Driven Decisions

An outside UX design agency can help an organization break free from opinion-based decisions. It’s tempting for organizations to skip research or testing and rely on internal team members’ expert opinions to inform design decisions. Sometimes that works out, but it is a risky way to operate.

The process we follow at Visual Logic gives stakeholders valuable data on which to base decisions. Each design is tested, and the results validate or invalidate the design before any production code is written. And that considerably lowers the risk of building the wrong thing.

I want to be clear that I’m not at all diminishing the value of experience and industry knowledge in product design. They are critical, but you need to balance that with a process that ensures that you look at things from your customers’ perspective.

Is your team spinning its wheels? Are you concerned that the curse of knowledge may be holding you back? Tell me about the challenges you’re facing.