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.
If you don't solicit customer comments, you won't get
any. The result could be documents that turn silk purse product
into sow's ear customer perception and reduced sales.
********************************
I concurr. In fact (and this is a BIC-sized flame to Marilynne, as she so
badly seems to want one--smiley inferrred but not actually shown), if you don't
complain about the restaurant food, but decide not to go back, the restaurateur
will not know what is wrong (bad cook, bad server, whatever) and can't fix it.
Before long, there are no customers, and !poof! out-of-business. It could have
been a problem like a rude server--who was damn careful not to be rude within
earshot of the boss--something the boss could fix.
By the same token, the software/document user is the only one (no matter
how sophisticated a pre-release usability/quality assurance cycle is) who
can provide the kind of feedback to make _many_ types of improvement.
Realworld Caveat:
I worked for a company for six months, and before being laid off, had written
complete re-writing proposals for all three (already existing) manuals I was
responsible for updating. (Never got to actually rewrite, tho'!) At first, my
manager insisted that there was no justification for the changes--she had heard
nothing but positive remarks about the documentation! Of course, she had
implemented absolutely NO feedback mechanism, had not really read the
documentation herself, and had no idea how to use the software we documented.
(You may remember this manager as the one who "looked good in meetings" when we
were comparing documenter/developer ratios.) The odd person who, like
Marilynne, took the trouble to provide feedback, was all there was (and I'm
still not convinced there was a real lot of that. I think it was more like the
marketing people said--wow, nicely laid out! Good font size! I like that
drawing!).
Anyway, after some time (and a good deal of developer support for my
changes), I was able to convince her. Unfortunately, once again, change came
too late, and !poof!...
******************************8
Chuck also says:
The result could be documents that turn silk purse product
into sow's ear customer perception and reduced sales.
********************************
Just an aside: how many of you have had to work the other way around? Make
a cludgey/stupid/ugly/orjustplainbuggy function actually work for the user
by writing the instructions around the problem? I think this is actually
more often the case.
Gwen (ggall -at- ca -dot- oracle -dot- com)
"The nice thing about standards is that there are so many to
choose from."
--Anonymous
