In technical communication circles, we sometimes take ourselves on snipe hunts. Our quarry: getting people to read our documentation.

How do we design it to be attractive? How do we write in a friendly and compelling voice? How can our diagrams be more interesting? How can we turn our documentation into entertainment?

A More Relevant Question

I think we’re past the point of no return in this area. People will read if they want to, but they generally don’t want to read documentation. (Unless maybe you’re including an engaging back story in the manual for your computer game or providing documentation for open source developers so they can be productive in their volunteer efforts.)

This isn’t to say that the questions I asked earlier aren’t important. Nevertheless, I think they’re secondary to the real question.

How do I write for someone who will spare near-zero attention for my material?

Reasons for Lack of Attention

People have short attention spans for various reasons. People are:

  • Busy. People have a lot to do. We have deadlines, personal commitments, or other pressures to meet. We’re in a hurry and can’t spare a lot of time for any given thing.
  • Distracted. In my last post, I mentioned distraction as a reason that people devote little attention to things. This may include people who have attention deficit conditions. Many things compete for our attention, especially things that we want to be doing.
  • Unmotivated. When we have little interest in something, we give it as little time and brain power as possible. We hope to get it over with quickly.

Maximizing the Window

If we accept that generally, people aren’t going to spend a lot of time with product documentation, then we can focus on the practice of providing the right amount of information at the right time. I did say generally—sometimes people really do want to read documentation, such as when they are interested in the subject or must meet legal or business requirements.

The questions I asked earlier should be rephrased in the following ways to address this:

How do we design the information to be presented at the right time? How do we write in a clear and concise voice? How can we convey this information using diagrams?

Note that I didn’t address the entertainment question. Entertaining documentation is a luxury. And though we come in all types, most technical writers don’t start out as rock stars or Saturday morning cartoon creators.

Tom Johnson’s recent series on organizing content addresses important concepts in making chunks of information easy to find, and he’s been pretty thorough. So I’ll say just that this is an important first step.

In creating content itself for the zero-attention audience, we can do a few things:

  • Make pieces of information as small and as clearly labeled as possible. We know we’re supposed to chunk information into topics that answer specific questions or explain specific tasks. But even within those topics, information should be chunked and labeled in small paragraphs or list items. In a mainly context-sensitive help project, I started labeling almost every paragraph with just two or three words in bold at the beginning. Your English teacher told you that the first sentence should tell the reader what the paragraph is about. But in tech docs, two or three words may be all the reader gives you in order to tell him that he’s hit the information he’s looking for.
  • Use the audience’s terms. In preparing for card-sorting exercises, I entered topic titles into Word to print on 3×5 index cards. I realized that some of the titles probably don’t make much sense to someone with no prior experience—which describes a number of the users. The verb isn’t right, or I haven’t been complete in naming a task. A user may see that topic and skip right over it because it doesn’t, in her mind, describe what she’s trying to do.
  • Use diagrams where possible. Where an image will tell the story, create one. If your material will be translated, use as few words as possible. Diagrams are great for conveying overview or process information. Introduce a step in your editing process where you look for places to replace words with images.

As Ginny Redish has pointed out (such as in her STC 2010 Summit presentation), when we design for people with limitations, we benefit everyone. If we create content with a target audience being people with limited attention spans, we’ll benefit everyone by providing clear, concise, well-placed information that gets the job done. It will even benefit those who want to read the documentation.

If you haven’t read Colleen Jones’s article, “How Users Read on the Web Redux,” I suggest you spare the attention to do so. I came across it while writing this post. It’s a great discussion of how Jakob Nielsen’s oft-quoted study about online reader behaviors probably doesn’t tell the whole story. And after reading it, I’m glad that in my first draft, I didn’t claim that nobody reads.

Related posts (auto-generated):

  1. Express Lane Documentation: Get in, Get It, and Get Out
  2. Informal Help via Electronic Conversation Can Lack a Certain Professional Quality
  3. First Principles of Technical Writing
  4. The Technical Writer Lens
  5. Tapping into the Resource of Project Documentation