Reading Usable Help
@UsableHelp on Twitter
Gordon R. Meyer
Help is the Last Resort
Do you know any technical writers? You might, just think of the people whom you know, but you're not quite sure what they do for a living. Is there a lady (usually) who never talks about what she does? She might write manuals for toaster ovens. Or database tools. This profession is somewhat like being a mortician. Someone has to do it, but nobody really wants to talk about at a cocktail party.
So there's no glamour. Big deal. But what about "nobody reads the documentation"? To say "nobody" is obviously an exaggeration. Better put, "nobody likes to read the documentation." The fact is, most people will use the help (or manual) only if they absolutely have to. Even those of us who do it for a living.
The other day I was using Adobe InDesign to create a collage of photographs. I wanted to add a drop shadow to one of the pictures, but I didn't know how to do it. I recalled hearing that this is something that InDesign makes really easy, so I began exploring the menus in the application. I didn't immediately see anything that seemed related to what I wanted to do, so I started looking for a pallet or tool that might do the trick. No luck there, either. Next, I grabbed the box that InDesign came in. Sure enough, right there on the back, it talks about editable drop shadows. But that didn't help either.
Everyone I know uses Xpress, so I couldn't think of anyone that I could ask to help me, so since I really wanted that darn drop shadow, I opened InDesign Help. The good news is that I easily found my answer and got back to work. Kudos, Adobe.
So why didn't I just begin with the help and save myself several minutes of futzing around? Well, the same reason you don't work that way either. Years of accumulated frustration and unsuccessful experience has created an "only if I have to" attitude about reading the documentation.
That, and human nature. The desire to feel smart, the satisfaction of figuring stuff out for yourself, and for many of us, the fun of serendipitous discovery when puzzling out a situation.
Generally speaking, most people turn to the help system under something like the following scenario:
"I want to accomplish something, but don't know how to do it. I've tried to figure it out, but can't. Nobody I've asked knows how either, and it's something I really have to do, so I guess I'll look in the help system".
It's help as a last resort. The final straw. The "I don't know what else to do so I hope this tells me something" Hail Mary pass in the last few seconds of the game.
As bleak as this might sound, it isn't a Bad Thing. Instead, accept it, and focus on how to make the help system usable under these circumstances.
The end-of-their-rope user is frustrated, so make it easy to find information in the help system. They know what they're trying to accomplish, so make the help searchable and use words, phrases, and tasks that real people are likely to look for and recognize.
Think about each task and the experience of the user who is likely to be looking it up. Speak to their experience. Is the task simple and basic? Write for the novice user that's likely to be looking up this topic in frustration. If it's an advanced task, less handholding will be greatly appreciated, as might a bit more technical detail.
Is there something about this task that everyone misses, or does it have some obscure prerequisite? Be sure the user who is in a hurry can find the one critical piece of information they need to know. Such as that hard to notice padlock icon that needs to be clicked before they can delete the contents of a table cell. Smile and imagine them slapping their forehead when they read that.
Instead of feeling bad that many people don't look at the help. Focus on making sure that it provides the best experience for when it is finally consulted. You'll be a hero, and perhaps next time the customer who has a good experience will look at the help just a tiny bit sooner. And maybe thank the next writer they meet at a party.