Misleading Documentation Metrics

Mark Baker’s post, Why documentation analytics may misread, presents an appealing argument about why it doesn’t matter if just a few people read the manual. In his post, Mark argues that a small number of key influencers who read the manual can share the knowledge with a much larger group who do not read the manual. The effect of the manual, therefore, disseminates out to a much larger group, even if that group never reads the manual. Mark writes,

A user does not have to have read a manual (for manual, read any form or packaging of technical communication) for it to shape their actions and their behavior. I’m willing to bet that there is one person in your family who reads the manual for a new gadget and then teaches everyone else how to use it. (Since I am writing for technical writers, I am willing to bet that someone is you.) The manual reaches you at first hand, and the rest of your family at second hand. Your kids then probably show their friends how to use the gadget. Some of them will then pester their parents to buy the same gadget, and will then teach their siblings and parents how to use it. Let this process run for a while and you could well have thirty products sold and a hundred people knowing how to use them, all based on one person having read the manual.

I’ve seen this same principle in practice. I wrote some help for an application at work. As with most help material, not many people read it. But one person did actually read it rather thoroughly. In fact, since it was a wiki, he even contributed a lengthy article to expand the help. This same person is a volunteer forum moderator and participates actively in the forums each day. I don’t think there’s a thread in the forum that doesn’t have a contribution from this individual.

In the forum, it turns out one of the most popular topics is the application I wrote help for. The volunteer answers a ton of questions about this application, disseminating the knowledge to a much wider group. The people who come to the forums to ask questions often don’t crack open the help, but they feel its effects in one way or another.

Perhaps in writing help material, rather than envisioning the lowest common denominator, we should target our influencers — the group that will help others. Paradoxically, maybe the information in the help will find a much greater distribution if we write for fewer people.

Madcap FlareAdobe Robohelp

By Tom Johnson

I'm a technical writer working for the 41st Parameter in San Jose, California. I'm interested in topics related to technical writing, such as visual communication, API documentation, information architecture, web publishing, JavaScript, front-end design, content strategy, Jekyll, and more. Feel free to contact me with any questions.

9 thoughts on “Misleading Documentation Metrics

  1. Patty Blount

    This is EXACTLY the dynamic in my family. I am the resident manual reader and everybody else learns from me – exceptfor cell phones. My kids teach me how to use them.

    I am astounded that this has not occurred to me before and could be a trend. As I think about it, I’m also the resident technical communication trends analyst in my department. I usually find the articles and blog posts and disseminate content to my colleagues.

    Insightful post!

  2. Dan

    I see this often at work. I write all the documentation for our software products. A scant minority of our clients read the documentation despite being directed there often by Support staff. Some people just find it easier to pick up the phone than to click F1 (I don’t understand these people but that’s probably why I ended up doing what I do).

    By far, the most active consumer of my documentation is our internal Support, Development, and Professional Services staff. Support staff consult online help when assisting clients on support cases (and now that we’ve put this content on the Web, it’s sometimes easiest for them to just forward a link to a topic rather than regurgitating the material). Development staff use help content when researching areas of the product that are unfamiliar to them. Professional Services use help content in the field when implementing our software – sometimes they just need a memory jog for arcane settings in configuration programs. Finally, new hires in all departments find online help indispensable for learning our products.

    Good online help content makes everyone work more efficiently and that trickles down to the bottom line – paying customers. It is very short-sighted to see the end user as the baseline for determining the effectiveness of documentation.

    1. Tom Johnson

      Dan, thanks for commenting on this post. It’s good to hear others’ experiences about this trickle-down effect of information. You’re right that focusing on the end user is short-sighted. I hadn’t thought of how other people inside my organization are using help, but you’re right — they may be the primary consumers, in some cases.

  3. Jen

    I really like the idea of writing specifically for influencers or those who actually take the time to read our stuff. Writing for the common denominator really changes the way we are able to say things, and I don’t think that change is always positive.

    I’ve found on one of the blogs I write for that the posts that are syndicated get far more RTs than from the audience I write for. This is definitely a case of higher denominator recognition of my posts. Or perhaps I should just dumb it down a little…

    1. Tom Johnson

      Thanks for commenting, Jen. I just subscribed to your blog.

      “Writing for the common denominator really changes the way we are able to say things, and I don’t think that change is always positive.” I agree. Probably the most common outcome is that help documentation becomes full of obvious information, helpful only to tech illiterates.


Leave a Reply

Your email address will not be published. Required fields are marked *

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>