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.
Subject:Re. Warnings... From:Rick Lippincott <rjl -at- BOSTECH -dot- COM> Date:Wed, 3 Jan 1996 14:36:14 EST
Nora Merhar suggested that all admonitions be called "notes" and then leave it
up to the reader to determine which involve safety hazards.
I think that in the lawyer-ridden USA, corporate legal departments would have
a cow at that thought.
Yes, I agree that a reasonable and intelligent person -can- determine the
degree of risk. Unfortunately, in a country where people apparently don't
know that coffee is hot and refrigerators are heavy, it's not good enough.
In order to avoid a potential lawsuit, many legal departments require something
like the following:
* A safety hazard must appear immediately before the step that produces or
involves the hazard.
* The safety hazard must have some sort of clear logo that communicates
danger. (I.E, it should say "Warning" or "Danger.")
* In addition to saying words like "Warning" or "Danger" it's likely that
you also need some sort of icon or pictogram that suggests the type
of hazard (picture of fingers caught in gears, or pictures of
flames, or lightening symbol).
* Putting all the info at the beginning of a manual isn't good enough. The
warning must come immediately -before- the step in question, and must be
repeated every time the hazard crops up.
* You must list -every- potential hazard at every possible place.
(Soapbox mode on)
On that last item, some of you may say "That's silly, you could end up with
pages nearly full of warnings, but only one or two steps per page." You're
right, it's silly. And you end up with -exactly- what is described, it
exists in many manuals right now. (This is something that crops up often
in the hardware documentation world, not so often in software docs...)
The fear by corporate lawyers is that following an injury or death, the
ensuing lawsuit will look for -any- angle to get a cash award. ("You failed
to tell our client on page 21 that there was an electrical hazard present
when dealing with live wires and standing knee-deep in salt water." Never
mind that in order to get to page 21, the user had to do the steps on page
20 where there -was- a warning....)
What's the most ridiculous warning I've ever seen? Well, in jet engine
maintenance, sometimes you have to put an ink mark on a disk or blade as a
reference point. The approved tool is a "Marks-a-Lot" (TM) or eqivalent
magic marker. Did you know that if you have the raw ink from a magic marker
in liquid form, in sufficient quantity, in an open container (i.e. a pan or
bucket full of it), it will burn? Anybody ever seen a pan full of magic marker
ink? Not me. But we were required to put a "Fire Hazard" warning in front of
some steps using the markers.
And it's no defense to claim that the victim abused the product. That goes
back to my refrigerator reference earlier. Within the past year or two,
a man took part in a race where contestants run a measured distance carrying
a refrigerator on their backs. This man injured himself, and sued the
refrigerator manufacturer on the grounds that "there was no warning on the
product telling me that this was dangerous." He collected money.
(Soapbox off.)
An issue that's rarely been considered on this list (or, so far as I know,
by the STC) is the adverse impact on usability as a result of all these
hazard warnings. (On this list, I think most folks are involved in software
documentation, so it's just not encountered on a daily basis.) I explored this
a little bit about a year ago, but discovered there is almost no data in this
field.
Rick Lippincott
Boston Technology
Wakefield MA
rjl -at- bostech -dot- com