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.
>As to the hoary quality standard of "I talked to a couple of users and they
>liked the manual", you find during testing that even users who profess to
>like something often won't or can't use it. I say again, with emphasis...*If
>you ain't tested it, you don't know.* I realize the father of the manual
>finds it hard to imagine, but just because there's an answer in
>there...somewhere...it doesn't mean the damned thing is usable.
Hi, I think this is my first post to the actual list -- I usually reply
off-list to folks.
I'm a brand-new writer. I have a degree in Biology and dropped out of grad
school to start a new career 3000 miles away -- in technical writing.
I'm an intern, and I'm taking a certification course. And guess what? It's
Sure, there are plenty that aren't -- that's the fault of the teacher, not
proof that education is useless.
The best part of this program so far has been the demonstration of a quick
usability test (not strictly a usability test, but it worked for class
purposes). Every student wrote a short manual on a subject they knew well.
Once they'd written the final draft, everyone brought in their manuals and
the materials needed to follow the manuals. They handed over the manuals
and materials to another student, and watched as that student attempted to
follow the procedure.
It was a disaster. A very, very, educational disaster, as my teacher
intended! Despite the simplicity of the tasks, and the weeks that the
writers poured into writing them -- plus edits of each draft by both a
fellow student and the teacher -- most of the manuals were not followed
very well. The most unexpected sentences and situations caused the testers
to stumble and make mistakes! I was astounded and learned at the very
beginning of my new career just how important testing is.
You wouldn't send your children to a school you didn't research. If you're
interested in a good certification program, go research them and find a
I'm up for a good discussion as much as the next person, but this one is a
little strange. It seems obvious to me that:
-you need to make deadlines,
-you need to know your product,
-you should make your manual as painless to read as possible (that means
-that if you hit on a good system, you should stick with it (hence a style
-theory helps (don't reinvent what someone discovered 100 years ago -- I
wish I knew a lot more),
-you also have to write things (don't spend all of your time playing with
-if you don't know how to use the tool, how on earth will you get anything
done? (if you don't know it, demonstrate that you can learn it in a hurry
or go to the trouble of learning it!)
-if you're not writing what your readers want to know, you're not doing
So you're all right and you're all dead wrong, and you need more work so
you can stop nitpicking. ;)