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.
Dave Stewart reports <<my fellow writers have commented to me that "XYZ
Company has great documentation" or "customers consistently rate XYZ
Company's documentation very high." Unfortunately, they can't tell me
exactly WHY the documentation is so good.>>
That's pretty common, and it often indicates nothing more than that they
like the look, whether or not they could actually use the documentation to
accomplish a task. If they've got comments, ask them to put their money
where their mouth is. To pin down exactly what they like about the XYZ docs
and what they like less about yours, come up with a simple evaluation
checklist. In tht checklist, create sections that group together questions
related to a specific topic that relates to the quality of the docs by
rating your documentation versus the XYZ docs. For example, create a heading
entitled "Formatting", and make up a checklist under that heading to include
things such as readability of the font, font esthetics, use of white space,
and so on. Now add a second heading, called "Navigation", and add checklist
items that ask them to compare the indexes, heading hierarchies, table of
contents, etc. You can use numeric scales, but it might be easier to work
with words such as "unacceptably bad" through "best I've ever seen". You'll
end up with a series of comparisons of each feature of your docs and those
of XYZ, and where your docs suffer by comparison, you can dig deeper to find
out the cause.
A well-designed checklist will at least provide you with concrete feedback
on what the critics like and dislike, and you can then follow-up to see
whether this is something that needs correcting. Don't forget, some
criticisms will be nothing more than subjective personal preference rather
than something that really needs to be corrected. The feedback may also fail
to provide any useful information on whether the _users of your software_
(as opposed to your colleagues) like your docs, so proceed with some caution
in interpreting and applying the results.
And, of course, if you have any specific "best practices" questions that
arise from this exercise, drop us a line and we'll provide our own feedback.
--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
"The most likely way for the world to be destroyed, most experts agree, is
by accident. That's where we come in; we're computer professionals. We cause
accidents."-- Nathaniel Borenstein
*** Deva(tm) Tools for Dreamweaver and Deva(tm) Search ***
Build Contents, Indexes, and Search for Web Sites and Help Systems
Available now at http://www.devahelp.com or info -at- devahelp -dot- com
Learn about tools and technologies for user assistance developers at
The Help Technology Conference, August 21-24 in Boston, MA
Details and online registration at http://www.SolutionsEvents.com
---
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.
