One of the biggest mistakes we make in technical communication is trying to write for every user.
Sacrilege, I know, but hear me out. Many users don’t read documentation. They don’t not read documentation because the documentation is bad, or not written for their level, or uses big words. The don’t read documentation because they are the kind of people who don’t read documentation. It is a fixed part of their character and their outlook on life, and nothing you can do with the documentation will change it.
It’s like a child who won’t eat anything new. It isn’t because they have tried the new food and not liked it. It is because they don’t like new food. Even if forced to ingest it, they will not like it, no matter what it tastes like, because they are the sort of child who does not like new food.
Of course, you can’t force the user who doesn’t read documentation to read it anyway, but even if you could, they would not like it because they are not the sort of person who reads documentation.
I know what you’re thinking. If they won’t read documentation, they will watch videos, so we should move all of our docs to video. But no, while there may be some people who prefer to get their instruction from a video rather than text, people who won’t read instructions are primarily people who don’t want to be instructed. The medium is not the sticking point, it is the instruction, the unpleasant exercise of expending mental energy required to learn something of slight or passing interest, and especially of learning it not from a person, or from experience but from some impersonal and abstract lump of content. They just don’t like it.
There may be many causes of this refusal to be instructed. Some may be genetically indisposed, some scared by early childhood trauma, some trained by the schools to regard any form of learning as drudgery followed by humiliation. Some people expect and demand that if they pay for something it should just work without need for directions. Some feel they don’t have time to read, some that they don’t have the mental energy or the room in their brain for new information. And some, who are willing or even keen to be instructed, have nevertheless been so disappointed so many times by the bad documentation that accompanies so many products that they will never read any documentation any more, but will seek instruction elsewhere.
There are many writers who see this host of non-documentation reading folks as a challenge. If only we can make the docs good enough, or sexy enough, or graphical enough, or entirely video, they believe, they can turn these non-documentation reading folk into documentation reading, and even documentation loving folk.
This is a highly dubious proposition, since all you can do is put docs in front of them, and they are people who don’t read documentation. And as a business proposition, it makes no sense at all. The marginal utility of converting one or two non-documentation-reading folk, in terms of its contribution to improving share or margins, or reducing costs, is zero. If that kind of heroic turnaround of people’s basic orientation to knowledge is what lights your fire, you should go work in an inner city school or some similar environment that calls for heroic teaching. It is not what technical communication, as a business process, is about.
To be sure, there are some people who have no choice but to read the documentation. If you work in a regulated profession with significant safety or security concerns, you will probably be required to read the documentation, and pass a test on it, before you are allowed to play with the toys.
The interesting question here is, how many non-documentation-reading people choose to go into professions where documentation reading is a job requirement? Probably not a lot. Those who do will clearly be highly motivated by some other aspect of the profession they want to enter. They will reshape themselves to meet the requirements of their chosen occupation. They may not have been born documentation-readers, but they will teach themselves to become documentation readers, at least within the scope of their profession. As an audience, therefore, they are documentation readers.
I don’t for a minute want to suggest that all documentation-reading people are highly educated, or that all non-documentation-reading people are poorly educated or unintelligent. I know lots of non-documentation-reading people who are highly intelligent and highly educated. They just don’t read documentation. And I think there are very clearly people of lower educational attainment who are documentation readers. It’s not about education or intelligence, it is about a basic orientation towards or away from documentation reading.
It is also certainly true that there are people who are documentation readers in some aspects of their life and not in others. Some may be documentation readers at work but refuse to read documentation at home. Some might be willing to read documentation for software but not for hardware. Some might be willing to read documentation in their own field but not in other fields.
But none of this matters to the prospects of them reading your documentation. Either they are the sort of people who read documentation in your domain, or they are the sort who don’t, and there is nothing you can do about it.
The real audience for your documentation therefore, is not the set of all users, but the set of people who are the kind of people who read documentation. Everyone else will get their information some other way, or do without it. There is no point in your trying to cater to them. They are never going to look at your stuff. Your efforts will produce zero net gain to your company, and zero net gain to its customers.
Non-documentation-reading people may receive your information at second hand, from someone they know who is a documentation reader, or they may just figure it out by trial and error, but they will never read the documentation for themselves.
The real audience for your documentation, however, is not a strict subset of the users of your product. Other people, such as analysts, journalists, bloggers, and prospective customers may read your documentation even though they don’t use the product.
The audience for your documentation, then, is simply the set of people who are interested in reading your documentation. This is good news, because they are a relatively homogeneous group, and relatively easy to write for. The only danger is that you may turn them off with all the gegaws and antics you have stuffed into your docs in a vain attempt to reach the non-documentation-reading part of your user base.
Stop trying to cater to every user, therefore, and design your documentation for the people who actually read documentation. Your life will be a lot easier, and you will produce more value for your company, and for its customers.