RE: More on Validating documentation

["Christensen, Kent" <lkchris -at- sandia -dot- gov>]

I would add (coming in late) a few more thoughts to this discussion.

1.  I cringe every time I hear the word "documentation," and "validating"
isn't much better.  In my view there is little relationship between
"documentation" and the ultimate customer for the product who, instead, most
of the time wants "help" and possibly even a "user manual."  Customer
service and customer value must remain the top priority whether the task is
designing and testing the prototype product or the prototype help system
that accompanies the product.  All the stuff about "relationships" within
your firm must remain secondary to and surely directed toward customer
service, i.e., relationships with outside customers.

2.  "Relationships" within your firm are not insignificant, but critical in
the effort, I believe, is some process.  Just as there is likely some
formality and design to steps taken to test the product, there should
likewise be a design for testing the help system.  I'd venture, possibly
optimistically, that if the "documentation validation" is part of a formal
process that is developed, understood and accepted by everyone,
"relationships" within the firm will be not such a problem.  The
"documentation validation" design should exist prior to initiation of the
project, be based on, ideally, what worked well last time, and be subject to
planned continuous improvement and review.

3.  As usual, most discussion here centers around software projects, but
with just possibly a few generalizations, it could apply to user manuals for
hardware things as well.  Specifically regarding software, however, it is of
course likely a "mantra" of developers that the software product be
self-explanatory.  That is usually the developers' goal and always should
be, and this leaves the "documentation," the help system, the user manual in
a somewhat secondary position.  That is, the developer can quite naturally
see the tech writer as adding little extra value, since he or she or the
developer team has already worked so hard to create an intuitive interface.
Again, the solution is keeping the ultimate customer in mind.  The
"validation" process for the "documentation," then, must involve
understanding whether the product is, indeed, self-explanatory for the
customer.  Are the customers techies like the product developers, or ... ?
This leads, again, to the requirement for a "design" for help system
testing, and, ideally, to testing using people/guinea pigs who are like the
customers or even ... customers.

4.  Finally, this discussion shouldn't lose sight of the notion that the
"help desk" is part of it all, and that the possibility should be left open
for developing FAQs and for continuous improvement of the manual and that
the help desk personnel ought to understand the manual, too.  Since the
discussion is mostly centered on software products, the concept of a Web
site for some sort of additional "documentation" supplements seems only
natural.  All this should be in the customer relations plan from the
beginning and never simply a reaction.


^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
PC Magazine gives RoboHelp Office 2002 five stars - a perfect score!
"The ultimate developer's tool for designing help systems. A product
no professional help designer should be without." Check out RoboHelp at
http://www.ehelp.com/techwr

  Check out the TECHWR-L Site redesign! 
  http://www.raycomm.com/techwhirl/

---
You are currently subscribed to techwr-l as: archive -at- raycomm -dot- com
To unsubscribe send a blank email to leave-techwr-l-obscured -at- lists -dot- raycomm -dot- com
Send administrative questions to ejray -at- raycomm -dot- com -dot-  Visit 
http://www.raycomm.com/techwhirl/ for more resources and info.