How to understand a user? Part 2. User's refusal
5 February 2008 | admin | Psychology
Author: Andrew Morozov
(Or Why does a user speak about a wrong subject or in a wrong way)
A competent developer tries to interact with a prospect user. Both paries are interested in each other: a user will get a usable device or programm, that will make his life easier, a developer will create a product, which will help him fulfill himself and make money. Both parties are ready to interact but certain circumstances occur and lead to conflicts and refusal to exchange information. Let's consider some ways out of such obstacles.
The primary meaning of interaction is limited to communication, i.e. exchange of information. Psychologists found out long time ago that three processes simultaneously take place during communication:
- communication (exchange of messages),
- interaction (demonstration of attitude to the partner and his words)
- integration (change of positions and opinions).
Each process has its peculiarities, but is at the same time connected with other processes and influences their quality. Mistakes in communication occur because of external noise, when the message can't be heard, or because of the errors in coding-de-coding. But the process of communication can also be destroyed if we neglect or ignore our conversation partner - he will simply stop speaking. Misinterpretation of his words can also destroy communication. In other words: any of the three processes can bring efficiency of communication to zero.
Lost in translation (communication)
All specialists use professional jargon in their speech: special terms, contractions and special word order. Terminology allows to contract phrases without losing their meaning. To explain something to an "outsider" you have to use simplier but longer phrases. The problem here is that the professional gets a feeling that he is not making himslf clear. He tries to comment the above said, clarify and specify the most important moments. The topic of discussion gradually drifts away from discussing job peculiarities to clarifying the basics. The developer is annoyed by having to comment the obvious points of his job. The user is annoyed by having to learn something he doesn't need. It feels like an idiot - and who likes it?
When we speak about specific unique terms the best way out is staying calm and consistent. If the developer is tired from explaining everything he can ask for a glossary to be drawn up.
It's worse if the developer starts using professional jargon. The user doesn't want to feel like an idiot. It's easier for him to pretend that he understood everything. It's better to murmur something to the most difficult question: aha, probably, sure. The developer gets an illusion of having understood user needs, but it's just a trick.
The most difficul case for mutual understanding is when common words are used in a specific professional sense. Let's consider the name of this chapter for instance: "User's refusal". It would probably make a technician smile. "Refusa"l in the sphere of technique means that the device won't perform it's functions because of the breakage. It means that the user "broke down". For a lawyer "refusal" means the declaration to refuse to perform certain actions on the legal basis. Here a user has to declare that he doesn't want to interact. "Refusal" in psychology means implicit or explicit unwillingness to participate in interaction. Here a user can directly refuse to interact or hide his unwillingness with different tricks.
There is a plenty of examples of "ambiguous" words. A great part of data bases developer's vocabulary has this unpleasant characteristices. Why unpleasant? Because it creates the illusion of understanding. it seems that both a user and a developer have agreed on everything and understood everything, but they where talking about absolutely different things.
"I prefer the results to be generated in a table" - a user asks. "Sure, no problem" - says a developer. During the testing it turned out that the user meant a screen form, not the mdb file, as the developer thought. Of course, everything can be fixed, but it requires time and even worse, it requires admitting the mistake. Instead of cooperation they start to decide who was wrong. It often leads to direct conflict: they (developers) can't do what we order, and they (users) don't know what they really want.
Who works for whom (interaction)
There's a good rule of business communication: in case of failure the more intelliget one is to blame. If I can't make my conversation partner do what I need it means that either he is smarter and predicts my actions or he has already got what he needed. Or that I make mistakes and the partner can't notice and correct them.
Marketing communication has the same principle: the quality of communication is the responsibility of the person who needs it more. If the buyer needs the gods more than the seller needs the money, the buyer will try to persuade the Seller by looking for arguments, necessary words and even fawning. Quite a usual picture for stores, where salary of a salesperson does not depend on sales. And vice a versa. If the seller needs money, he will be active, persistent and attentive.
Everyday communication has an absolutely different principle: why would I talk to him if he does not understand anything? It's hard to talk to a person who cannot follow your thought, who you need to repeat the same info over and over to, who asks stupid questions. But personal contacts are private business, everybody chooses who he communicates with himself.
Self-confidence of a professional is justified. He has the knowledge that nobody has, can do the work better, quicker and more efficiently . System administrators, programmers, tech support specialists and help desk specialists are hired exactly for their skills and knowledge. However, self-confidence may play an evil trick on a specialist: he starts to demand that others should know and be able to do the same. It might be worth to ask yourself a question: what would I do if users learn to perform my job?
There is another unpleasant side of self-confidence: it urges to demonstrate superiority. Superiority is reflected in the manner of answering, asking questions or making comments. A person can feel when he is spoken to in a haughty manner and will lose any desire to communicate. Only a dependable person will keep such a conversation going - a child, a newbie, a subordinate, somebody who does not feel his professional importance. A mature person, a high skilled professional or an experienced worker will just refuse to talk to an arrogant developer.
Another moment. Why do we need programms, good interfaces, technical devices? A rhetoric question - of course, to free ourselves from routine, to speed up performance, to increase work efficiency. In other words, user expects his problems to be solved. Solved, not created! When, instead of increase in efficiency, user comes across the problem of wasting time, necessity to correct or re-do the same task, he becomes angry. It is psychologically difficult for him to talk to the culprit of these problems. He has a strong argument: I used to perform my job without this software and had no complaints.
About money and clients. Only entertainment software makes money directly. In other cases it's a user, who makes money. He shares his money with programmers only because their software allows him to make more money or to reduce the workload. A client pays a user for his skills, experience and knowledge. The user has already persuaded a client, found approaches to him and got his money. Now everybody serves the user, they have to explain to the user, why he should give a certain amount of his money to somebody else - accountants, programmers, security staff, cleaners. All these people usualy realize, that perform auxiliary functions. Accountants, programmers or plumbers often think that the whole enterprise is created only for the sake of writing financial reports, maintaining the coolest database and maintaining the water system. Such an illusion results in negative attitude to the representatives of these professions.
But let's leave all the above behind for a while, and imagine that a developer's behaviour is correct and professional. He found the necessary user, introduced himself, behaves politely, asks understandable questions and calmly answers the questions. Seems like verything is ok. But, for no particular reason, user starts to hurry, he is annoyed and sidesteps from answering questions. The developer is working. He performs the job he is being paid for. The user wastes his working time on helping one of his co-workers...
Conclusion. A user can do whatever he wants during a conversation. A developer, a programmer, a system administrator, tech support specialist or helpdesk person should behave as a professional diplomat. All refusals and errors are exactly their fault. There is just one exception: if you have hired a user as a tester. Then the quality of communication is on him.
Communication has several illusions. If a person keeps silence, he has nothing to say. If a person does not ask questions, he has understood everything. If I heard a person, I have understood him. If I had noted down the question, there could be no mistakes in interpreting it.
Such illusions result from the fact, that during a dialogue a person not only hears and reacts, but also interprets the situation somehow. Due to casual attribution (that was described above), a person tries to find explanations to everything. The interpretation can be quite precise as well as incorrect. And an error can be fatal. Two thirds of conflicts between people start from misinterpretation of words or actions. Interpretation mistakes can be avoided by using feedback.
Feedback principle is very simple: say aloud what you think, show what you have noted down.
A person can be silent because he does not know what exactly he should talk about or he excpects to be asked questions, can not find necessary words, he has been distracted or is just deep in his thoughts. Ask him a question, what else do we need to discuss? Or: what topics haven't we discussed yet? The user will either confirm that the conversation is over or will propose to put it off, as he cannot continue the conversation, though there are still topics to be discussed.
A person does not ask questions because he might not realize that he does not undersatnd something, or he is afraid to seem stupid, cannot find the right moment to ask a question. To get feedback, offer a user to voice his concerns. If there are no concerns, let him talk about the essence of the questions discussed. For instance, So, we are talking about "...", what do you consider to be the most imporatnt here?
The easiest things to understand in the speech of others are things that are clear. Attention concentrates on important from the listener's point of view moments. "We want to reinstall this computer tomorrow ". The speaker implies that he would like somebody from Tech support to come and reinstall the computer TOMORROW. The listener hears that WE WILL reinstall the computer by ourselves. Should he voice his version of the conversation, there will be no conflict tomorrow.
Answers, that have been noted down, can contain the same mistakes as the ones that you have heard. The consequences are worse, however. You might want to say "But I have noted this down". Even if you note your thoughts down it is still interpretation.
Misinterpretation destroys the dialogue by creating a feeling of deliberate lying.
When getting feedback try to avoid general or rhetoric questions.
General questions are questions which can be answered "yes" or "no". A simple question "Do you need a macros for this document?" The answer is "No". Now try to figure out, what the respondent meant:
He does not need the macros, others need it.
He needs a macros for another document.
He does not need a macros at all.
Rhetoric questions are questions that do not require an answer. They are good for arguments, presentations, lobbying but does not suit for feedback, because the answer is not required.
So, the user stops interaction implicitly or explicitly when:
- a developer refuses to understand his terminology
- a user himself cannot understand professional slang of the developer
- a user and a developer use the same terminology but in different meanings
- instead of identifying errors you start looking for the one who is responsible for them
- a developer demonstrates his superiority
- a developer acts like he is the most important person
- a user wastes too much time on communication
- user's words are misinterpreted
- How do you understand a user. Part 2.1 Why is he silent? Implication of knowledge.
- How do you understand a user. Part 1 Why is he silent?