Frustration

I had a video camera handy and recorded the experience because I believe that as help authors, we too frequently forget the state of mind of computer users when they need help.

Her typing becomes more rapid and hurried. Little things around her (for example, her children, cookies) become more annoying and increase her stress level. She types away in disbelief and seems to keep trying the same thing over and over. Nothing on the help screen indicates that there’s an answer to her problem. She shakes her head every now and then. She’s tense. She repeatedly jerks her head. She looks up and squeezes her hands. She’s running out of options. She throws things. The littlest disturbances set her off. Her stress level continues to escalate.

In moments like these, what might she do for help? Search for it? Click a relevant-looking help button? Call tech support? Call me? Yell at someone?

If there’s one undeniable characteristic of the frustrated computer user, it’s that her patience is gone. She will not be slowly flipping through the  user manual. Notice her jerky movements. If she turns to the help (which she doesn’t here), she’ll search for keywords, skim rapidly, click quickly from topic to topic. She’ll look for topics with clear flags for help – “Troubleshooting Passwords,” “Can’t Remember Your Login?”, “Stuck? Click Here,” etc.

She won’t give any help page but 2-3 seconds of a glance to see if it has the information. She’s in a hurry and she’s desperate for the information, as if there’s a ticking time bomb in the house about to go off.

As we write for users in this state of mind, we have to remember the hurry. Avoid long chunks of text. Avoid long topics. Make your topics findable in searches. Make your start page show the top ten list problems users encounter. Provide contact information for live help, if possible. Get right to the point in your text, without making the reader sort through fluff and meaningless introductory material. Provide answers to problems, not long descriptions of menu bars.

After Jane’s emotions settled down, I asked her why she didn’t turn to the documentation for help. She did, sort of. But, she explained, “If there’s not a real person who can cry while I’m mean to them, where is the incentive to fix it?”

Blog Sponsors

• 3Rabbitz book
• Webworks ePublisher
• Scriptorium
• Help Generator help authoring software
• Southern Polytechnic: Information Design and Communication
• Simplified English
• MindTouch
• Madcap Software
• Dr.Explain
• Adobe Technical Communication Suite
• Congree

• In Flare: the good stuff, he explains the features of Flare that he really enjoys, such as being able to integrate his own javascript and PHP scripts directly into the code.
• In Why do we use Flare?, he and a colleague talk about Flare in depth — for about an hour, actually, discussing the little things that annoy them about Flare, such as the visual editor.
• In What does it take to be a technical writer (a carcast), he mentions some key qualities technical writers need, such as a curiosity for learning and understanding how things work.
• In his May 19th Dogcast, he actually gives the podcast while walking his dog. The podcast covers the evolution of help, the need for technical communication, and user psychology.

Although the dogcast started out slow, this was the podcast I enjoyed the most. About 15 minutes into the podcast, he really hit his rhythm and started driving down into the topic that seemed to grip him most: user psychology. Users don’t read manuals. The days where long, printed manuals were standard prerequisites to using technology are gone. People experiment with an application and try to learn by doing; when they need information, they search for information about the task they’re trying to accomplish in that instant. Online help is critical in helping users find a single piece of instruction for an immediate need.

Users are also in a state of anger and impatience when they turn to the help. They’re mad because the software has frustrated them and stopped their work. They don’t want to read a manual. What they really want is someone to explain to them how to do something.

Listening to Alistair’s thoughts on the user’s state of mind made me think about the help we write. Why is it that we often begin a software documentation project by documenting all the tasks that users can possibly do from all the available functions of the software application? We spend the bulk off our time creating written instructions that almost no one wants or reads.

Instead, I think we should be focusing on several key deliverables:

• Audiovisual tutorials or screencasts
• Short getting started guides covering the basics
• Context-sensitive online help

Further, we should begin by getting to know our user — not through a description from the SME or business analyst, but actually contacting the user to determine the tasks they want to accomplish and the format for the help.

The Getting Started guide should walk them through the most common, basic tasks the user will need to perform. This guide should be easy to get through. Alistair says the help should provide immediate rewards to the user. Take them through some quick wins. In the Getting Started guide, you give them easy-to-perform tasks that make them successful.

The screencasts (which should also be short) provide a range of other benefits, such as providing the experience of a friend showing them how to use the application.

The context-sensitive online help gives the user immediate information about the task at hand. The online help also provides a searchable database for answers.

So often we begin with the comprehensive manual in mind, when that’s the last priority for users.

Additional Resources

A few months ago I posted some notes from a Kathy Sierra presentation that talked about the user’s state of mind as well.