STC’s Intercom magazine published a repurposed post from Gryphon Mountain having to do with what I called the “Unspoken Rule.” The main idea of this post is that I think we as technical communicators ought to afford each other the courtesy of using each other’s materials when the need arises. As the writers, we know how valuable it can be, and if we don’t use it when the need arises, we’re contributing to the prevalent concept that “no one reads it anyway.” By doing so, we shoot our own profession in the foot.

In response, Sharon writes, “I don’t feel guilty about breaking the Unspoken Rule, because I’ve had so many experiences with bad documentation. I give the instructions a fair shot, but sometimes I give up on them fairly quickly. I think that most instructions either are not written by trained technical writers or they are written by people who are technical writers in name only.”

In my opinion, by giving documentation a fair shot, you are keeping the “rule.” That’s all I can ask of anyone using applications I work with. As we’ve rolled out a certain system in stages and trained the users, we have emphasized to them, “If you have a question, check the online help system.” In a series of feedback emails from one user, he would ask his question and then say, “I haven’t checked the help” and “I still haven’t checked the help.” It turned out that the help system provided answers to his questions. But he didn’t give the documentation a fair shot.

If the documentation fails the first couple of tests, then I’m not surprised if anyone drops it.

And I totally agree that our profession is given a bad name by those who aren’t trained in it and produce documentation anyway. I saw an STC SIG listserv thread a few months ago in which someone pointed out that just because you have a set of tools (and know how to use them), you’re not necessarily fit for the job. I may know how to type and to use Word and InDesign, but that doesn’t make me a technical communicator.

Sharon adds, “I do wish that we could get rid of the ‘nobody reads help anyway’ mentality that you mentioned. Improving the quality of documentation would cause some users/owner/operators to use it more, but that will happen only as companies employ more professional communicators.”

And as those communicators produce quality documentation and training. It’s a downward spiral: Management says no one reads it because it’s not helpful or valuable—therefore it’s superfluous. This attitude causes companies to undervalue technical communicators, which means one of a few things:

  • They don’t employ any technical communicators at all and deliver no documentation.
  • They don’t employ any technical communicators at all and get the user community to write documentation. It’s anybody’s guess what you end up with in this case.
  • They don’t employ any technical communicators and get anyone they can (developers, program managers, stakeholders) to produce documentation, with less-than-spectacular results.
  • They employ one or few technical communicators, and they are spread so thin that the resulting documentation sets are cursory and unhelpful.

The third, and fourth situations, and sometimes the second, drive users away from using documentation in general when they do try it because it’s a bad experience. The concept that “no one reads it anyway” is reinforced.

Thanks for responding, Sharon. You may have thought our opinions were polar, but I agree with you quite closely. I certainly hope that if you ever use the applications I document, you give the help and training materials a fair shot. I also hope that you wouldn’t be disappointed.

Related entries (auto-generated):

Usability and Maintainability: Instructions They Can Follow

Four More Reasons Your Company Needs Technical Communicators

When Tech Writers Don’t Read Directions

A Good Example of Simplified Technical Instructions

Anyone Can Write?