Exploring the Tech Comm Paradox
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.
One thing that has changed in recent years is that users have become more familiar with technology. There is less need to explain how to use a mouse, close a window etc. In that sense the training element that used to be in user guides has gone. You’re right to pick up on the fact there is still a need to answer the “what does that mean?” question. There will till be times when concepts will be unfamiliar, particularly if a product is innovative.
The app abandonment rates of tablet and mobile phone apps may result to there being a limit in how far you can go with “good UI”, and need for overlays (the “geography” of app controls can be varied).
I think another area of innovation will be with media sychronisation – where video, speech and text care binded in a way that the user can switch from one to the other . Search the text to find the point where to play the video, jump from the video to related information etc. We’re seeing the start of this with Kindle X Ray, and we can do similar with technical documentation. YouTube has tons of “how to” videos – combine video with text and we might see a renaissance. If we find the time, we’ll be putting together a demo of this on our web site, and it’s a theme I’ll be talking about at the TCUK conference on Thursday and at the MadWorld conference next April.
Tom, I think you make an excellent point about documentation making the product seem scary. Another exampled of the same principle is a recent New York Times article arguing that helmet laws limit the uptake of cycling, particularly bike rental programs. (http://www.nytimes.com/2012/09/30/sunday-review/to-encourage-biking-cities-forget-about-helmets.html?pagewanted=all&_r=0).
The argument, in part, is that helmet laws make cycling seem more dangerous than it is, resulting in more pollution and less exercise, as people drive cars instead, with net health consequences worse than if helmets were not used.
For that matter, one of the earliest Apple Mac commercials played on the same thing, contrasting the huge pile of binders that used to come with an IBM PC with the slender volume that came with an early Mac.
But I think there is a wrinkle here, one that came up in a discussion with Sharon Burton on LinkedIn about whether and when people read the docs. I think, and it is no more than an intuition, that people read documentation when they think they should have to. In other words it is not about whether they do actually have to read, as a practical matter, but about whether they have a prior expectation, either of themselves or of the product, that this is the soft of product they should need to read docs for.
People can be really stubborn about things they don’t believe they should have to do, often putting up a resistance out of all proportion to the actual cost to them of just doing whatever it is. “It’s the principle of the thing,” is a phrase that exists solely to justify such things — the refusal to do trivial and unimportant things simply because you don’t think you should have to.
There are many products for which most people feel they should not have to read docs, and for those, stressing docs would only hurt sales. For other products, though, people fully expect that they will have to read the docs — for a programming language, or an API, or a computer chip, or a nuclear power station — and for those the presence and quality of the docs should make a difference in the sales cycle.
If this intuition is close to correct, the implication is further evidence for two disparate propositions:
1. For products for which people don’t think they should need to read docs, help, as you suggest, should be as integral to the interface as possible, so that help and interface are one, and people have no sense that they are having to read documentation. In short, tech comm in this sphere will become UI design.
2. Tech comm itself will continue to become more technical, as the demand is increasingly found in the kind of industrial and commercial applications and products for which people still expect that they will have to read the documentation.
@Mark Leah Guren has done research into when people read manuals. If I remember correctly, beginners think documentation is very important but actually read it less than they and everyone thinks. Power users value it less, but read it more often than everyone thinks. She may have some details on her web site.
Re documentation means the product must be complicated. My presentation at the STC 12 conference was on this topic – that a great deal of technology is no longer technical, but ubiquitous, almost mundane. My argument was that we need a different writing style for these types of products – the non-scary products. It’s more marketing like, more chatty, more guide-on-the-side. Watch out though – If you get it wrong, you might end up with your own version of Microsoft Clippy.
I would have to agree with you.
My sister sent her husband out to buy a product. He kept bringing items back that came with instruction manuals. My sister said she had no time, no desire, and no patience to read ANY manuals. She told my brother-in-law not to come back until he found something simple enough that it had no manual. He succeeded.There are no manuals of any kind in my sister’s house. She refuses to even store them.
My mom used to read instructions from cover to cover. This is not the case with my sister.
My sister has said, “The world should be simple enough to come without instructions.” My sister always gets what she wants.
I wonder if this is the death knell for technical communications aimed at family households?
I think technical communications (or at least, technical publications) aimed at family households was an anomaly created by the flood of unfamiliar tech products in the tech boom. I think we are now reverting to the norm, which is no docs or minimal docs for household products. (Hobbyist products are an exception though, and always have been. Hobbyists often tend to like docs with their toys.)
Pingback: Differential Content Strategy - Every Page is Page One
As my career is based on providing simple to follow instructions for financial products, I appreciate when the steps to accomplish something are clear and not open to interpretation. It is demanded of me in my profession, so I expect it when I buy a product that is not intuitively understood by simply looking at it.
A simple paragraph can easily be included with the product that not only points the customer to the manufacturer’s website for additional products, but also acts as a link to tech support information, is critical. The product information that is contained under the tech support section must be kept up-to-date, or you lose your audience.
Having excellent support on how to use a product drives brand loyalty. There is nothing that drives away that loyalty quicker than frustrations with how to use the product that you just purchased.
“Users don’t want to know that products have good help, because good help documentation implies the product is difficult to use.”
That’s certainly true for some (maybe many) products. But the product that I document, for example, has an API. Trust me: API developers LOVE good documentation! Yes, they try to figure out as much as they can on their own, but when they get stuck they want a complete list of fields and values, examples with code samples, and great search and navigation.
Maybe you can tell that we’ve been focusing on our API docs lately. We’re also adding docs that answer more complex use cases (for both the UI and API versions of the product), but rewriting our API docs has generated a lot of interest, and we’ve been getting compliments from our Sales team who do use the documentation as a sales tool.
But you’re correct that the positioning isn’t “Look how complex our product is!” Instead, it’s, “Hey, this problem that our product solves is complex, and we’re here to help you. Just look at how we support you!”
I find this discussion interesting in light of this article I read recently from the Content Marketing Institute: “The Static Website Is Dead…” http://www.contentmarketinginstitute.com/2012/10/the-static-website-is-dead-long-live-personalized-content/
The article suggests that websites will soon cater to specific user profiles rather than just displaying more generic results. For those writing documentation or content professionals, this could be very valuable, since the needs of the beginner are so different from the needs of the more advanced, and the website would populate content specifically aligned with the particular user’s profile.
Tom, I believe that when mark says “Make documentation more visible pre-sales.”, it does not mean the typical “help” type documentation.
Offering help is just one of the aspects of documentation. It can, on the other hand, offer features in the “you can do so many wonderful things with our product” mode. I have experimented with this approach and we have included “sneak-peek” documents in pre-sales. They work. They may not be the deciding factor, but they are the assuring factor.
Why can’t it be both? I’ve had the sales team tell me directly that our docs are a sales tool, and those are mainly product help and API reference. Most of the “what’s the product and how can it help you” info is on our corporate site (run by Marketing). Customers want to see both types: to understand why they should buy your product, and to be reassured that they have somewhere to go for help (that’s of good quality) once they start using it.