Computer people are fine human beings, but they do a lot of harm in the ways they "help" other people with their computer problems. Now that we're trying to get everyone on-line, I thought it might be helpful to write down everything I've been taught about helping people use computers.

First you have to tell yourself some things:

Nobody is born knowing this stuff.

You've forgotten what it's like to be a beginner.

If it's not obvious to them, it's not obvious.

A computer is a means to an end. The person you're helping probably cares mostly about the end. This is reasonable.

Their knowledge of the computer is grounded in what they can do and see -- "when I do this, it does that". They need to develop a deeper understanding, but this can only happen slowly -- and not through abstract theory but through the real, concrete situations they encounter in their work.

Beginners face a language problem: they can't ask questions because they don't know what the words mean, they can't know what the words mean until they can successfully use the system, and they can't successfully use the system because they can't ask questions.

You are the voice of authority. Your words can wound.

Computers often present their users with textual messages, but the users often don't read them.

By the time they ask you for help, they've probably tried several things. As a result, their computer might be in a strange state. This is natural.

They might be afraid that you're going to blame them for the problem.

The best way to learn is through apprenticeship -- that is, by doing some real task together with someone who has a different set of skills.

Your primary goal is not to solve their problem. Your primary goal is to help them become one notch more capable of solving their problem on their own. So it's okay if they take notes.

Most user interfaces are terrible. When people make mistakes it's usually the fault of the interface. You've forgotten how many ways you've learned to adapt to bad interfaces.

Knowledge lives in communities, not individuals. A computer user who's part of a community of computer users will have an easier time than one who isn't.

Having convinced yourself of these things, you are more likely to follow some important rules:

Don't take the keyboard. Let them do all the typing, even if it's slower that way, and even if you have to point them to every key they need to type. That's the only way they're going to learn from the interaction.

Find out what they're really trying to do. Is there another way to go about it?

Maybe they can't tell you what they've done or what happened. In this case you can ask them what they are trying to do and say, "Show me how you do that".

Attend to the symbolism of the interaction. Try to squat down so your eyes are just below the level of theirs. When they're looking at the computer, look at the computer. When they're looking at you, look back at them.

When they do something wrong, don't say "no" or "that's wrong". They'll often respond by doing something else that's wrong. Instead, just tell them what to do and why.

Try not to ask yes-or-no questions. Nobody wants to look foolish, so their answer is likely to be a guess. "Did you attach to the file server?" will get you less information than "What did you do after you turned the computer on?".

Explain your thinking. Don't make it mysterious. If something is true, show them how they can see it's true. When you don't know, say "I don't know". When you're guessing, say "let's try ... because ...". Resist the temptation to appear all-knowing. Help them learn to think the problem through.

Be aware of how abstract your language is. "Get into the editor" is abstract and "press this key" is concrete. Don't say anything unless you intend for them to understand it. Keep adjusting your language downward towards concrete units until they start to get it, then slowly adjust back up towards greater abstraction so long as they're following you. When formulating a take-home lesson ("when it does this and that, you should try such-and-such"), check once again that you're using language of the right degree of abstraction for this user right now.

Tell them to really read the messages, such as errors, that the computer generates.

Whenever they start to blame themselves, respond by blaming the computer. Then keep on blaming the computer, no matter how many times it takes, in a calm, authoritative tone of voice. If you need to show off, show off your ability to criticize bad design. When they get nailed by a false assumption about the computer's behavior, tell them their assumption was reasonable. Tell *yourself* that it was reasonable.

Take a long-term view. Who do users in this community get help from? If you focus on building that person's skills, the skills will diffuse to everyone else.

Never do something for someone that they are capable of doing for themselves.

vrkalak wrote:Your primary goal is not to solve their problem. Your primary goal is to help them become one notch more capable of solving their problem on their own. So it's okay if they take notes.

I agree particularly with that message: in fact I worked with one tech who was meticulous about taking notes and could indeed reference previous problems fairly quickly by that method, and as such was a very good tech.

It sounds like you are mainly talking about over-the-shoulder help, that is inherently much easier to do than any remote help--unless the user will allow you to take-over the screen and demonstrate what is required at a reasonable speed, not a dozen mouse clicks in quick succession (the jerky mouse syndrome of someone who isn't really sure or familiar enough with that OS or that interface or that application), but rather a mouse click with the statement I am trying to do this or this, so that they can see that even if you know the interface and OS they are using, that unless you actually have a full menu map in front of you, you will be exploring much as they would be.

Except of course you can be quicker, because you do have an idea (one hopes) that you know what to expect and where you are going.--and we all hope that we are not being denigrated as idiots by the user that wanted help in the first place..

I don't know, though. A lot of folks have an aversion to checking the manual/documentation. A lot of the article is about helping users to help themselves, and part of that is encouraging them to... RTFM.

Years ago I worked for a company that contracted me to set up new computers for their customers and provide them withone hour of instruction. Usually the instruction was in the form of browsing the web and email, send and receive.

One particular gentleman had never used a computer before and I even had to show him how to use the mouse. Sitting behind him I said see the little arrow? Move your mouse right and left, see the arrow move? Now move the mouse up. - - There he was holding the mouse over his head and telling me the "stupid arrow" didn't do anything.

This is a much nicer approach than my buddy's "Wizard's First Rule" that "people are stupid" so we must speak to them as such. I like the being nice and understanding method defined here. I'm printing this out. Hope you don't mind.

Computer people are fine human beings, but they do a lot of harm in the ways they "help" other people with their computer problems. Now that we're trying to get everyone on-line, I thought it might be helpful to write down everything I've been taught about helping people use computers.

First you have to tell yourself some things:

Nobody is born knowing this stuff.

You've forgotten what it's like to be a beginner.

If it's not obvious to them, it's not obvious.

this is all TRUE

A computer is a means to an end. The person you're helping probably cares mostly about the end. This is reasonable.

this is also true, even if it is not exceptable, its like driving a car: people find it normal that you have to be tougth to drive, and its exaptable to make misstakes at first, but its not exeptable to buy a car, step behind the weel and crash, and than expect people to fix your car and say nothing of it ....

driving a car without a licence gets you a fine, or even jail time, because you can hurt people, this is the same with computers, driving a pc without a licence, hurts other people as soon as you got yourself a virus and start spaming people from a botnet...

Their knowledge of the computer is grounded in what they can do and see -- "when I do this, it does that". They need to develop a deeper understanding, but this can only happen slowly -- and not through abstract theory but through the real, concrete situations they encounter in their work.

Beginners face a language problem: they can't ask questions because they don't know what the words mean, they can't know what the words mean until they can successfully use the system, and they can't successfully use the system because they can't ask questions.

use a dictionairy, or if none avail ask your local techi, what to look for, i for one often tell people a few 'techi' terms thay can look for on google and send them on their way, and about 35 out of a 100 times i do this they will fix it themselves. about the same amounth of times they come back telling me they tried but wherent able to solve it. and ill be happy to look at it myself, bout also about the remaing 30% are to damned to do anything about it themselves, ... so if they dont bother, why should i????

You are the voice of authority. Your words can wound. Computers often present their users with textual messages, but the users often don't read them.

allways reed that the computer says to you write it down before you call the techy gui, if you don't he either cant, or won't help you.. (my personall lesson number 1 for computer users)

By the time they ask you for help, they've probably tried several things. As a result, their computer might be in a strange state. This is natural.

They might be afraid that you're going to blame them for the problem.

computers dont make mistakes, people do, they should be made understanding this, so its either thair fault, or the programmer's fault, or even the administrators (my) fault, but that doesnt matter AT ALL, as long as every one is trying thair best to fix the problem. this is what counts, because if one of them is unwilling to fix the issue its unfixeble

The best way to learn is through apprenticeship -- that is, by doing some real task together with someone who has a different set of skills.

Your primary goal is not to solve their problem. Your primary goal is to help them become one notch more capable of solving their problem on their own. So it's okay if they take notes.

its not oke to take notes, its a requirement if you dont take note, youl forget, and ask the same question over and over again, even I with about 10 years of professional experience, still take notes if somewone it teaching me something new... even if it (at first) seams obvious

Most user interfaces are terrible. When people make mistakes it's usually the fault of the interface. You've forgotten how many ways you've learned to adapt to bad interfaces.

Knowledge lives in communities, not individuals. A computer user who's part of a community of computer users will have an easier time than one who isn't.

thus should you hand them a set of weblinks to communities like this one (linux mint forum) and explain them howto ask good questions

Having convinced yourself of these things, you are more likely to follow some important rules:

Don't take the keyboard. Let them do all the typing, even if it's slower that way, and even if you have to point them to every key they need to type. That's the only way they're going to learn from the interaction.

Find out what they're really trying to do. Is there another way to go about it?

Maybe they can't tell you what they've done or what happened. In this case you can ask them what they are trying to do and say, "Show me how you do that".

Attend to the symbolism of the interaction. Try to squat down so your eyes are just below the level of theirs. When they're looking at the computer, look at the computer. When they're looking at you, look back at them.

When they do something wrong, don't say "no" or "that's wrong". They'll often respond by doing something else that's wrong. Instead, just tell them what to do and why.

Try not to ask yes-or-no questions. Nobody wants to look foolish, so their answer is likely to be a guess. "Did you attach to the file server?" will get you less information than "What did you do after you turned the computer on?".

Explain your thinking. Don't make it mysterious. If something is true, show them how they can see it's true. When you don't know, say "I don't know". When you're guessing, say "let's try ... because ...". Resist the temptation to appear all-knowing. Help them learn to think the problem through.

Be aware of how abstract your language is. "Get into the editor" is abstract and "press this key" is concrete. Don't say anything unless you intend for them to understand it. Keep adjusting your language downward towards concrete units until they start to get it, then slowly adjust back up towards greater abstraction so long as they're following you. When formulating a take-home lesson ("when it does this and that, you should try such-and-such"), check once again that you're using language of the right degree of abstraction for this user right now.

Tell them to really read the messages, such as errors, that the computer generates.

Whenever they start to blame themselves, respond by blaming the computer. Then keep on blaming the computer, no matter how many times it takes, in a calm, authoritative tone of voice. If you need to show off, show off your ability to criticize bad design. When they get nailed by a false assumption about the computer's behavior, tell them their assumption was reasonable. Tell *yourself* that it was reasonable.

Take a long-term view. Who do users in this community get help from? If you focus on building that person's skills, the skills will diffuse to everyone else.

Never do something for someone that they are capable of doing for themselves.

Don't say "it's in the manual". (You knew that.)

i hope that you dont mind but i added a few 'notes' to certain parts of you document, these might be 'interesting to add to your fine tutorial, bacause, a techi should not only try to understand a newby but also make the newby understand what could happen if you ask a question over and over and over again.. ive been a newbie, too once, mostly in a time where there wasnt so mutch online information as today. when i wanted to know somthing i had to find it myself or try to figure out how to ask the right question to those not so 'social skilled' nerd you'd have today. mind you : the avarage nerd today is way more likely to help you than they where 10yrs ago....

so in general 'if i could have learned it so long ago poeple certainly should be able to now, (IF they try).

to all you nerds and nerdettes out there, it doesn't hurt to help people to speed up thair learning by 50% ... as long as they ar willing to do the other half themselves.

wow i can really relate this to my self i have always had a problem of trying to explain computer fix's to my family members and friends but this is a great guide to help remind me that we all started from the bottom and worked our way up. ty for this post very helpful to me

Excellent post, vrkalak. In fact, your "blame the computer" is my Rule #1. I have sat next to and taught many a raw beginner how to use a computer. I learned very quickly to begin with:"Rule #1: You are smart; the computer is stupid. Remember that always: *You* are the smart one; the computer is stupid."At this point, some people will actually start to argue the point. Either way, I continue:"Maybe in fifty years, probably more like a hundred or more, someone might build a computer that is smarter than we are. But right now, remember, you are the smart one; the computer is stupid."Then I add:"And feel free to yell at the computer and call it names. It won't mind. I do it all the time."

Your advice on "Don't take the keyboard," I find to be useful *most* of the time. Sometimes someone will ask me a question that I don't know off the top of my head. I'll say I don't know, but I will find out. I'll gently take the keyboard and investigate the solution. If they tell me I'm going too fast for them, I simply explain that I will get the answer, then show them step-by-step how to do it. After I have the solution, I put the computer back into a neutral state (ie, without any progress toward the solution), and I give back the keyboard and repeat the question: Okay, you wanted to do X, right? Okay, here is how to do it. Then I have them do it.

Re asking the same question multiple times, I find this be the case almost always. From the point of a teacher and student, I have found that a teacher repeating something at least once is critical to learning. (This may be different when doing over-the-phone tech support, which has always been quite frustrating for me. I much prefer in person training if possible.) When a person asks a question more than once and receives an answer, or when I show a person for the second (or more) time (over successive sessions), the person is *learning*. This is true whether they refer to notes or not. Some people (eg, ADD person or senior citizen or both) *absolutely need* to be shown some things multiple times before they get it. That's just a matter of patience and understanding on the part of the teacher. I go in expecting to repeat myself. Even if the student is quite intelligent, a "second pass" may simply be a matter of a friendly reminder or "pointing him in the right direction."

From my training in Training: Tell them what you're going to tell them, tell it to them, then tell them what you told them. Yes repitition is always helpful to students, so expect to do it 3 times. Also, to help focus their attention, explain how what they are learning will make their life easier.