I found this howto particularly relevant for FOSS people who care about making their projects and communities stronger and their products more usable. A few of the many gems:

  • Nobody is born knowing this stuff. You've forgotten what it's like to be a beginner.
  • 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, 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. 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.
  • 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.
  • 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.
  • 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.
  • 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.