Users’ Advocate: Where Have All the Users Gone?

Where have all the users gone?
Gone to Google everyone.
When will we ever learn?
When will we ever learn?
Users' Advocate follow to the web

As I begin my stewardship of the Users’ Advocate column, I think it is important to begin by asking, where have all the users gone?

Thirty years ago, tech comm had a more or less captive audience. If users wanted information on your product, they looked at the manual. They didn’t have much choice. There were few other sources of information. They could ask a colleague or attend a course, but failing these, reading printed documentation was their only recourse.

The only other competition for the reader’s attention in those days was a third-party book. But since using a third-party book involved the user in additional time and expenditure, the central role of the User Guide was secure.

Not today. Today, when the user has a question or encounters a problem with your product, the first thing they do is to Google it.

True, there are some exceptions. If your user lives under a rock, works in a secure compound, works up a pole or down a hole, or gets their hands really dirty, they may not have access to the Web or to a connected device. But that is not most users of most products. And every year there are fewer people living under rocks, secure compounds are finding ways to connect while remaining secure, devices are becoming small enough and rugged enough to take down holes and up poles, and voice control is improving people’s ability to use a device even when their hands are dirty.

Today, technical communication takes place on the Web. It takes place in forums and on websites like StackOverflow, and IFixit, and on enthusiast sites like Miata.net and Android Authority. Technical communication today is, more than ever, a conversation between users rather than a dictation from vendors.

If we, as technical communicators, want to talk seriously about meeting users’ needs, if we want to act seriously as advocates for the user, we have to begin with this one basic fact: the users of technical communication have moved to the Web. The Web is where technical communication happens and if you are not there, you are not part of it.

There is no point in expending any energy on improving how your content meets your user’s needs if you don’t put it where users look for information. If your content is not both on the Web and of the Web, it doesn’t matter how good it is because it won’t get read.

And yet, many many companies still do not put their technical documentation up on the Web, and many of those who do, just throw up content designed for paper as a kind of afterthought. The amount of professionally produced technical communication that is not just on the Web, but also of the Web, that actually works the way Web content is supposed to work, remains miniscule.

Objections to Putting Tech Content on the Web are … Nutty

Why? For many doc groups, the first problem is that the companies simply aren’t interested in putting their tech pubs content on the web. Some of the reasons they are given are pretty nutty.

Some are told that if the company puts its documentation up on the Web, competitors will use it to reverse engineer the product. I have to think that some of this is due to a confusion over what “documentation” means. If people can reverse engineer your product from the end-user documentation, there is something seriously wrong with what your docs are covering. I have to think that when the execs are hearing “put the documentation on the Web” they think it means putting the code documentation or the engineering blueprints up there.

In any case, unless you are doing comprehensive background checks and making every customer sign an NDA (there are a few companies who do this), then your competitors can get a copy of your end user documentation (and a copy of your product) if they want to.

Another one I have heard is that online access to the documentation is part of the maintenance package, and people may not pay for maintenance if the documentation is available for free. I have to think that if that is the only benefit of your maintenance program, then you are probably not going to get a lot of people paying maintenance anyway. And the problem with this strategy is that it means your documentation is hidden from Google. The only way users will find it is if they log into your website and search the documentation separately. But users are so accustomed to Googling for everything these days that they may never think to do that.

The toughest objection, though, may have to do with PDFs. We are often told that the only thing that customers are asking for are PDFs. In part this is misleading, because the company is only hearing requests from those people who want PDFs, not from the people who are Googling for answers. If they are finding answers in user-generated content, via Google, they don’t need to ask for documentation.

But you still have to answer why the customers who are asking are asking for PDF. The answer is pretty simple. If you are writing your content in book form, and then producing HTML only as flat files on the file system, then the PDF is going to be the most useful format for accessing that content. Findability in HTML files on the file system is lousy, and HTML files created by bursting books, don’t tend to read well individually. There is no search facility, and usually very few links to allow readers to move from one page to another.

Tri-pane help systems aren’t much better. There are still few links, and the pages still don’t work well as separate pages, and the search facility lacks the sophistication of Google. Help system search does little more than a full-text search on the entered keyword, which is something the reader can just as easily do in a PDF. And since help system interfaces are often not consistent from one product to the next, the PDF is something that the reader is more familiar with.

But the biggest thing is this: if the content was written as a book, it will be easiest to use as a book. And since we no longer provide those books on paper, it follows that the PDF will be the preferred format for viewing that book.

This does not, of course, mean that they would rather have a PDF than real working Web content. No one asks for StackOverflow to be delivered in PDF. No one asks for the PDF version of Wikipedia or Android Authority or Amazon or iTunes. It’s not that people love PDFs. The only reason they ask for your docs in PDF is that they can’t use your book-like content in the other formats you provide.

Users’ Advocates Must Ask Some Hard Questions

The catch here is that it will take some investment to get your content into a form that works properly on the Web. For that, you will have to make the case to the folks who are raising the objections outlined above. So, how do you make the case? Suggestions welcome, but to me it comes down to this:

When people have questions or problems with your product and they Google for an answer, whose content does the company want them to find that answer on? This can cut two ways, because some execs may say, if they can find answers elsewhere, why should we go to the expense of producing our own content (this is a questions they are going to ask sooner or later anyway if your content isn’t on the Web). But put this question in its starkest forms and it becomes powerful.

  • When a customer Googles with a question about our product, whose content do we want them to land on?
  • When a customer Googles about a problem with our product, whose content do we want them to land on?
  • When a potential customer Googles about how to solve the kind of problem our product addresses, whose content do we want them to land on?
  • When a competitor’s customer Googles about how to solve a problem in our field, whose content do we want them to land on?
  • When a technical journalist or blogger Googles about features of products in our field, whose content do we want them to land on?

If you really want to drive the point home, do some of those searches and show the execs some of the pages that Google is sending people to (especially the competitors pages,or those that are critical of your product). Are they cool with people landing on those pages, or would they rather they landed on their own company’s content?

Your users have moved to the Web? How much longer before you follow them?

Category: Users' Advocate - Tag (s): documentation / PDF / search / web content

Tom Johnson

11 years ago

Excellent article. I agree with most of your points. I especially like your comment that “the users of technical communication have moved to the Web.” I also agree with your reasoning about why some users ask for PDFs — because the content was written to be read optimally in book form.

I would note that not all technical information is available on the web, though. Users can’t always just turn to google to find information. That model only works for popular consumer products. But suppose you work on a highly specialized product (e.g., functions for a Cateye Cyclocomputer bike monitor) where the only help information is on your company’s site. In that model, the user has to come to the source of info to find it. This is in contrast to help for popular products like WordPress, where practically everyone writes help and tips on their own blog.

I’m also curious to hear more about how you bridge the gap between structured authoring and the web. It seems like if you want content on the web, you need to use a web platform. Publishing tripane help online puts your information on the web, but that platform is not “of the web,” to use your phrase. Do you see a trend in authoring in structured platforms such as EasyDITA and publishing out to web platforms such as Drupal and WordPress?

Tom

Mark Baker

11 years ago

Hi Tom. Thanks for the comment.

Indeed, not all technical information is on the Web. That’s the problem. However, current coverage is vastly more than just popular consumer products.

For instance, there is third party tech comm for the Cateye Cyclocomputer bike monitor. Googling “Cateye Cyclo computer bike monitor repair” turns up this, and a great deal more:

http://sheldonbrown.com/cyclecomputer-troubleshoot.html

Anything related to Web protocols, programming languages, and APIs, for instance, are covered extensively on the Web. Anything to do with auto repair or aftermarket installation is also there. Repairing and playing musical instruments is there. Coverage is vast and growing.

And even if there isn’t much community tech comm around your product, that is no reason not to have you technical content on the Web. So many things are covered on the Web that the first thing people do when looking for information on anything is to Google for it. Even if you are the only people who write about your product, what is the downside of letting customer and potential customers find out about it with a Google search?

To be sure, there are particular products for which keeping documentation private makes sense, either because you are revealing proprietary information to your customers under a license agreement, or you need to closely control the sales cycle. But these are not the reasons that most companies are not putting their content on the Web. And these reasons have nothing to do with the many companies who are designing their documentation for paper (even though they never ship paper) and then throwing it up on the Web in a form that is un-web-like and virtually useless on the Web.

The world has moved to the Web as its default platform for information, and tech comm should be there unless there is a very good business reason not to be.

Mark Baker

11 years ago

Tom, on your question about structured authoring and the Web, I think that is still one of the missing pieces. One of the key differences between book/help content and Web content is linear vs web-like organization and navigation. Wikis provide unstructured authoring with Web-like navigation. DTP tools provide unstructured authoring with book like navigation, and DocBook and DITA provide structured authoring with book/help style organization and navigation. The empty quadrant here is structured authoring with web-like organization and navigation. (The SPFE project is intended to fit in that quadrant.)

This is not to say that you can’t use these other tools to product content with web-like organization and navigation, you may just have to work a little harder to achieve it than if you had a tool designed specifically for it.

Whether such a tool would/could/should publish out to WordPress or Drupal is an interesting one. Both are designed to be both authoring and publishing tools, so you run into some workflow issues if you push content into them from another system — how do you prevent people from editing that content in WordPress of Drupal rather than in your structured source? On the other hand, these tools have rich publishing and interaction features that it makes sense to use rather than duplicated. Perhaps it just needs a plugin to provide protection for generated content. In any case, I see this as an area that deserves much more research.

Craig Cardimon

Craig Cardimon

11 years ago

I enjoyed reading your article. I get it. I understand. Can you tell me how to get buy-in from management, because my own efforts to this point have been unsuccessful.

Subscribe to TechWhirl via Email