Exploring the Tech Comm Paradox

by Tom Johnson on Oct 1, 2012
categories: technical-writing

In 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 is a constant source of user complaints. Mark writes,

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. (See The Tech Comm Paradox)

Mark explores several reasons to explain why there isn't market pressure to produce better documentation:

• Everyone uses the product already, so the product is accepted based on the widespread network rather than the product's merits alone.
• People don't check out the docs until later, after they've already been using the product.
• Features and price are simply more important than documentation.
• Most documentation sucks, so it's not really a buying consideration for users anyway, since it is always poor.
• The documentation isn't targeted to the right people -- i.e., the techies.

Mark then explores several strategies for making documentation affect buying behavior. He suggests that we might do the following:

• Accept reality and simply try to minimize the cost of documentation.
• Examine cost data more carefully to get a better case for documentation.
• Focus on those customer scenarios where documentation really does matter.
• Make documentation more visible pre-sales.
• Write for techies instead of novices.
• Look at documentation as a “product design activity,” with its real goal to target internal audiences.
• Be disruptive and try something that truly changes the game for documentation's importance.

My Analysis

Overall, I thought this was an insightful post. Mark is one of the most reflective and analytical writers in tech comm, and his blog — Every Page Is Page One — is well-worth following (as is Techwr-l, where this article was posted).

Here are my thoughts on the tech comm paradox. I mostly agree with his reasoning above, but I want to expand on one point in particular. Documentation will almost never be a pre-sales emphasis, that is, something to attract and persuade customers into buying the product, because the mere presence of documentation suggests that the product might be hard to use.

If the salesperson says, “This product comes with great documentation.” What this seems to mean is the following: “This product is kind of hard to figure out, but if you follow the instructions, you'll get it.”

Customers definitely value ease of use, and the more you have to rely on documentation to use the product, the lower the ease of use. Therefore the salesperson will minimize the presence of documentation as he or she raves about how easy the product is to use. You don't want to put any fear into the customer before he or she begins using the product.

To continue Mark's car analogy, imagine you're at a dealership and thinking of buying a car. The salesperson says, “And this car comes with a great emergency kit. You've got a crowbar and jack to change the tire, and some extra oil and brake fluid. You have a few spare lugnuts and some dials for the radio in case the current ones break. You have safety flares and even an emergency radio packed in here. This kit will get you out of any jam.”

If a salesperson stresses this emergency kit, rather than a selling point, I would start to wonder about the car's reliability. Why would I need this kit at all? Does the manufacturer expect the car to break down? Why are they stressing emergency measures?

Documentation is the same sort of thing – it's the emergency kit that comes with the product. You don't see yourself using it as you're buying the car/software. You hope you never have to use it, and the less someone stresses it, the more calm and comfortable you feel in the pre-sales scenario.

However, just because we downplay documentation in the pre-sales scenario, it doesn't mean that we relegate documentation to something unimportant, only that we sell documentation to another group entirely. Instead of selling documentation to the end-user, we sell it to the support manager. The support manager is perhaps the real customer for documentation.

To the support manager, the one who pays for the cost of supporting the product, documentation has a real monetary value, one that you can quickly calculate. If each support call costs $15, and documentation saves you 50 support calls a day, that translates into $273,000 dollars of savings each year. The value of documentation is clear.

While the end-user certainly needs the help documentation, he or she will rarely pay for it up front, choosing instead to believe in the promised usability of the application. Because of this (end-user delusion), we would be better off changing our target customer from the end-user to the support manager.

Strategies with Support

So far I've argued that help doesn't factor positively into buying decisions, and that's why market pressures don't automatically weed out products with poor help. Users don't want to know that products have good help, because good help documentation implies the product is difficult to use.

Users do, however, like to see convenient support options available for software. If you advertise 24/7 tech support for a product, that's definitely a selling point. However, unless you have access to unlimited support engineers working on a 1:1 basis with each customer, providing an individualized solution that is never posted or shared anywhere else, and you can pay for that sort of hopelessly inefficient support model, documentation factors significantly behind the scenes in any support strategy.

For example, I subscribe to the Woothemes developer club. The main selling point of the club, besides unlimited downloads of woothemes themes, is unlimited support. If I submit a question, about 1-2 days later someone knowledgeable gets back to me with the right answer. Many times they simply point me to articles published on their knowledge base -- articles written by a technical writer.

The problem with coupling documentation's value with support lies in poorly architected billing models in IT departments. Unless support costs for a product hit a product manager's budget, he or she most likely won't value help materials. If someone else has to pay for support, there's no incentive to have the technical writer create help materials at all.

On the other hand, if product managers must pay a hefty chunk of change to support their products, they will more likely allocate funds for help material. In this case, the product manager role blends with the support manager role.

I don't know how common it is for support and development budgets to be aligned, but it seems that, in almost every place I've worked, they are usually siloed.

Other Comments

I want to make several other comments here. I do think documentation can play a part in making products easier to use. The more we can bring documentation into the interface with context-sensitive help, the easier the product becomes. Little question marks that explain what fields mean, or on-screen text that guides users through a process, can significantly enhance the ease of use. Because documentation is integrated into the interface, it doesn't really feel like documentation. It feels like the user interface.

As far as implementing a disruptive technology for documentation, one that is a mutant strain that becomes the dominant trait leading to survival of the fittest, I welcome disruptive experimentation, even when it fails. What might this disruption be? I think it will involve the integration of video actions within the user interface. When you get stuck trying to “Configure a Widget,” and you click the little help button on the screen, wouldn't it be neat if the application itself could show you the process, using the actual screen elements you're working with, rather than a separate diagram or video?

Currently, a video tutorial could simply show you how it's done. But a more futuristic implementation might involve a video overlay on your actual screen elements and data. I'm not sure how the dynamic video overlay might work, but such a visual display could be overwhelmingly cool. The closest I've seen this application is with Sony Vegas HD Studio software. When you explore the quick start tutorials, they video instructs you to work with actual screen elements as it teaches you tasks and concepts.

Both of these enhancements involve improving the user interface, rather than improving documentation as a separate effort. When help is integrated directly into the user interface, it seems less and less like documentation and more the user interface alone.