RE: instructions for a pb&j sandwhich - a little OT

[Richard Lippincott <richard -dot- lippincott -at- ae -dot- ge -dot- com>]

	Sean B:
	>Agreed, I too would think twice about hiring a guy whose
instructions on
	>making a sandwich included "putting a glass jar" between the slices
of
	>bread. However, if those words weren't explicitly written, I'd look
long
	>and hard at the person who interpreted the instruction that way . .
..

Well...you get all kinds in the audience, I suppose. 

The thing about Sean H.'s story that rings true to me is I've spent almost
half of my technical communication career doing document testing (first at
an aerospace firm doing what's known as "validation/verification" per
contract requirements, most recently at a telecommunications company where I
convinced them that they needed a full-time document tester in their QA
department). 

I used to explain that the way I'd do my job was to tighten my tie (back
when we wore ties...I told you I've been doing it for quite a while) enough
to cut off the oxygen flow to my brain, so that I'd stop thinking and simply
follow what was written...literally, to the letter, and without
interpretation or assumption. Then, when things get goofed up beyond
recognition, comment back to the writer "This doesn't work as written."

In the case of the P&J sandwich, I can see how you get the glass jar between
the slices of bread. Try these steps:

1. Obtain a jar of peanut butter.
2. Obtain two slices of bread.
3. Place the peanut butter between the slices.

Ooops...did we forget to tell the user to open the jar of peanut butter? Did
we forget to tell the user to obtain a knife to spread the peanut butter?
Having forgotten those steps, how would one literally place the peanut
butter between the slices? By putting the glass jar there.

Sure, it's silly, it's not realistic, and of course "everybody knows" what
steps are missing. 

The problem is, the thought process that left out those steps that
"everybody knows" is the same one that resulted in some software
installation instructions that I had to fix: ones that forgot minor details
like "Insert the tape now" or "Configure network settings before rebooting
the system." (And, unfortunately, yes I really encountered both of those
errors.)

In the case of the telecom company, the knowledge base of the customers
ranged from very high (we could have simply written "Here are the tapes,
there is the system, have a nice day" and they'd have gotten it) to very
very low (some smaller companies simply hired cheap labor who had quite
possibly never used a computer before). Some of the incorrect steps, if
followed literally, would have brought down the system and caused an
interruption of service. That would have brought the customers back
screaming at us, and "Your people should have known to do this" wasn't going
to cut it as an excuse for why the steps were wrong. 

YMMV, but I've seen some incredible mistakes in procedures...personally I
think the only way to chase them down is a formalized process of document
testing, but that's the subject of another discussion.

--Rick Lippincott
  Saugus, MA


^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
Check out RoboDemo for tutorials! It makes creating full-motion software
demonstrations and other onscreen support materials easy and intuitive.
Need RoboHelp? Save $100 on RoboHelp Office in May with our mail-in rebate.
Go to http://www.ehelp.com/techwr-l

Free copy of ARTS PDF Tools when you register for the PDF
Conference by May 15. Leading-Edge Practices for Enterprise
& Government, June 3-5, Bethesda,MD. www.PDFConference.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.