The Paradox of Tech Comm

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.

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:

  1. 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.
  2. 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.
  3. 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.)
  4. 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.
  5. 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.
  6. 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:

  1. 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.
  2. 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.
  3. 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.
  4. 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.
  5. 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.
  6. 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.
  7. 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?

Ellis Pratt

12 years ago

I add “Measure the value of what you create” into the mix. How many people read the documentation? How many support calls are avoided? If all we measure is productivity, is it any wonder the focus is on lowering costs and making writers produce more content.

Pick your battles: Many products are no longer technical – they just work and are mundane. So we need to ask whether the traditional technical writing model is the best approach for these products.

We may be aiming documentation at the wrong audience: The purpose of documentation may be for the benefit of the organisation rather than for the user. The user is going to take the line of least resistance – if they can get a concierge service by calling Support – then they may well follow that route.

Change the target: Mike Priestley has suggested a phased implementation of documentation – for early adopters, leaders and then laggards.

Change the visibility: Agree. It needs to be on the Web. Other comments – (a) The attraction of Amazon is the product reviews. (b) SAP’s Keren Okman said at conference earlier this year that they are making the descriptions in the Apple App Store more Help- focussed in order to reduce app abandonment rates.

Tom Smith

12 years ago

I’d agree with Ellis. Many tech comms teams are yet to truly understand how their customers are using and interacting with their documentation. This is the key to discovering the value that tech comm provides to the organisation and its customers.

I also think the crux of this is that documentation focuses to heavily on the basics. One of the changes we are seeing is that tech comms is now looking to scenario-based documentation and moving away from the feature-based, traditional model. Talking to a tech comm manager for a phone manufacturer recently, he mentioned that he is trying to solve scenarios such as ‘how do I connect my phone from one manufacturer to my tablet from another manufacturer’. I, for one, search for that kind of information all the time, much more than ‘how to use bluetooth to connect to other devices’

Great post, Mark, I enjoyed it

Robin Hall

12 years ago

I would add to your list of things that are preventing evolution, the fact that users are already helping each other online without your company’s assistance. The quickest way to solve a computer problem these days is to google the problem. Chances are you will find about 80 fixes the company never thought of. I think that the company creating such a forum would allow them to tap into the creative power of their users to solve problems. It would also give them an avenue for learning consumer’s pain points so that they can improve not just the documentation but the product itself.

I would also like echo the sentiment about making documentation online. In addition to making it more visible, it makes it easier to upate and allows you to introduce multimedia elements, and tie to the aforementioned forum.

Mark Baker

12 years ago

Ellis, agreed, within the sphere of things that make the difference between surviving and thriving, there are lots of potential cost avoidance that docs can provide to other areas of the company, including support.

While I would far rather make a value-add argument than a cost avoidance argument any day, if I have to choose between a cost reduction (in pubs) argument and a cost avoidance (for the rest of the company) argument, I would choose the latter every time.

Regarding leaders and laggards, I am definitely coming more and more to the opinion that we should be delivering different types of documentation over the arc of a product life-cycle, and perhaps even more importantly, over the live of a product category life-cycle. Delivering the same set of docs from 1.0 to the last public release, which is the model most tech pubs groups still use, simply ignores the vastly different levels and types of information needs and information availability that exist at different parts of the product and product category cycles.

Mark Baker

12 years ago

Tom, I too suspect that tech comm focuses too much on the basics. Indeed, I would go so far as to say that tech comm is obsessed with novices. To the extent that changing the focus to more intermediate and advanced user needs could potentially make a difference to customer buying behavior, we may not see it because too few tech comm groups are doing it, and thus there is no superior mutation to put evolutionary pressure on the rest.

Could scenario-based documentation be the superior mutation? I hope so. I don’t think the concept is really that new, though. We have been talking about task-based documentation for a decade or more, but that, unfortunately, has seemed to degrade into nothing more than writing procedures (for novices). If a new name can revitalize the concept, though, it might force positive change in the environment.

Mark Baker

12 years ago


I agree entirely, Indeed, there has been a large and rapid evolution of technical communications outside of tech pubs departments. If there is evolutionary pressure at work it is not a pressure between good tech pubs and bad tech pubs, but the pressure of community content that is threatening to make tech pubs as a whole extinct.

The reluctance of so many to put docs on line (which often comes from outside tech pubs, unfortunately) will only exacerbate the risk of an extinction event for tech pubs.

Marcia Riefer Johnston

12 years ago

Excellent topic, Mark.

While I don’t typically write presale materials–documentation is more my thing–I was recently hired by a B2B marketing agency to audit of their client’s post-sale content. Seems the client got wind of potential customers seeking out their support documentation during the purchasing-decision phase. Because the product is complex and expensive, and a purchasing decision has huge implications, customers want to know what they’re getting into: “How well will this company’s documentation support me?”

Documentation, for this client, had suddenly become marketing collateral.

No paradox there.

See also…

… and Rahel Bailie’s commentary here:

I do love your question, though: “So why hasn’t natural selection driven bad technical documentation out of the marketplace?” Wonderful analysis, as always.

Milan Davidović

12 years ago

” 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.”

How broad a range of products is this statement intended to cover?

Mark Baker

12 years ago

It is meant to cover the market as a whole. There are very clearly some niches where docs do make a difference, if only because doc quality is highly regulated, so if your docs don’t meet standards, you can’t sell the product. But in the general market, we still seem to see what we have always seen: a few examples of really good docs, a lot of mediocrity, and a lot of drek. And if doc quality really affected buying behavior, we should expect the drek (at least) to be driven out of the market.

Mark Baker

12 years ago

Marcia, I definitely believe that there is a significant section of the market for which tech docs could have significant impact as sales collateral. Of course, how well they work for that purpose will depend on how well they are written. I would expect a collection of Every Page is Page One topics to outperform a traditional book for this purpose, since they can answer specific buyer questions more effectively.

Exploring the Tech Comm Paradox | I'd Rather Be Writing

12 years ago

[…] another insightful post from Mark Baker, this one called  The Tech Comm Paradox, Mark asks why there’s no market pressure for good documentation even though bad documentation […]

Sarah O'Keefe

12 years ago

I’m not sure that’s true only because if all products have drekky docs, nobody gets pushed out of the marketplace! But what if *one* company tries improved docs and their competitors don’t?

Differential Content Strategy - Every Page is Page One

12 years ago

[…] my TechWhirl article, The Paradox of Tech Comm, I pointed out the paradox that while documentation is a common source of user frustration, it seem […]

Mark Baker

12 years ago

That’s true, if a somewhat dismal prospect. As with American cars before the Japanese invasion, if there is no superior mutation, there is no evolutionary pressure on the weak incumbents.

What if one company improves docs and their competitors don’t — that is the question. If that company gains significant market share, that should create evolutionary pressure in favor of good docs. Conversely, if that company does not gain significant market share, but expends more energy in improving their docs, then evolutionary pressure may drive good docs out of the market.

Personally I’m inclined to the view that the right docs should provide an evolutionary advantage in some situations, and that what we need in consequence is a differential content strategy. More on that here:

Neal Kaplan

12 years ago

We’re moving to scenario-based documentation, too, and that’s based on feedback from internal and external users (internal being professional services, support, and sales).

I think documentation tends to focus on the basics because we’re told that we need to document enough to get our users up and running. And in smaller companies, that’s often all we have time and resources for before we need to move on and document the next feature.

But our users are asking for more than that: They want use cases, examples, and what we think of as “How Do I…?” topics, and all of those are for more complex processes. Of course, users still need basic configuration info, but we can’t just leave them with that and pretend it’s enough.

Jonatan Lundin

12 years ago

Great article, Mark. If I get you right, you’re saying that whenever users complain about low usability for a certain design part of a product, like user documentation, a logical consequence would be that they’d change to another product perceived to be better. But for user doc they don’t (and you give possible causes to why they don’t change).

So what is the actual problem? Technical communicators still have their jobs, albeit we are producing stuff nobody likes. People are continuing to buy products, no matter the quality of the user doc. Business as usual? Or are you saying that the problem is that technical communicators will be out of job in a near future for some mysterious reason.

If I understand you right, your claim is that technical communicators are always striving to make better information products, increasing customer satisfaction and user experience. But the effort is meaningless since it does not contribute to the company bottom line, and our effort will not be maintained. So there is no point in trying; we might as well give up and do what we have always done. If we where to put any effort in trying to improve user doc, the improvement must be at such scale that it has an impact on sales. Only then it will be maintained. I do not disagree to this perspective.

But let us agree on one fact. For many products there will always be users in need of help. Yet for other products, no one ever needs any help to use them. D. Norman claims that we are surrounded by nearly 20 thousands artifacts every day for which we do not need any documentation (shoe laces, pens etc). So I guess you are referring to “complex” products where the UI cannot communicate its use.

A user in need of help does have many options, that is, information sources to choose from: friends, colleagues (physical or on-line), support, user doc etc. Now, some amount effort is required to retrieve help from any type of source. Some sources require less effort than others. We know that users tend to select sources according to a principle of least effort, which often means that user doc is not the first choice since users perceive it to require a lot of effort to use.

If “easy to use sources” are available, they will always be used first which means that the user manual will be the last resort. If user doc is the only source, users complain since they cannot find what they need given that they are only willing to invest a certain amount of effort which is often below what is required. I argue that most of the effort that a source requires, must be put in retrieving the needed information (=answer), thus in searching and finding.

To me, a paradigm solution to break the paradox is to design user doc that requires less effort to retrieve help from than the often first of choice sources like colleagues, friends, wikis, Google etc. So if we can design user doc that literally requires no effort in finding the needed help (there must be a substantial difference between user doc and other sources), we have a break through. Such user documentation might very well be a business driver. The question is: is it possible to design such documentation?

Mark Baker

12 years ago

Essentially, yes. The marketplace is subject to evolutionary pressure. It a mutations makes an organism more successful, it drives out less successful organisms. But the status quo is not a option either, because evolutionary processes also say that mutations that consume energy but deliver no benefits will be squeezed out. If docs convey no advantage to the company, but continue to consume resources, they will eventually be squeezed out.

But I agree that there are many products for which documentation is indispensable. It won’t be squeezed out of those markets. But I would go further and say that there are times in the product cycle of a product when documentation is far more valuable than it is at other times. I think there are other factors as well that dictate when and where documentation adds or subtracts value. This is why I believe tech comm needs to move to a differential content strategy (

Breaking the tech comm paradox…. | Writex Ltd

12 years ago

Milan Davidović

12 years ago

Consider the set of factors that influence a purchase decision. Then consider the set of factors that affect user experience. Documentation is believed to be part of the latter but not the former. That could be true, but what else might fit that description?

Sponsored Posts

Interested in having a sponsored post on TechWhirl? Learn More >>

Subscribe to TechWhirl via Email