Published on <a href="https://blog.prototypr.io/the-curse-of-knowledge-in-products-45c1faafff9f?source=rss----eb297ea1161a---4">| Prototyping: From UX to Front End &mdash; Medium</a> Ellen Twomey 
Intro / What is the curse of knowledge?
Knowing your users is harder than you think…because you have 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 know 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 they already know?! The truth, however, is what we already know is not relevant when we are discussing what users’ needs are. Not yet anyway. Just because you are 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 we 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. The other component of this is that being focused on the user means, continually being focused on the user. It takes so much 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 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 chatbot 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 their round of user 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 watch some of the live recordings of the 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 the features that they could have access to.
So they did. They called the testers up and told them about all of the great features that the product had for the users. 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 biasesd 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!. But 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, you might have the best engineers in the country, but it won’t sell unless users understand and pay for the problem that a product solves). 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-centric product. They paired down featured, streamlined the UX, and created clarity through UI. The product shrunk in size and grew in popularity. The techie, 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 that situation.
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 a developer’s fault. 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 important aspects of the product for the user. The UX designer needs to effectively communicate the user to the dev team, otherwise all the ux designs in the world won’t have much of an impact.
Conclusion / overcoming the curse of knowledge
Empathy is word frequently used in the UX world. I like the word and believe it has value, 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. We may also use mechanisms (actions) to overcome our intrinsic biases about how we want our product to be see or viewed or use. That is why Dave Gray of XPlane created the Empathy map canvas
<img alt="" src="https://cdn-images-1.medium.com/max/825/0*LNxJqPTtKaB4FRyl.">
.
“If you want great design, then empathy for customers is the single most important ingredient.” — Dave Gray of XPlane
RAH
The Relentless Advocate for Humans approach to UX is based on overcoming this 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 centers 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 will allow the developer to be connected to the user. Continually remembering that the product team is there to solve a problem for someone outside of the team will enable directional 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 <a href="http://xplaner.com/">http://xplaner.com</a> or on Twitter @davegray
<img src="https://medium.com/_/stat?event=post.clientViewed&amp;referrerSource=full_rss&amp;postId=45c1faafff9f" width="1" height="1" alt="stat?event=post.clientViewed&amp;referrerSou">
<hr>
<a href="https://blog.prototypr.io/the-curse-of-knowledge-in-products-45c1faafff9f">The Curse of Knowledge 
(in products)</a> was originally published in <a href="https://blog.prototypr.io">prototypr</a> on Medium, where people are continuing the conversation by highlighting and responding to this story.

The Curse of Knowledge (in products)

Top Stories