Getting Read, or The First Step in Solving Any Problem is Assigning Blame

In my last post, I was complaining (as usual) about modifiers used as "weasel" words: one of my client's clients, rather than give their writers some real direction in creating technical documents, told them that documents had to be "effective", "comprehensive", and organized "logically." My feeling was that these words gave writers no direction on how to do their jobs and no way for writers to check to see if they had done the job well.

But it does raise the questions: "Shouldn't technical documents be effective, comprehensive, and organized logically"?

Well, yes. Of course. But the problem is that these words don't mean anything--or, rather, that they mean too many things to provide any real direction. All of these words have to be given narrower definitions that are relevant to the job of writing technical documents.

For instance, look at "effective". For me, the first thing that's required of an "effective" document is that it actually be read. Amazingly enough, often "getting read" isn't included in the definition of an "effective" technical document. This is despite the fact that "getting read" would be one of the easiest things to check (call 10 members of the audience, ask if they had received a copy of the document, ask if they'd read it, cross-check by asking some questions based on the content of the document). When I suggest to my clients that "getting read" is a good start on defining "effective", I'm usually told that if the document isn't read, it isn't the author's fault. Well, then, whose fault is it?

Apparently, the reader's.

This attitude isn't without it's benefits. To begin with, by shifting the blame to the reader then, as an author, I don't have to do anything to solve the problem. This is good for me but bad for the organization. Besides, if I keep churning out material that no one reads (like this blog) I'm going to have a very negative attitude towards my job eventually.

So what can I do to get my document read? I doubt that the following list is comprehensive, but here's a good beginning:

• Does the title promise to deliver something that someone actually wants?
• Does the opening paragraph describe what reading this document will do for the reader?
• Is that something that the people who have this document actually want?
• Since no one reads these documents start to finish, do the documents headings/graphics/structure allow the reader to find what they may want when they need it?
  

Getting the document to the right readers, I admit, might not be my problem (but I bet that it is). The rest of the items in the list are certainly my problem. And, you've probably noticed, that last item starts to provide a definition of what a "logical" organization of the material would be: Something that allows the reader to find what they need when they needed it.

So "getting the document read" is my problem. And, quite frankly, I'd prefer it that way. If it's my problem then I can do something about it. If it isn't my problem then I can't do anything about it--I'm a victim. I'd rather be a writer than a victim.

Reading or read

• Burridge Unbound by Alan Cumyn
• The Photographer: Into War-torn Afghanistan with Doctors Without Borders by Emmanuel Gilbert
• Sum: Forty Tales from the Afterlives by David Eagleman
• The Hellbound Heart: A Novel by Clive Barker
• Batman: Arkham Asylum (15th Anniversary Edition) by Grant Morrison
  
• A God Strolling in the Cool of the Evening: A Novel by Mario de Carvalho