The 10 worst ways to deal with end users

You think you're a good communicator: You keep your users informed and you listen to their problems. So why is it that no one appears to read your e-mails or seems capable of following your instructions? Are you surprised to learn that the users have been living with computer issues rather than ask you for help? These are all signs of a breakdown in communication -- which we, as support techs, frequently misinterpret as user indifference or even stupidity. Before long, we find ourselves on a downward spiral toward complete communications failure. Even with the best intentions, it's possible to sabotage our own attempts to communicate with the users by inadvertently committing one or more of the following deadly sins of miscommunication.

#1: Inappropriate nonverbal communication
Our words may say "Absolutely, yes, of course I don't mind helping you change the toner cartridge," while our facial expressions, tone, and body language simultaneously scream, "You complete and utter gimboid, do you honesty think that I spent four years in school, have an IQ of 167, and earned 53 technical certifications just so I could change your toner cartridge? Would you like me to breathe for you too?"

It's not necessary to be a behavioural psychologist to know that tutting under your breath, rolling your eyes, and suppressing little smirks combined with your apparently kind words, sends a patronising, insulting message to the user. Instead, if you are frequently asked to perform such seemingly menial tasks as changing toner cartridges, turn it into an opportunity to educate and empower the user.

#2: Showing off
Just because we happen to know all the correct technical terms and concepts does not mean we should use them when communicating with users. Providing instructions that are overly technical and contain far more information than users need is not the most effective means of conveying our message. Instead of impressing a user with our superior knowledge, it alienates and belittles them and makes us seem supercilious and pompous. For example, telling users to clear their cache and delete their objects to solve a browser issue may be technically correct. But the chances are, if a user knows how to carry out these instructions, he or she has already done it. Try giving the user click-by-click instructions on how to perform these tasks, perhaps accompanied by a single line of explanation in terms the user can relate to. Aim to impress with your attitude instead of your knowledge.

#3: Losing patience
If William Langland had not coined the expression "Patience is a virtue" in 1377, I am firmly convinced that it would have been invented by an enlightened support tech sometime during the latter half of the twentieth century, just as humans were being introduced to computers in the workplace. Even though the computer literacy of the general working population has steadily improved over the intervening years, there always seems to be at least one user who simply doesn't get it, and whose persistence in demanding help for the same problem stretches our patience to its breaking point. Calling the user a brainless twit and bashing him or her over the head with a gel wrist relief may provide a moment of immense satisfaction, but it's likely to result in a miffed user and an unemployed support tech and should, therefore, be avoided at all costs. A better alternative is to develop techniques for (a) preventing such situations and (b) handling them appropriately when they do occur.

#4: Being dismissive
Imagine going to see your doctor because you have a mysterious green knobbly growth in your arm pit and all he does is pat you reassuringly on the back and tells you not to worry but do come back in a month or two if it hasn't gone away. How would this make you feel? What if the doctor didn't even look at the growth? This is precisely how we make the users feel when we fail to engage with their problems, dismissing them with platitudes and vacuous reassurances. Even though we may be 100 percent certain that Bob's computer isn't really taking twice as long to boot up and that Marcie must be imagining that high-pitched whine, telling them not to worry about it and to let you know if the problem doesn't go away achieves absolutely nothing except to make them feel stupid and insignificant.

Whether a computer problem is real or perceived makes little difference to users. All they know is that they have a problem that needs to be resolved. Even merely perceived problems can be fixed with some sensitivity and a little creativity. However insignificant the issue, by engaging in the problem and treating users with respect we increase their confidence in us and open the lines of communication.

#5: Failure to inform
This may seem like stereotyping, but in general geeks are not natural communicators, at least not when it comes to communicating with members of our own species. Unfortunately, the ability to meaningfully communicate with fellow human beings is a prerequisite for being effective in our role as support techs. In many organisations, the support tech is the user's prime interface with the IT department. Support techs function as Babel fish, translating between geek and human, and are ultimately responsible for ensuring that users are kept informed and up to date.

Constant communication is a critical part of fulfilling any work order, from acknowledging its receipt all the way through the process to a follow-up phone call to make sure the user is satisfied with the work performed. Often, a user can accept a delay provided he or she knows about it in advance and can plan accordingly.

#6: Lack of documentation
Not providing the users with consistent, clear, and easy-to-follow instructions is another way in which we frequently fail to communicate. Various aspects of our jobs require us to write user-consumable documentation, such as instructions for new procedures, explanation of corporate computer-usage polices, and manuals for new employees. Before distributing new documentation, test it out on a few users. Well-written documentation, kept organised and up-to-date, should ultimately save you time, as it provides users with an immediate resource for answering their questions.

#7: Lying
What should you do if you're asked to perform a task you find labourious or boring? Or what if you're asked a question to which you don't know the answer? What if the answer to a user's inquiry is something that will make them unhappy or that they don't want to hear? In such circumstances, bending the truth or misrepresenting the facts can be alluring, especially if the lie seems harmless and the chances of being caught are small. Is lying to the user ever justified?

Sometimes it's necessary to simplify the facts to give users an explanation they can comprehend, but this is different from deliberately lying to avoid work or save face. Many years ago, I worked with a senior support tech who was in the habit of blaming Microsoft for everything. When users came to him with a problem he could not immediately resolve, he would tell them it was a Microsoft issue and they just had to live with it. After awhile, users stopped going to him with their problems and he took to bragging about what a great job he was doing, as his users had so few issues. This situation continued until the next IT reorg, when he was assigned to a different group of users who were more computer-savvy and accustomed to being treated with more respect. A few weeks later, the tech was out of work due to the high level of complaints and his declining skills.

In short, when presented with a problem we can't resolve, for whatever reason, it's far better to be direct with users and help them find a resolution by some other means rather than mask our ignorance or unwillingness as an insoluble technical issue.

#8: Giving too much information
Honesty may be the best policy, but this does not mean it's appropriate to overburden the users with too much information. A mother of five grown-up boys once told me that in her experience, the average teenager will tune out all but the first three sentences of any lecture... so you want to pick those sentences carefully. It may be unfair to compare users with teenage boys, but the principle still applies: Limit communication to what's absolutely essential and don't expect users to absorb too much information at once.

It's possible to fail to communicate by overcommunicating, in terms of both frequency and detail. If we e-mail everyone in the company every time the slightest imperceptible change is made to the users' environment, many of the users will simply ignore the messages. Before long, work orders to set up inbox rules deleting messages from the IT department will start flowing in to the help desk.

Limit mass e-mail to the users who will actually be perceptibly affected by an upgrade, downtime, or some other change. If the impact is for a limited period of time, such as a lunchtime reboot of the e-mail server, set an expiration date and time on the message. Be careful not to overwhelm users with details or explanations that aren't relevant to them. For example, if the e-mail server needs an unexpected reboot at midday, give the users the time, expected length of outage, what it means for them, and what -- if anything -- they need to do. Users don't need to be given full explanation of why the reboot is necessary, although a single sentence summarising the problem may help them appreciate the urgency and is more likely to elicit their cooperation.

#9: Not providing training
Training is not restricted to sitting in a classroom for three days learning how to create a PowerPoint presentation. Support tech-provided training can be as simple as a 30-second demonstration to a single user on how to add a contact to his or her address book or as complex as a multi-day onsite class on advanced report writing in Crystal. Even if providing training is not part of the support tech's formal job description, it's almost impossible to effectively fulfill the job function without training users. Some techs deliberately avoid educating users because they regard knowledgeable users as a threat to the integrity of the network or to their jobs. Although these concerns should not be dismissed as mere paranoia, they aren't valid reasons for failing to improve the computer literacy of users.

#10: Failing to listen
Communication is a two-way process. As support techs, we need to actively listen to our users. By definition, our role is to support our users, to enable them to perform their job functions, something we can hope to do only if we have a thorough understanding of their needs. As time allows, listening can be a proactive process, with the support tech spending time with users to learn their routines and to see where technology can be applied to improve productivity or safety.

Opportunities for user feedback can be created through feedback forms, satisfaction surveys, follow-up phone calls, and even brown bag lunches. Although it may not be possible or even desirable from a business standpoint to implement all of the users' requests, without making a concerted effort to align the IT function with the business directive, it's all too easy for the IT department to become wholly self-serving and to perceive the users as little more than an inconvenience.

TechRepublic is the online community and information resource for all IT professionals, from support staff to executives. We offer in-depth technical articles written for IT professionals by IT professionals. In addition to articles on everything from Windows to e-mail to firewalls, we offer IT industry analysis, downloads, management tips, discussion forums, and e-newsletters.
©2006 TechRepublic, Inc.