What Can Be Learned From User Frustration With Tech Support

How much of the public’s current woes with technology (and services) could be alleviated by better documentation?

Leaving the topic of product design (which is where problems are really started…or averted) to folks like Creating Passionate Users, I’ve long believed that better documentation and better product testing could go a long way toward reducing user frustration and help desk overload.

On the January 28 episode of “60 Minutes,” Steve Kroft profiled the Geek Squad in his story titled, “Get Me The Geeks!” There were two comments that stuck out to me as a tech writer. One came from Geek Squad founder Robert Stephens:

“It takes time to read the manuals. I’m gonna save you that time cause I stay home on Saturday nights and read them for you.”

The other comment came from survey results cited by Kroft:

“According to one survey, 29 percent of all callers swear at their customer service representative, 21 percent just scream. The rest presumably are too exhausted to do either.”

I would modify Stephens’ statement to say, “It takes effort to read the manuals. More effort than it should.”

In the environments where I’ve written technical documentation, users would consult the online help first. Then a manual (or two). Then the knowledgebase. Then the tech support line. With each step they had to take through that progression, their frustration (and, sometimes, agitation) increased. So the survey results don’t surprise me. As a user, they don’t surprise me either. I would never swear at a customer service rep, but there have been times when my frustration — over setup issues with Web hosting or my DVD/VCR player, over driver errors with my printer/copier/scanner, with Adobe Distiller messing up fonts in PDF files — has been readily apparent. The frustration has come after sorting through manuals and knowledgebases that either don’t cover something at all or bury it beyond reasonable explanation. It increases when a knowledgebase FAQ tells me that such-and-such manual covers something when it really doesn’t.

Documentation shouldn’t be such an effort to read. It doesn’t need to be something that people feel they have to plod through. It doesn’t matter if we’re talking about reference information for a relational database system or FAQs designed to help people who are registering their business as an LLC in their state. Documents designed to help people shouldn’t be painful (mentally speaking) for them to read.

When users search for help, what are they scanning first? Right…headings. And this is where the notion of “invitations to read” comes in. A heading anywhere in any document — whether it’s a user guide, marketing brochure, white paper, or something else — has to give readers a genuine inkling of what they’ll find in the text below it. When you consider that most documents are being flipped through by readers who are busy, distracted, frustrated, or outright agitated, it makes it all the more necessary for headings to be clear and useful. If they can be creative and pithy, great. But clarity and usefulness are more important.

Michael Stelzner once wrote about the three-second rule in marketing — a title has three seconds to grab a potential reader. (The three-second rule is even bleaker than the five-second rule I’ve worked from for years.)

I’m convinced that marketing’s three-second rule is equally applicable to titles and headings in any document, including user documentation. How ’bout you?