Published on | Prototyping: From UX to Front End — Medium Ellen Twomey Photo by Glen Noble on Unsplash

What is the Curse of Knowledge?

Knowing your users is harder than we think…because we are plagued with the curse of knowledge.

The curse of knowledge is rarely if ever a curse about knowing your users too well. The curse of knowledge is knowing your product too well. Knowing it the way that is, makes it hard to change it and adapt it to the needs of the user. When building a new product, the main curse of knowledge that occurs is the curse of what the product team already knows. Namely, their capabilities.

The team member’s individual contributions can become the leading indicator of how the software is designed. There is comfort in what we know. Who wouldn’t want to put to use what we already know?! The truth, however, is what we already know is not relevant if we are focused on users’ needs. Not yet anyway. Just because an engineering is really good at writing a topological sort algorithm doesn’t mean that is what the user needs. The product team may have to adapt or learn new skills to adjust to the user needs. This is a positive. It keeps team members growing, learning and becoming more valuable.

This is why it can be helpful to bring in consultants or have coaches. They are our “fresh eyes.” They take us out of what we already know and help us to remember what is possible (the good ones, anyway!). We need the same thing when building a product. We get caught up in all of the cool stuff that we as a product team can do, and we forget that what we should be doing based the user’s needs. Being focused on the user means, continually being focused on the user. It requires effort, focus, and persistence to constantly ask, “how is this helping the user?” at every sprint planning, and even frequently at daily stand ups.

Story

Setting
Once upon a time in the highly techy and slightly hipster city of Durham, North Carolina there was a team of highly skilled software engineers. They were full-stack developers who had many years of experience and GitHub submissions numbering in the tens of thousands. They could breathe code, spew algorithms and summon database retrievals.

Characters
The amazing part is that the possibilities for a product were endless. The problem was that the possibilities for a product were endless. Ronny, a 10 year engineering vet, said that the new product should have machine learning (initially but then scale up to full 2.0 artificial intelligence), have a repository of services that could be customized by the user (you know, like AWS), and a chat bot with algorithmic service recommendations personalized to the user. Scrum Master Jean said that the product should be bug free, have full stack automated testing, and be delivered in 6–9 months. Jackie, a newbie to the group, but still an excellent engineer in her own right thought that the machine learning was an excellent idea, the application should be built with RoR (Ruby on Rails) and should have eCommerce similar to Amazon.

Conflict
They began coding. Releases came flowing out. They knew their product inside and out. The fun was just beginning. And then, they sent their MVP out for the first round of usability tests. It was a complete disaster. The testers had no idea where to find things, how the product helped them, or what the goal was. The engineers watched some of the live recordings of the usability testing sessions. It wasn’t pretty. They wanted to jump in explain the product, tell the testers how the product was supposed to work. Let them know all of the features that were available.

So they did. They called the testers up and told them about all of the great features that the product had for them. Were the users impressed? No. They didn’t care. What did they care about? They cared about how it helped them. Or didn’t. In this case — it didn’t.

Resolution
Then the team hired Jeremy, a UX designer. He asked one question? “What one problem are we solving for our users?” That’s it. Just one question. UX to the rescue! (Am I biased towards UX designers? Yes I am, so Super UX designer it is! Am I suggesting that ALL UX designers will save your products — not by a long shot! If your product does not solve one specific pain point that your users care about enough to pay for, then your product is not relevant. It might be very well implemented, we might have the best engineers in the country, but it won’t sell unless users understand and pay for the solution that the product offers). Jeremy asked this question and the team paused. They weren’t sure. They talked about all of the cool features and the complicated technology, but they did not answer his question. So he asked it again. And Again. And again until the team paid attention. Then he asked it during each sprint planning meeting. Each demo. Most stand ups. He asked it so much others started asking it for him. Eventually, with some solid user testing and aggregated screen recordings, Jeremy was able to move the team towards a user-centered product. They paired down featured, streamlined the UX, and created clarity through UI. The product shrunk in size and grew in popularity. The techy, hipster, Durham product team lived happily ever after with a product that served its users.

Moral
The moral is that features are not really all that important when we think in terms of quantity. A user prefers less, to more — unless the more means more effective. The moral is that we need to start with users. We need to identify a solutions to an unmet need that they have. Or maybe two or three, but not really much more than that. It will become overwhelming for them and no amount of UX can save feature overload.

We also need development to be second. Design needs to be first. Design that is focused on the user will ensure that development stays focused on the right aspects of the user experience. This is not due to any limitations on the part of engineers. They can meaningfully contribute to design, but their main job is to execute on what the user needs by building features and fixing bugs that impact the user. It is the UX designer’s job to keep the team focused on the user by communicating the most relevant aspects of the product for the user. The UX designer needs to effectively communicate the user to the dev team, without that all the UX design assets in the world won’t have much of an impact on building a user-centered product.

Overcoming the Curse of Knowledge

Empathy is word frequently used in the UX world. Its a good word, an important word, however, “being empathetic” is not enough to improve UX. The term is becoming frequently overused so as to lose it’s meaning. In order to ensure that we really think about our users, we need to take the time to think about what they are doing and how they feel about what they are doing. We may also use mechanisms to overcome our intrinsic biases about how we want our product to be viewed or used. That is why Dave Gray of XPlane created the Empathy map canvas

“If you want great design, then empathy for customers is the single most important ingredient.” — Dave Gray of XPlane

Relentless Advocate for Humans (RAH)

The Relentless Advocate for Humans approach to UX is based on overcoming the curse of knowledge that plagues the product world. We have so much knowledge and talent — how can we channel that to build a product highly desirable for our humans?

One small, but important step is to stop asking, “where are we with that feature?” The more important questions center around the user. If we use language that supports the user, such as, “How are we coming along solving user X’s need for Y?” and build stories that are outcome-based that will allow the developer to be connected to the user. Continually remembering that the product team is there to solve a problem for the user, who is outside of the team, will enable focused development that leads to better end products.

******
Thank you to Dave Gray for his contribution to this blog.
You can find Dave on his web site http://xplaner.com or on Twitter @davegray

******
For more information on becoming a Relentless Advocate for Humans to build user-centered products, visit us at http://uxsimplified.com

The Curse of Knowledge was originally published in prototypr on Medium, where people are continuing the conversation by highlighting and responding to this story.

The Curse of Knowledge

Cool stuff, every week

More Articles