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.
Sylvia Braunstein reports: <<The QA manager told me that we would have to
establish procedures on how to perform QA for our technical writing
department. Does anybody have... recommendations?>>
Only your QA (quality assurance) manager can tell you your employer's
requirements; there's little point implementing something that we
techwhirlers suggest if your QA people have an entirely different idea of
what's required. So find out your company's requirements directly from that
manager and build your QA processes around those requirements. In fact,
enlist the aid of that manager; they'll find it much harder to reject what
you develop or criticize the results if they contributed to its development.
That being said, here are a few things you can do in any QA program for
documentation:
Accuracy: What you've written must be accurate, and only a review by the
developers can ensure that this is the case. Asking a colleague to run
through what you've written and check each claim against the actual project
goes a long way towards achieving this, but won't eliminate the need for a
review by the experts.
Completeness: Anything a user can see or use and subsequently ask questions
about should be documented. As is the case for accuracy, you can do some of
the testing for completeness by yourself, but you're also going to have to
enlist the aid of the developers--and particularly so if the product is
evolving and they're not keeping you informed of the changes.
Usability: Only your audience can tell you whether you've produced a truly
usable document. Until you can arrange for feedback from that audience, you
can produce something _more_ usable by having a skilled editor go through
what you've written, and by asking your training and technical support
departments to confirm that you've clearly answered all the most common
questions they receive.
--Geoff Hart, FERIC, Pointe-Claire, Quebec
geoff-h -at- mtl -dot- feric -dot- ca
"User's advocate" online monthly at
www.raycomm.com/techwhirl/usersadvocate.html
"Hart's law of gravitation: Deadlines are the documentation equivalent of
black holes: the closer the deadline approaches, the harder it becomes to
escape its pull, and the faster events accelerate in their rush towards the
deadline; at the technical communication equivalent of an "event horizon",
nothing escapes that pull. And the closer you approach a deadline, the
faster things are moving and the less time everyone has to react
appropriately."--Geoff Hart
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
Develop HTML-Based Help with Macromedia Dreamweaver 4 ($100 STC Discount)
**WEST COAST LOCATIONS** San Jose (Mar 1-2), San Francisco (Apr 16-17) http://www.weisner.com/training/dreamweaver_help.htm or 800-646-9989.
Sponsored by DigiPub Solutions Corp, producers of PDF 2001
Conference East, June 4-5, Baltimore/Washington D.C. area. http://www.pdfconference.com or toll-free 877/278-2131.
---
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.
