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: writing around desgin flaws From:Bonni Graham <bonnig -at- IX -dot- NETCOM -dot- COM> Date:Thu, 16 Nov 1995 09:16:38 -0800
Funny that this issue should come up now, since my most recent Project
from Hell (NOTE: actual location description, not profanity <g>) had a
number of these flaws. I first tried Gwen Barnes' (NOTE: appropriate
use of the apostrophe as a possessive for a word ending is "s")
suggestion of getting all my ducks in a row and going to the client.
The client refused to look at my ducks no matter how neatly they were
aligned, so I had to write around the problem.
I used the suggestion put forward by someone else (I unfortunately did
not note who) of simply writing the instructions for the most workable
workaround as though that was the best way to perform the task. OK, my
staff and I griped and moaned, THEN wrote the instructions. The client
accepted the work and I went on with my life (except for a few still
fairly frequent moments of bitterness, which will pass. I hope.).
In situations where I can, I then alert the hotline (Tech Support) that
calls WILL be coming in about this and provide additional workarounds I
have found, if any, so TS can present them to the customers who need
them. I sometimes (depending on the severity of the problem) alert
Sales or Marketing (or both) that the program may be taking hits for
the problem behavior, either in the press or from rival companies.
This allows Sales and Marketing to have ready answers to the problem.
I warn Training, so they can be sure to cover the workaround in
classes.
I try to do all of this in a upbeat fashion: not "the %# -at- $# (NOTE: use
of extraneous symbols to stand in for your favorite profane or emphatic
phrase of choice -- I don't want to limit you to the one *I* would
use<g>) program doesn't work and here how to make it work anyway" but
"in order to accommodate programming necessities, feature X works in Y
way. This may be confusing to the customer/repellent to the
reviewer/used by the rival sales force to indicate our lack of quality"
which steps on fewer toes.
--
Bonni Graham
Manual Labour
bonnig -at- ix -dot- netcom -dot- com
