This article is adapted from The
Network Observer.
Copyright 1996
by Phil Agre.
Computer people are generally fine human beings, but nonetheless they do a lot of inadvertent harm in the ways they "help" other people with their computer problems. Now that we're trying to get everyone on the net, I thought it might be helpful to write down everything I've been taught about helping people use computers.
| Nobody is born knowing this stuff.
| You've forgotten what it's like to be a beginner.1
| If it's not obvious to them, it's not obvious.2
| 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, of course, but this can only happen slowly, and not through
abstract theory but through the real, concrete situations they encounter in
their work.
| By the time they ask you for help, they've probably tried several
different things. As a result, their computer might be in a strange state.
This is natural.3
| The best way to learn is through apprenticeship -- that is, by doing some
real task together with someone who has skills that you don't have.
| 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. You've forgotten how many things you once assumed
that the interface would be able to do for you.
| Knowledge lives in communities, not individuals. A computer user who's not
part of a community of computer users is going to have a harder time of it
than one who is.4 | |
| 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 each and every key they need
to type. That's the only way they're going to learn from the interaction.5
| Find out what they're really trying to do. Is there another way to go
about it?6
| 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.
| 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 like
you.
| Be aware of how abstract your language is. For example, "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 check such-and-such"), check once again that
you're using language of the right degree of abstraction for this user right
now.
| Whenever they start to blame themselves, blame 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 the bad interface. 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.
| Formulate a take-home lesson.7
| 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 outward
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 probably knew that.) | |
