Do we write documentation to fulfill a responsibility, or to create a business asset? Are we striving to meet a set of requirements pronounced by either convention or regulation, or are we striving to increase corporate revenues and contribute to shareholder value?
The question is provoked by an interesting discussion with Jonatan Lundin in the comments on Tom Johnson’s post Using Tags to Increase Findability. (The discussion has virtually nothing to do with using tags to increase findability — sorry Tom!) Jonatan’s position (if I have understood him correctly) is that tasks can be divided into product-centric and organization-centric, and that documentation should stick to covering product-centric tasks and not touch organization-centric tasks. My position is that the user’s task is to use the product’s features to meet the organization’s goals and that if we are going to produce task-oriented documentation, therefore, we cannot ignore the user’s business domain.
The move toward task-based documentation is of long standing. To borrow a phrase from JoAnn Hackos, it is broadly felt that we “have to stop documenting the product and start working for the user.” This is more than a shift in style, I have come to realize, it is a shift in our view of the responsibility of tech pubs. Curiously, I think the shift is not towards a greater concern for the customer, per se, but a shift towards seeing content as a business asset.
When I started out in tech writing, it was pretty clearly understood where the boundaries of our responsibilities lay. Our job was to document the product, the whole product, and nothing but the product. What if the user needed to use our product with another system? Not part of our responsibilities. We don’t document anybody else’s product, and we don’t document public standards. If we didn’t build it, we didn’t talk about it.
On the other hand, we did not ask much whether people really needed some things documented. If it was part of the product’s behavior, we documented it. I took over one user manual that told the user that if they did such and such an operation, the phone would emit a tone of so many megahertz for so many milliseconds. I changed it to “the phone will beep”. But today I would assume that the customer would hear and understand the beep for themselves. You don’t bother documenting interface conventions that everybody knows.
In those days, documentation’s role was defined essentially as a responsibility. You had a responsibility to document your product, so you documented it. You had no responsibility to document anything outside your product, so you didn’t talk about how your product worked with anything else, and you did not make any assumptions about what the reader was using the product for, or offer them any help with their task beyond describing the features of your product.
To have your job defined as a specific responsibility in this way makes life easy. You can measure pretty accurately whether you have completed your task satisfactorily. 37 features. 37 feature descriptions. Check. Is the user able to get their work done easily? Maybe. Maybe not. But you have fulfilled your responsibility to the user because you have documented all 37 features.
We might imagine that users were frustrated by this approach, but I don’t think they were, in general. I think they accepted the same notion of the limits of the responsibilities of vendors that writers were assuming in their work. Yes, falling into a gap between one vendor’s product and another could leave you in an information limbo and force you to do a lot of work to figure stuff out, but that was an accepted part of life.
My theory is that it was IBM’s decision to release the PC architecture that led to the breakdown of that longstanding cultural convention, which was actually already underway when I started in tech writing. Suddenly, people were buying a computer from one company, peripherals from another, an OS from a third, and applications from half a dozen more. They expected all the combinations to work, and they were no longer satisfied when each company blamed the other company’s products for the failure of the system to work as a whole. Interoperability of hardware, operating systems, and applications became a business crisis, a point of extreme customer pain and frustration.
Since then, people have only increased the extent to which they interact with systems rather than individual products. They no longer think in terms of the product working or not working, but of the system working or not working. Vendors have to take responsibility not only for making sure people can use their products, but for making sure they can use the system in which their product operates.
This crisis broke the old boundaries of responsibility, and ushered in a much more pragmatic consideration: customer satisfaction and customer retention in a world where customer satisfaction was based on their whole experience. User experience became an ever more pressing business concern, and the old boundaries of responsibility became irrelevant in the face of the demand to make the entire customer experience better.
Thus the objective of technical communication becomes not to fulfill a responsibility to thoroughly document an individual product, but to enhance the user experience of people who bought the product. If parts of the doc set are not making any significant contribution to the user experience, trash them. If enhancing the user experience means going beyond the boundaries of our product and its features, that is what we must do.
I frequently mention my time with OmniMark Technologies, and my experience there provides a perfect example of this issue of going beyond the product to address the user’s task. OmniMark is a programming language for content processing, including SGML and XML. Through conferences, documentation, and particularly the developer mailing list, the company addressed all sorts of questions and issues about markup design and content processing that had nothing directly to do with the features of OmniMark. For a contemporary example, look at SynchroSoft, the makers of the oXygen XML editor, who do the same thing on their mailing list and forums.
In his book UnMarketing, Scott Stratten argues that the way you market yourself on the Internet today is to build a reputation as an expert in a particular domain. Become the person that people look to for information and answers on a particular subject, and sales of products and services will follow. This goes beyond content marketing — it is expertise marketing. This is where technical communication is going, I think, or at least the direction it should go — becoming an expertise marketing business asset.
This is not, then, a different way of writing the same old set of manuals. Tech pubs planning is no longer about figuring out how many feature descriptions have to be changed for version 3.2. It is about figuring out when and how to create content that enhances the reputation of the company as a source of expertise in its field, and supporting the users in their experience, to the full extent that doing so increases revenues and enhances shareholder value.