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.
About Tom Johnson
I'm an API technical writer based in the Seattle area. On this blog, I write about topics related to technical writing and communication — such as software documentation, API documentation, AI, information architecture, content strategy, writing processes, plain language, tech comm careers, and more. Check out my API documentation course if you're looking for more info about documenting APIs. Or see my posts on AI and AI course section for more on the latest in AI and tech comm.
If you're a technical writer and want to keep on top of the latest trends in the tech comm, be sure to subscribe to email updates below. You can also learn more about me or contact me. Finally, note that the opinions I express on my blog are my own points of view, not that of my employer.