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.
Having worked for the past two years developing docs and training for new
products at a start-up company, I agree that awards are too often given to
documentation that a very high production values.... which requires graphics
design talent, but also requires a mature product with a high volume of sales.
For low-volume products, glossy, full-colour publications would not meet
customers' needs, only those of my own ego.
I'm not sure that documentation for more mature products is perceived as being
higher quality. When I worked at a large company on mature products,
documentation was under appreciated -- either used and taken for granted, or
ignored altogether. In large part this was because there were established
training courses, as well as sales engineers and support staff, to help
customers use the product. And most customers had used the product, or similar
But when I write documentation at a small company, for new products, I find that
everyone -- engineers, customer support, product verification and sales people
as well as customers -- appreciate having good documentation. And even when the
documentation isn't exhaustive, or error-free, customers still appreciate having
something to help them.
You're certainly right that complaints occasionally arise about the
documentation that may actually reflect deficiencies in the product. But with a
less-than-mature product, we're much more able to bring about improvements in
both the product and the documentation. That's a lot more fun that continuing to
document lame, confusing, or just plain brain-dead product features.
> On the subject of why good manuals are rare, I have a suggestion for a
> thesis topic, if somebody needs one. (Unless its already been done -- if so
> I'd love the see the results.) My thesis, based on unstructured observation
> over many years, is that the perceived quality of documentation correlates
> inversely to the maturity of the product.
> That is: Documentation of mature, well designed products with which users
> are already familiar, is commonly perceived as good. (It is also the stuff
> the people choose to attempt to prove that text can be completely replaced
> by graphics.) Documentation for new, immature products for which users have
> no basis in experience, is commonly perceived as bad. Users often cannot
> tell the difference between difficulties caused by bad design, those caused
> by bad docs, and those caused by their own lack of sophistication about a
> product and its uses. They tend to blame the docs.
> It is the immature, or inherently difficult, products that need good docs
> and good writers. But because, even with good docs, they are still going to
> be hard to understand and learn, people are often reading the docs and
> getting frustrated. And they blame the docs.
> I think this profession as a whole heaps too much praise and too many awards
> on docs that look good because they document a mature well designed product,
> and not nearly enough on docs that struggle to support immature products for
> users who have no adequate frame of reference for understanding or using