TechWhirl (TECHWR-L) is a resource for technical writing and technical communications professionals of all experience levels and in all industries to share their experiences and acquire information.
For two decades, technical communicators have turned to TechWhirl to ask and answer questions about the always-changing world of technical communications, such as tools, skills, career paths, methodologies, and emerging industries. The TechWhirl Archives and magazine, created for, by and about technical writers, offer a wealth of knowledge to everyone with an interest in any aspect of technical communications.
I've worked in plenty of places where the doc was denotation. We did it
only, because some analysts would knock us if we didn't have any. These
places were unsatisfactory places to work. And, yes, I've generated huge
framework reference manuals that contained information that was better
presented within the application. And, I've done ISO documentation, which IS
READ by the ISO inspector. But, the client company usually hopes that the
ISO inspector doesn't understand what was written, because they would lose
their certification if it could be demonstrated that labels broke
tractability, or some other arcane process issues were uncovered. The client
company I worked for even when so far as to put a thick-lined black box
around each page, so that the readers eyes would lose track of the line.
They made the doc nearly impossible to read.
With all that reality exposed, however, the value-add provided by TW is
really locked up in the idea of minimizing the time it take to understand
the content. That content may be in the form of a graphic, a table, or text.
That content should have an easily understood information architecture, be
accessible, and be reader/role centric. Every paragraph we write costs the
customer money to read. Every long-winded, theoretical discussion that
delays getting work done, costs the customer money and eventually costs the
company a customer even though the user is now an expert. Read this as,
costs the vendor, our employer, its investment in its increasing return.
And, content that makes the user to much of an expert likewise drives up
support costs and eventually drives the customer to some other product more
suitable to that expert's craft use context. More doc is rarely the
solution. The right doc is the solution. And the right doc changes over the
lifecycle of the product as it moves from market to market, and audience to
audience.
The value-add has nothing to do with reducing the cost to produce doc, or
reducing the cost of technical support. I remember taking eight hours to
align the content in four tables. That increased production costs, but it
took the reader about three seconds to find what they were looking for
instead of ten minutes. That obviousness costs the vendor money, but reduced
the user's costs by much more, since their readers were more expensive than
the vendor's writer. The reader probably never noticed, particularly since
they didn't see the original source, but customer's are becoming more
sensitive to post-acquisition costs with the rise of the TCO and other
related concepts.
Sensitive distribution of content across user education/support functions
can eliminate redundancy and reduce costs by allocating responsibility for a
range of content, so that content doesn't overlap. And, distribution also
creates opportunities to create relationships with customers. None of this
has to be left to accidental happenstance.
If there are any doc being written, so that they will not be read, let's
just fill them with geek text and leave it at that. Nobody will notice--NOT
HARDLY.