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.
I've seen such "guidelines" before. To my mind, they're of little value
without some greater detail.
What is "your best"? Does doing "your best" require you to stay current with
the latest research into usability, or just to stay sober through the day
and not make too many spelling errors? Is it incumbent on you to never
question a boss's order? Do you, personally, have any responsibility for the
eventual product of your labors? If not, how are you different from someone
assembling units on the assembly line?
How do you know the audience and write to them? Do you poll them, or just
make assumptions? Do you test, or are guesses good enough? Have you checked
them out recently? Have you visited them? Have you given them any feedback
mechanisms? Do you have a tear-out card in the manual or a page on the
website with a form? Have you done a complete user profile?
To my mind, if the manual my company produces doesn't work, then we have
failed, regardless of the client's mindset. When I was an employee, I felt
exactly the same way. I detest failure. Manuals should be judged, not on
whether the boss is happy with it, but on whether it does the job, as
expressed in specifications agreed upon before writing begins. Manuals, like
pig feed, pumps, and software, should be judged on functionality, not on
speed of production or the degree of management satisfaction.
If the goal is to rush out something that has text and pictures, then why
bother at all? Why waste the money? Why bother to get up in the morning? I
can make nearly as much money assembling on the line. If I'm producing
something of only marginal usefulness in front of a computer, I prefer to
work on the assembly line. At least there I know I'm contributing directly
to the profit margin. And my output can be tested, my capability shown in
simple metrics. Manual usefulness can be tested in precisely the same way,
but rarely is. It's ironic that in many companies, the youngsters on the
line are held to a higher standard than is the fellow in the shirt and tie
operating Microsoft Word in a cubicle, responsible for making the technology
understandable to customers.
Tim Altom
Simply Written, Inc.
Featuring FrameMaker and the Clustar Method(TM)
"Better communication is a service to mankind."
317.562.9298
Check our Web site for the upcoming Clustar class info http://www.simplywritten.com
> So far as I'm concerned, technical writing's essential rules are the same
as
> writing for a magazine, newspaper, or other publication:
>
> 1) Do your best.
> 2) The editor/boss is always right.
> 3) Know your audience and write to them.
> 4) If you think you know a better way, diplomatically discuss it with your
> editor/boss. If at the end your editor/boss disagrees, refer to rule 2.
>
> These rules are in order of importance. All other rules come after. Is
> that so hard?
