October/November 2006

Volume 47, Number 2

A “Way Last Resort”?

by Molly Malsam

I recently made a career transition from technical writing to usability engineering. In my new position, I have been conducting site visits with customers in the area. During a recent visit, I found an opportunity to query a user, “Mike,” about using online Help.

Mike mentioned that he wished the software did something, which I knew that it, in fact, did, and was explained in online Help. So I decided to walk him through a little exercise.

I said, “What would you do if I told you that the software has that feature? How would you find it?”

Mike wielded his cursor in various ways across the interface in an attempt to make the software perform the feature. Then, he right-clicked different areas of the interface, looking for the appropriate command. Finally, he searched the menu bar for the elusive treasure with no success.

I asked him to explain what he would do next. Mike said that he couldn’t think of anything else to do.

The recently deceased technical writer in me gulped hard.

I prodded a bit asking, “Do you see anything else on the screen that may HELP you?”

“Nope,” was his swift reply.

Again, the technical writer silently screamed, “What about Help? What about the piece of software that I labored over, that I organized, and chunked and indexed? It’s just waiting to help you!”

Well, I already knew that he wouldn’t turn to Help, so my next step was to guide him to it and see if he could find my astonishingly well-written and researched instructions on the matter.

I innocently asked, ‘Would you ever use the online Help?”

And Mike said, “Oh, I only use help as a way last resort. By then I’ve usually figured it out on my own.”

I avoided pointing out the obvious fact that he had not figured it out on his own, and yet did not turn to Help. Instead, I told him to open the Help file and try to find a topic about the feature, confident that he would finally be successful.

What happened next took me by surprise. He immediately jumped from the exemplar of TOC and Index listings and went straight for the Find tab. He typed in two words, scrolled through the list of matching topics, and did not find anything of interest. One of the search words was, indeed, not in the topic he needed to find.

When I asked Mike what he would do next, he said, “Well, I’m confident that the Help does not have the information I am looking for, or I would have found it with my search, so I would conclude that the software does not have this feature.”

In sum, the final score was: User 0, Technical Writer 0.

Where had I gone wrong? How could I have possibly anticipated the combination of search words that Mike used? And even if I had, how could it have helped Mike, who, apparently, would not have even opened Help in the first place?

I left thinking that the maxim was true, “Nobody reads the documentation, anyway.” I’ve reflected on the experience since then, and I have no definitive answers. However, I do have a few thoughts.

• Mike was only one user at one company, and although he confirmed my deepest fears, there is no reason to assume that he is representative of most users. I’m sure people have researched how often people turn to Help on a wider scale, although I don’t recall seeing that type of data anywhere recently.
• Many users just will not read anything about a piece of software, and will rely on discovering features during use. This is probably increasingly common as a Web-raised generation of computer users becomes accustomed to tooling around an interface looking for information, or using full-text search to find whatever they need. This may point to a need to build online Help into interfaces in more obvious ways (without being overly annoying--Mr. Clippee Office Assistant, anyone?!?).
• Technical writing groups need to continue to attempt to expand their influence during the development process. Most of us have vast reservoirs of untapped talents in interface design and the creation of usable software. At the very least, we know when a feature is so confusing, we struggle to explain it procedurally, which is a sign that something needs to be changed.
• Technical writing groups should push hard to conduct usability testing on their documentation. They may be surprised at what they find, and may be able to come up with innovative strategies to address any issues discovered. I have worked at numerous companies over the years; yet I’ve never worked with a technical writing group that ever had any contact with users. What is the point of writing excellent documentation if we have no idea what our users do with it, if anything?