Users’ Advocate: Don’t Idealize the Reader

Often we seem to be questing for an ideal document in the belief that if we could write it, an ideal reader would emerge to read it.

Wanting documentation to be better is a good thing, of course. Wanting it to be ideal may be a fatal vice. An ideal document requires an ideal reader – its status as ideal cannot be measured against any other standard. But ideal readers do not exist. In fact, as readers, the people we actually write for are generally pretty bad.

The Genteel Art of Reading

Schools used to inculcate the art of reading – or attempt to. Perhaps they still make the attempt. A good reader had a certain set of duties towards a text. A resolve to finish was one of them. A calm and dispassionate demeanor was another. Time and serious attention, and a certain appropriate level of educational attainment and general knowledge were also thought the proper attributes of a reader. And if my prose here seems decorous, it is because reading was, in those times, a decorous business.

It ain’t today.

The bad reader

Today’s reader, particularly today’s reader of technical documentation, is more often impatient, flustered, poorly prepared, and unwilling to give the writer any time or attention with which to construct a cogent explanation. They are bad readers, but they are the readers we have.

We should not be writing for the ideal reader, but for the bad reader.

Idealizing the reader

I think technical writers tend to idealize readers in two ways. First, they imagine them as the ideal novice – a blank slate on which a fresh and perfect impression can be imprinted. Second, they imagine them as the ideal information seeker, a kind of mix of genteel reader and reference librarian, with infinite skill and patience in information finding.

This ideal reader is enormously appealing. Not only is it possible to imagine them very clearly, they also represent a perfect patron of the technical communicator’s art. They are anxious for our work, receive it gladly, consume it as it we intended it be consumed, and comprehend it perfectly.

• The ideal reader takes the time to understand the organization of our information set and to use it as intended.
• The ideal reader reads the whole document in the order it was written.
• The ideal reader understands the standardized terminology we have so painstakingly developed, and if they don’t, they take the time to familiarize themselves with it.
• The ideal reader reads the prerequisites to every procedure and ensures they have met them.
• The ideal reader is calm, has allotted an appropriate amount of time to the task at hand, and is disposed to learn.
• The ideal reader is a pure novice: they know just what we expect them to know, and nothing else.
• The ideal reader brings their full mental capacity to bear on the documentation.
• The ideal reader recognizes that their mental model of how the task should be done may be incorrect and is ready and willing to change it.
• The ideal reader delights in the elegance of your prose and appreciates your correct use of the semi colon. They gain confidence in the accuracy of your documentation from the quality of your writing.

Of course, real readers are not remotely like this.

• The real reader types some incoherent cry for help into the search box, and jumps straight to the first page returned.
• Real readers “often skip over crucial material if it does not address their current task-oriented concern or skip around among several manuals, composing their own ersatz instructional procedure on the fly.” (John Carroll, The Nurnberg Funnel)
• The real reader calls things by the names the make sense to them and responds to unfamiliar terminology with frustration and bad language.
• The real reader jumps straight to the first numbered step they see, executes it, and panics if the result is not what they expected.
• The real reader is flustered, past deadline, and had no interest in learning anything.
• The real reader is not a novice, but an expert in their own craft and concerns, with fixed ideas about how things ought to work, but with unique and sometimes surprising gaps in their knowledge.  They have no tolerance at being told what they already know, but still less for not being told whatever peculiar thing they don’t know.
• The real reader arrives at the documentation with their full mental capacity devoted to the task they are trying to accomplish, and trying to stay in the flow of their task so they can continue productively. They have little or no mental capacity in reserve for the documentation.
• The real reader is convinced that their mental model of how the task should be done is correct and that if they product does not work that way, it is either badly designed, broken, or the documentation is wrong. Only real world experience and pain can convince them otherwise.
• The real reader does not care an antelope’s armpit for the elegance of your prose and does not know a semi colon from a semibreve. They care far more about whether this solution worked for other people than they do about how well written it is.

Idealizing the bad reader

It is as easy to idealize the bad reader as it is to idealize the good one. It is easy to think the bad reader simply as someone who is bad at reading, and to imagine that they can be served by writing at a grade 6 reading level or adopting simplified technical English. But people who are bad at reading don’t read at all unless backed into a corner and threatened with bodily harm. That is why they are bad at reading – because they don’t do it unless forced to. The people reading your docs are doing so voluntarily (though generally not enthusiastically).

The readers of tech comm are not bad readers because they are bad at reading, but because they are ill-disposed towards the reading they have to do. They are bad readers because they have something else on their minds, they are rushed, they are frustrated, and they are mad that your product doesn’t “just work” (thanks, Steve Jobs).

Being talked down to or addressed in unidiomatic language is not likely to sweeten their mood. They are more likely to see it as a further waste of their time when they are already being forced to waste their time looking for information on how to make your #$%^&***!!!@### product work.

This is not fun

The reader does not want to be here. The reader is not doing this for fun. The reader is not enjoying this at all.

Reading a manual is like visiting the dentist: it is expensive, time consuming, and painful. It is only justified at all by the hope of alleviating greater pain. It is not fun.

What therefore must we do?

What can we do to make our content work a little bit better for bad readers? Some thoughts:

Abandon the idea that we can make it work well

The biggest problem with idealizing the reader is that it can lead us to imagine that we can create content that will work well for the reader. We can’t. You can’t make a piano that works well for horses. You might make one that works a little better than your average Steinway, but horses are never going to play the piano really well. Readers will always read your content badly, so it will never work really well for them. But it can work better if we learn to write for bad readers.

Abandon fancy navigation and organization schemes

When you see your readers flailing around in the search box, it is very tempting to tell yourself that search sucks and your readers would be much better served by a really sophisticated navigation or organizational scheme. They might, if they would use it. But they are bad readers. They are impatient and their brains are full of the task they are attempting to complete. They are not going to drop all their mental baggage to focus on learning your fancy navigation or organization scheme. They are going to do what they already know how to do: search, and click on links that look promising.

Make prerequisites step one

Many writers include one of more prerequisites before a procedure. In a well-structured document, these are clearly labeled with a heading that says “Prerequisites.” This works well for the ideal reader that we don’t have, because the ideal reader actually notices them and reads them. Bad readers often scan the page for the string “1.” and start reading there. If you actually want readers to read and act on the prerequisites of your procedure, make them part of the procedure itself, even if that means making step one read “1. Make sure that you have completed the following prerequisites:”

Strike the right balance between consistent and colloquial

It is certainly true that the reader will be confused by inconsistent terminology. But don’t go so overboard on consistency across the enterprise that you end up using terms no one understands. It is an unfortunate and unavoidable truth that all language is local. We can’t solve this basic fact of life by mere fiat. Use the language that your readers actually use themselves, and try to use it consistently. Introduce and explain new terms only where it is genuinely necessary to understanding a point that it is genuinely necessary that the reader understand.

Write to be anthologized

The reader is not going to read just your content, nor are they going to read your content in the order you intended. They are going to make up their own anthology of likely-looking bits and pieces on the fly as they follow the scent of the information they are looking for. Write your content so that it works as a part of such an ad hoc anthology. What does that mean? Essentially, write Every Page is Page One topics. (For details on how to do that, see my book, Every Page is Page One: Topic-based Writing for Technical Communication and the Web.)

Link richly

Many technical writers argue against linking in your content because they fear links will distract the reader.  That might be true of the ideal reader, thought the really ideal reader won’t be distracted. But the real reader arrives distracted. They search badly. They thrash through content like a shark in a tea shop. They read badly. Your job is to establish an information scent that the distracted reader can find and follow to the information they really need. Links are a great way to do that. Links can also help readers grasp unfamiliar terms, fill in the gaps in their background knowledge, and skip straight to the nugget of information they need right now.

Practice Information Architecture Bottom Up

Readers plunge into the middle of content following search or links. They largely ignore the hierarchy of a site or a help system, so the top down information architecture is not doing them much good, even if they were willing to spare the mental energy to understand it. The information architecture that is going to work for them is the one that operates bottom-up, that takes the current topic as the reader’s starting point and helps them move onward from there to the places they need to be.

What do you think?

Can you think of other ideal reader fallacies and their corresponding real reader behaviors? Can you suggest other strategies for creating content that works somewhat better for bad readers? Or do you think your readers are different, that they are good, or even ideal readers? Please leave a comment.