Users Read Help Manuals Like an Encyclopedia, Not a Novel
On Linkedin, I've been reading an excellent thread of answers to the question, "Do you read user manuals?" Of the 50 people who answered, the resounding response is No, I don't read the manual. I try to figure out the application on my own. I only turn to the manual when I get stuck and can't figure out a feature. Or I turn to the manual when I want to learn more advanced functions.
One of the responders, Robert Poulk, put it best when he compared manuals to encyclopedias:
You're asking a variant of the question "Do you read the Encyclopedia?" The answer is, of course, yes, but only the parts that matter.
I think if you go over the other answers you'll see that's really what everyone is saying -- "Yes, but only the parts that apply to whatever I don't understand at the moment."
A good user's manual useful it not only contains good information about everything a user may come across as the product is used but also, and more important, a means to locate the information easily, meaning randomly.
IMHO people need to stop being embarassed about not reading the whole thing. Nobody does, and nobody should.There's no need to read the whole encyclopedia in order to learn where the Ganges River is.
In other words, users turn to the help to look for a specific question, just as someone consults an encyclopedia for a specific question. No one reads the entire encyclopedia/manual, nor is anyone expected to. Well-written encyclopedias allow users to find information through indexes, tables of contents, alphabetical organization, and search fields.
Reading these responses, it made me wonder I should adjust the approach to my help's home page. Usually, my help's home page provides an introductory overview of the application. Most of the time, users are already familiar with the application, so this introduction is really just filler material.
What should really be on the help's home page? The top ten most common questions users have about the application. The first page users see should try to anticipate answers to the obstacles they encounter. A search box should also be readily visible.
In a previous post ("How Much Should You Document?"), I explored the question of whether we document too much, whether the resounding thud of a thick manual is a turnoff to readers. Reading this LinkedIn thread reinforces the idea that users need all the advanced nitty gritty detail that help provides. In simplifying the help, we may leave out the answer to the complicated question the user is trying to answer. A comprehensive online help file, or a three-inch thick manual, is all right if the user can navigate it via indexes, tables of contents, keyword searches, or other means to quickly find the answer he or she is looking for.
I'd Rather Be Writing Newsletter
Get new posts delivered straight to your inbox.
About Tom Johnson
I'm a technical writer based in the California San Francisco Bay area. In this blog, I write about topics related to technical communication — Swagger, agile, trends, learning, plain language, quick reference guides, tech comm careers, academics, and more. I'm interested in , API documentation, visual communication, information architecture and findability, and more. If you're a technical writer of any kind (progressional, transitioning, student), be sure to subscribe to email updates using the form above. You can learn more about me here. You can also contact me with questions.