If you do technical support for a user community, you have probably had to contend with stupid users. I use that phrase in the most affectionate way. These are users you have to explain things to over and over again. Others don’t want to listen to the end of your explanation. Some even assure you they know exactly what to do and then do something different. And some ask questions that you can’t believe. Mostly they just waste your time.
While you occasionally question your own abilities, you quickly reassure yourself that you are a strong support tech. And, as much as you’d like to take it out on the users, you slowly come to terms with the sage advice to, “Suck it up and bear the discomfort.” But even such sage advice does little to alleviate the fatigue you regularly bring home.
So where do stupid users come from? Is it a simple bell curve distribution? Or is there a school they attend to develop their particular brand of not learning? Is it an issue of different learning styles, which means I will have to learn to do educational back flips to give these people a clue? Maybe it’s my karma. But I’m really such a nice guy in this life. Isn’t that worth something?
As it turns out, there’s a formula for calculating where stupid users come from. It has 3 variables, so it’s kind of complex. But if you work in tech support, you certainly have the ability to do the math. Here it is. Preponderance + Propensity + Jokes = your score. Preponderance is the number of stupid users you have in your organization, measured by percentage. So if you have 50 users and 10 of them are stupid, you have a Preponderance score of 20%. Propensity is a measure of how likely you are on average to return home still upset or wearied by your users. This is a percentage too. So if you come home one day out of five still upset about stupid users, that would be a score of 20%. Jokes are the number of jokes you tell or overhear in a week at the expense of your users, whether in their presence or not. This is a raw number per week.
Add these two percentages and your Jokes per week and you arrive at your score. If your total score is less than 5%, then your stupid users come from the luck of the draw. Count your blessings and do your best. If your total score ranges from 10%-45%, then your users come almost entirely from your imagination and your own sense of victimhood. If your number is over 45%, I have good news for you. It’s not your fault at all. You’re in the wrong profession. Find a career that makes use of your intellect, but one that makes no demands for compassionate customer service and you’ll do just fine. If, however, you are sure that you can’t possibly change careers, then see category two(10-45%). You really are making it up. Now I know what you’re thinking. What if your score is between 5% and 10%? As it turns out, we have no data on that. No one has ever registered a score in that range.
Stupid user syndrome is what happens when your tech support people think it’s the user’s job to make their job easy. The syndrome shows up in companies where support techs love the technology and easily learn the ins and outs of the system. Because of this, they have very little understanding of, or compassion for, the varying needs of typical users. They make the assumption that others are just like them, and that this task the user is working on should be simple and quick. They also assume that like themselves, if you give users the barest outline of a fix, they can connect the dots for themselves and run with it. There is also a managerial component of wanting your techs to fix problems quickly and often.
Let’s get serious here. What is missing in this short-sighted approach is three things:
- an awareness of the Pygmalion Effect.
- an understanding of Instructional Design and
- a familiarity with Systems Theory. If we are not viewing the organization as a system, then all we are left with is blaming the users.
The Pygmalion effect is when students either rise or fall to the expectations of a teacher. When you treat users with contempt, even veiled contempt, they become self conscious. That produces bumbling, slows down the fix and interferes with learning, which seems to justify the label of stupid user. When next you meet, you are both primed with the label. They expect you to be short and irritated. And you expect them to be bumbling. Self-fulfilling prophecy. Having contempt for any user who is having trouble understanding something can turn him into what we might later call a stupid user.
Good instructional design starts with a goal of competency-based training that is easy, fast and fun. If we design our training appropriately, users will learn and do the task. If users don’t learn, then the design has failed. And while that certainly happens sometimes, starting with this assumption results in far better trainings. To those who object and say that we are in tech support, not training, think again. A great deal of your job in tech support is (or should be) training, even if only in short bursts. Your job is not simply to fix the problem, but also to reduce the chances of that problem showing up again.
Systems theory would suggest that if some percentage of your users are doing things you don’t want them to do, then the system itself is broken. Drawing from the works of C. Edward Deming’s TQM (Total Quality Management) and Peter Senge’s Learning Organization, we can stop blaming users almost completely and spend our time creating a healthy system that actually works.
While tech support people are rarely expected to have expertise in instructional design, having them understand this perspective can lead them to a fruitful search for simple ways to make learning easier. And rare is the tech support person who has any understanding of systems theory, especially as it relates to the organization. But starting with the simple goal of reducing the chances for error leads to a whole array of easy guidelines that can improve the system. Examples of reducing user error include: FAQ’s, a Buddy system, mentoring, checklists, videos, easy-search help docs and restructuring the work flow of a task. These supports are not hard to deliver if you start with a healthy goal and there are lots of blogs that offer tips to support you.
There are no stupid users, only unenlightened tech support people, who may or may not be in the right job. As tech support staff, it is our job to be of service. The better we get at that, the more our users will shine, making us look good. And the sooner it becomes their job to make our life easier.
http://www.hci.com.au/hcisite2/articles/deming.htm Deming’s 14 points
http://www.infed.org/thinkers/senge.htm Peter Senge and the Learning Organization
http://managementhelp.org/systems/systems.htm Systems Thinking (plus a nice collection of management articles)