Publisher’s Note: TechWhirl is happy to welcome Mark Baker back as a guest contributor. His thoughtful, reasoned commentary on tech comm generates great conversation and debate and always provides a fascinating perspective. He blogs regularly at Every Page is Page One and is principal consultant at Analecta Communications.
In a tech world obsessed with user experience, the role of technical communication seems paradoxical.
Photo by Brett Jordan
On the one hand, documentation is 100% user facing, and 100% intended to enhance the user experience, but most users seem to be dissatisfied with the documentation of the products that they buy and use. On the other hand, there is little evidence I can find that suggests that people’s buying decisions are significantly affected by the quality of documentation. There is lots of evidence that people complain about poor documentation, that poor documentation can drive them to distraction at times, but there is not much evidence that they actually change their buying decisions as a result.
If I think about the products I use on a regular basis, I really can’t think of any that I would say have great docs. Lots of them have lousy docs. oXygen is a great XML editor supported by a fantastic company that is a joy to deal with. Its docs are Frakenbooks. ANT is a great (if sometimes eccentric) tool for creating build scripts. Its docs are abysmal. Yet, of all the products that I use that have lousy docs, I can’t think of one that I would switch from, even if I were told that the rival product had great docs. I like the products too much.
The market is an infallible arbiter of such things. People vote with their wallets, and if a company makes products that people won’t buy, the company goes out of business, and its products disappear from the market. We don’t need great management decision making for the market to produce great products. All we need is Darwinian natural selection. Companies that produce great products succeed; companies that produce lousy products fail; the quality of products available in the marketplace improves over time due to this natural selection of superior products.
Anyone who has owned or driven a car designed and built in the 70s, and one designed and built today, knows that today’s cars are vastly better in every way from the cars of the 70s, even though the essential function of cars is pretty much the same today as it was in 1970, or even 1940. This is largely the result of the Japanese invasion of the 80s, which drove AMC out of business altogether, brought GM and Ford to the brink of ruin, and left Chrysler as a division of Fiat. This is natural selection at work in the marketplace. Japanese cars were better, so people bought them. The injection of high quality cars drove low quality cars out of the marketplace. You can’t buy a car today that is as unsafe or unreliable as a 70s car.
So why hasn’t natural selection driven bad technical documentation out of the marketplace?
The thing about natural selection is that successful adaptations can carry along all sorts of junk DNA with them. The human appendix serves no purpose; it remains in the DNA of an otherwise successful species because there is no pressure to force it out. Successful products, similarly, can carry all sorts of junk along with them: redundant code, useless features, unfinished and broken features. FrameMaker and Word both have broken features that have been broken for a decade or more. Those products so dominate their respective niches that there is no pressure to get those features fixed.
Are perpetually lousy docs simply the appendix (pardon the pun) of steadily improving products?
Now, let me be clear. I think it is possible to write good documentation. My career has been all about figuring out how to make documentation better. I doubt there is anyone reading this article who isn’t similarly devoted to making documentation better, and who doesn’t believe that good documentation makes a difference. But the problem is, if the market place does not reward companies that produce good documentation nor punish those that produce bad documentation, gains and improvements in documentation quality are not sustained and extended. Many of us have had the experience of encountering a manual that we originally wrote but which has been maintained by other writers in the interim, and we have wept. Good docs appear over and over again in many different places, but they don’t seem to have the evolutionary advantage to drive out bad docs from the ecosystem, or even to maintain themselves over time. If the market does not select for good documentation, then good documentation will remain at best a recurring mutation. It will not evolve into a dominant strain.
But if UX is everything (as we are frequently told), and if documentation is providing poor UX (also a familiar refrain), then why is there no evolutionary pressure in favor of great documentation? Some possible causes to ponder:
- The network effect: In technology, products tend to become more valuable the more widely they are used. Word is valuable, in large part, because everyone uses Word. We can send people Word documents and be sure they can open and edit them because everybody has Word. The network effect conveys such an evolutionary advantage that the product is virtually immune to other forms of evolutionary pressure. Documentation quality may impact customer satisfaction, but it does not impact sales, because the network effect trumps all other considerations.
- Incumbency advantage: Typically, defects in the docs do not show up until you have been using the product for a while. Initial ease of use seems to be a strong evolutionary selector, so most products that have survived in the marketplace have good initial ease of use, and people typically don’t consult the docs right away. By the time you come across some problem that you can’t figure out unaided, and thus have occasion to discover that the docs suck, you have a lot invested in the product and are reluctant to switch.
- Features and price trump all: Even for products in a competitive market, customer choice is based primarily on features and/or price. Even if people are unhappy with the docs, they will not switch to a product with different features or a higher price for the sake of better docs. (This may be misguided. Better docs might improve their productivity by far more than the price differential. But if people are consistently misguided in this way, what is there to do about it? General consumer behavior will not change based on isolated experiences with better docs, so unless we can sustain general improvement, docs quality is unlikely to be a factor in buying decisions.)
- Consumer fatigue: Even if consumers are unhappy with your documentation, they may be so used to bad documentation with all the products they buy, that they have no expectation that documentation is ever going to be good. If they expect all documentation to be bad, then documentation quality is not going to enter into their buying decisions.
- We may be aiming documentation at the wrong audience: Ever had the experience of calling tech support, only to have them insist on walking you through all the troubleshooting steps you have already performed, and then run out of things to try at precisely the point at which you called them in the first place? Ever opened a manual only to find that it covers everything you could figure out for yourself and nothing you couldn’t? Perhaps tech comm’s obsession with novices has had us writing for the one audience that will never read docs, and ignoring the audiences that might. Of course, if this is the case, evolutionary pressure should have eliminated this behavior. But, as with the quality of North American cars, evolutionary pressure only asserts itself when a superior mutation appears. Tech comm is a pretty small community, and we all tend to drink from the same well. Maybe we just haven’t created that superior mutation yet.
- Limits to improvement: Documentation sucks. But is that because people are producing lousy documentation when they could be producing great documentation, or is it because documentation inherently sucks, regardless of its quality. Airline travel sucks. Market pressure drives out airlines that suck more and promotes airlines that suck less, but in the end airline travel sucks because being stuffed into a flying sardine tin with 200 strangers for hours on end just sucks and there is no way to make it not suck. If there was any other way to travel thousands of miles in a reasonable time, no one would get on a plane. Maybe documentation is just a lousy way to figure out how to use or fix a product and the experience is going to suck no matter how good the documentation is. Maybe your customer satisfaction scores for documentation are going to be lousy no matter how good your docs are because documentation just inherently sucks as a vehicle for technical communication.
This then is the tech comm paradox: documentation is a common source of consumer unhappiness and complaints, and yet there is no market pressure on products with bad docs, and therefore doc quality does not improve, and companies have little incentive to pay the cost to improve it.
Breaking the tech comm paradox
What can we do? If the tech comm paradox exists as I have described it, then many of the things we have been doing up to now are not going to work, because while they might improve documentation quality, and even customer satisfaction with the documentation, they do not materially affect buying decisions, and thus there is no evolutionary pressure to maintain the mutation we have created, and no reason for our companies to fund it.
The only way to break the paradox is to focus our efforts on things that will make a difference not just to customer satisfaction, but to customer buying behavior. Only then will there be market pressure and business justification to sustain the changes we make.
Here are some possibilities to consider:
- Learn to live with it: Maybe we can’t break the paradox, and we shouldn’t try. Maybe we should just focus on doing the minimum that government regulation demands and the market expects, and on reducing costs as much as possible. Yes, that probably means a lot of tech comm jobs will go offshore. And it will probably mean that the brightest and best among us move into other fields, but if their talents are then put to more productive use, that might be a good thing.
- Learn to count the money: The market is the ultimate arbiter, but all kinds of factors can make small differences to a company’s fortunes without meaning life or death for the company. Some companies grow rapidly, while others languish in niches, neither dying nor thriving. In between, companies continue in business with various levels of profit, growth, and success. Better docs could well make a difference to the income of such companies, without tipping the scales enough to trigger rapid growth or rapid death. Market discipline, in these cases, may work too slowly to enforce good doc practices or drive out bad ones, but doc quality might still make a difference in day to day returns for shareholders. But in these cases, we can only drive change and justify resources if we can make a clear business case that docs actually are — in our own particular company — making a contribution to the bottom line. Rhetoric and generalities are not going to do it. Time to make friends with the accountants.
- Pick your battles: I know that some people are going to comment that docs definitely make a difference in buying behavior for their customers, and they may well be right. Even if the tech comm paradox is true for the general market, it may not be true for all products or all parts of the product cycle. There may be products where documentation is so essential to the usability of the product that it makes a real difference to the user acceptance of the product itself. In regulated and safety-critical environments, doc quality is prescribed and is a condition of sale. And there may well be places in the product cycle, either of an individual product or a product category, where documentation can have a real market impact. Perhaps, for instance, documentation can play a key role in attracting early adopters to the product, or in helping a product to cross the chasm to mainstream adoption. In other words, identify those niches in which docs do affect buying behavior and focus most of your attention on improving docs in those niches.
- Change the visibility: For the most part, documentation cannot influence a purchasing decision because the user does not get to see the documentation before they buy. Documentation does play a big part in the sales cycle of some large equipment sales, but in many cases, online documentation is hidden behind a login, or not on the web at all. This is changing, as more and more docs do go up on the web, so market pressures may begin to force this change generally. But why wait: this is one of the easiest changes to make — get your docs on the web, and link to them from the product pages for each product. Give the docs a chance to make a difference in the sales cycle.
- Change the target: Maybe we are writing for the wrong people. For example, maybe we should be writing for mavens, not novices. Maybe we should be focusing on building and supporting a community in which users help each other, and we help the people who do the helping.
- Change the value proposition: We all know that documentation can have important side effects in an organization. We know that one of the best ways to really know what a product can and can’t do is to document it. What if we were to regard documentation as a product design activity, a way of testing, improving, and generating information about product designs. We know that testing, support, services, marketing, and sales all use documentation to do their jobs, but we don’t focus on them as our target audience. We focus on the buyers– the people who don’t read the docs and don’t make buying decisions based on docs quality. Maybe we should be focusing on meeting the needs of internal audiences instead. Maybe helping those functions work better would actually do more to drive consumer preference than writing manuals for consumers.
- Be disruptive: Sometimes incremental improvement does nothing to change your market position. Sometimes you have to be disruptive. No other package could dent Microsoft Office in the desktop office suite market, not even fully-featured free offerings like Open Office. But cloud computing, in the form of Google Docs, might do it by changing the nature of the game. (No one needs a copy of Google Docs to open your Google Doc — it’s all on the Web.) Competition between the big four car companies was not driving improvements in safety and quality, but the disruptive introduction of more reliable Japanese cars forced massive changes in the industry.
The Web is already being massively disruptive of how people seek and share information of all kinds, including technical information. To date, tech comm’s response to these disruptions has been cautious and conservative. We tend to look down on community content and we still tend to treat the Web as just another publishing medium. But, as I have argued before, the Web is not a media, it is a colloquium. Rather than trying to maintain our current role and current practices in the face of this disruption, maybe we should seize the opportunity to be disruptive ourselves. Maybe we need to stop trying to make documentation better and start trying to make technical communication different.
There are risks to all of these suggestions, of course. Part of the nature of evolution is that most mutations fail. But if I am right about the paradox, then we need to try something different if we are going to make technical communication into something that makes a difference in the market place. Someone is going to do it. Someone is going to be the mutation that becomes the successful adaptation. Why continue trying to be a better appendix? Why not try to be wings, or a third eye — something that will change the game.
What do you think? Am I wrong about the paradox? Are market forces actually driving steady improvement in overall documentation quality that I am just too blind to see? Or, if you think I am right about the paradox, what do you suggest we do to break it?
