If You Don't Understand Me, It's My Fault

Communication is the art of taking a concept from the mind of one person and reproducing it in the mind of another person. The copy is never exactly the same as the original, because concepts are defined in terms of the collection of concepts around them, and no two people have exactly the same collection of concepts.

Even what seem to be the most precisely defined concepts, such as "one", have different nuances to different people. My concept of "one" includes the fact that it is the successor to zero in the Peano construction; perhaps your concept of "one" includes the fact that it is the name of a song; someone else's concept of "one" has some different attachment that neither of us knows about.

Most of the time we have little trouble communicating in spite of the differences between each of our concepts. Our communications typically use the intersection of multiple concepts to reduce the ambiguity to the point where we can act in concert towards common goals. Most of the time, most of us don't concentrate on our communication, particularly verbal. We just talk and expect the listener to understand.

But sometimes it doesn't work so easily. Sometimes we make our statement, or give an explanation, expecting the listener to nod his head in agreement and understanding, only to see a puzzled expression instead. What do we do then?

If I explain something to somebody and he does not understand, there are a couple of basic reactions I might have:

1. I can get annoyed with the other person for being so dense, not listening, or otherwise failing to understand me.
2. I can ask myself why the other person does not understand me and try to figure out how I can reword what I am saying so that he does.

I have certainly run across people who tend to take the first approach. The cliche such situation is where somebody says something to a person who does not speak his language, and when the listener indicates a lack of understanding, the speaker repeats what he just said, but louder and more slowly - and with continued lack of understanding, yet louder and more slowly.

I have found it much more constructive, and in the long run more satisfactory, to adopt the attitude that if you don't understand what I am saying, it is because I am not explaining it well enough. Rather than repeating myself more slowly, carefully choosing different words is more likely to improve communication.

Assuming that the burden of communication is on me as the explainer is of course more work than assuming the burden is on the other person to understand me. If I assume it is the other person's job to understand, and he does not, then I can just stop trying. But if I assume it is my job to make the other person understand, and he does not, then I have to figure out why the other person does not understand, and tailor my communication based on that knowledge, which can sometimes be a significant task.

In order to tailor my communication to one person, I have to take some time to learn more about the concepts that person already holds. This means asking questions, listening carefully to the answers, and observing the non-verbal communication. If I can understand his concepts, I have a better chance of wording my concept in such a way that it fits in more easily with his existing concepts, which in turn improves the chance that he will understand my concept. Sometimes the problem can be resolved with one or two questions. Sometimes it takes much longer.

I can adopt the same attitude when addressing a group of people. If I start with the assumption that it is my job to get my concept across, rather than their job to understand me, I am motivated to put more effort into my delivery. As when communicating with a single person, I can solicit feedback from the group and try to understand the concepts that are generally held by the people in that group, then use that knowledge to tailor my talk. By doing so, the overall understanding within that group of what I am trying to say is likely to be much better than if I speak without taking any questions or other feedback.

Realistically, there is a limit to how far one can take this attitude and remain practical. If there is too large of a gap between your subject matter and the knowledge already held by your audience, you will not be able to get the entirety of your concept across until you spend the time to close that gap, which in many cases may not be feasible. Even so, if you start with the attitude that it is your job to get the concept across, and you are diligent in understanding your audience, you can get across more than you might think. With a good understanding of your audience you can adjust your delivery to the level that fits in with your audience's current concepts, delivering as much of your concept as the audience is capable of absorbing at the time.

Richard Feynman was famous for being able to explain advanced physics, including quantum mechanics and relativity, to first and second year college students. His attitude was, if he could not explain something in a way that was simple enough for his audience to understand, then he himself did not understand it well enough. When he found himself in that situation, he would go back to the drawing board and come up with a better way of explaining it so that his audience would understand. Feynman accepted that it was his job to explain his material at the level appropriate for his audience, and if he was unable to do that then he had failed at his task.

A similar attitude can also be applied to a user interface, whether for a program or a piece of hardware; or, for that matter, to any product: if you as the user of my product do not understand how to use it, it's my fault. It is thus incumbent upon me as a designer to understand how you, the user, think when using my product so that I can better fit in to your usage concepts and thus make my product easier to understand. This is one of the first points of Donald Norman's "Design of Everyday Things": if you as the user can't figure out how to use a product, it's not your fault, it's a bad design. Don goes further, saying that problems blamed on "human error" or "operator error" are usually also due to poor design that made it too easy to make the errors.

In the same way that trying to explain a concept without feedback is more difficult than explaining the same concept when the listener can ask questions, creating a product without seeing someone trying to use it makes it much more difficult to create a usable product than if you can get some feedback when creating the product. Creating a product is like making a presentation to a group of people: you have to listen to their feedback and understand their concepts in order to shape your product to fit in well with what they already understand how to use.

It is for exactly this reason that usability labs are so valuable: they allow users to provide feedback during the creation of the product so that you can tune the product to make it easier to use. If you don't do usability testing, and your users subsequently have problems using your products, you can't really place the blame on anyone but yourself. You don't need a big expensive lab; but you do need to put your product in the hands of some potential users and see how well they can use it without any help from you.

The next time you find yourself getting annoyed with someone because he did not understand something that was so obvious to you, or the next time you hear about someone who was for any reason unable to use your product easily, stop and think about how you might be able to change your message or your product to more easily fit into the other person's mindset, rather than expecting them to bend their concepts to fit yours.