RE: Do I have to understand the material?

[Allen Schaaf <soundbyte -at- sound-by-design -dot- com>]

At 09:15 AM 8/20/02, Sean Hower wrote:

Comments follow:

---------------------------------------
Kent wrote:
More to the point, if the tech writer is indeed a good user, he or she is 
still a sample of one. ... The point, then, is manuals should be 
tested.  By users.  And, for heaven's sake, don't think the subject matter 
expert is a user--he or she knows too much and isn't objective.
---------------------------------------

Don't know if this has been said already, but,
unless you have experience using the product in a "live" environment, and 
have experience working in that environment, you're not a user, you're 
still just an employee writing about a product. Sure, you may have the 
user's perspective in mind. You may even have a really good idea about the 
users, through contextual inquiry, ethnographic research, site visits, what 
have you.....but you're just not a user. :-( It's cruel, but true (as we 
used to say in 5th grade). I find any information gathered from internal 
"users" suspect, mostly because unless they are using the product in the 
same environment as the customers, the employees just aren't objective. 
They'll have access to resources and information that the normal/average 
user won't. They will have probably had many experiences with the product 
that the user wouldn't have, or shouldn't have....

You betcha'. This is such common thinking at companies that before they 
have released their product, they are already using crutches because they 
shot themselves in the foot.

---------------------------------------
Allen wrote:
Amen!  Software is QA'd, why not manuals?
The lack of end user input in manual production is the weakest link in tech 
pubs, but get a manager to understand and provide time for it? Pigs'll fly 
first.
---------------------------------------

It's not necessarily management, but upper management...the ones controling 
the money. They make the decisions, based on their understanding of the ROI 
involved. If they don't understand that user testing for manuals can have 
an ROI, then it's our job to demonstrate it. :-) (Not tell, demonstrate. 
Words are a weak tool in this respect, demonstrations are not.) Educate, 
negotiate, cajole, you know, get them to see things your way. If they 
don't, it's their company....it's their decision. We are working for them. 
While it's our job to help them make a better product, it's also our job to 
do what they want. They're the client. The client is always right....even 
when they're wrong. <sigh />

--------------

Allen responds:

The resistance of lower management is merely a reflection of the ignorance 
of what the company does, in reality, by upper management.

Lower management is not going to fight with their bosses because they might 
be perceived as "difficult" and out they go.

The only success I have ever had on this issue is by talking with SQA/Tech 
Support and get them to add to their trouble tickets a box that says 
something like: "Material was in manual: Did customer find the correct 
section? Did customer understand what they read?" I would like a little 
more than this, but it gave me a metric on what percentage of tech support 
calls were manual issues of either bad indexing or poorly (from the end 
user's POV) explained functionality.

At one place they admitted that support calls cost as a bare minimum $25 
each, and some would cost anywhere up to a $1000 dollars or so to resolve.

If you can get metrics like this, you can push for better review of 
manuals.  However, I will note that I have never succeeded in getting end 
user reviews.

ILM gets end users in to test their games and see if odd-ball key strokes 
cause failure or if there are confusing parts of the game that the end user 
just doesn't get.  If they can do this, why can't the rest of the tech 
industry?


Allen Schaaf
Sr. Tech Writer
Currently looking for work.

Who says bad manuals aren't a risk to your life?  Just ask the passengers 
of the jet where the engine caught fire because the company's maintenance 
manual was wrong about how to install one key bolt.  (NTSB Report on GE CF6 
engine fire, American Airlines flight 574, July 9, 1998. 
<http://www.ntsb.gov/publictn/1999/AAB9903.htm>)



^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
Check out the new release of RoboDemo, our easy-to-use tutorial software.
Plus, buy RoboHelp Office in August and save $100 with our mail-in rebate.
Get details and download free trial versions at http://www.ehelp.com/techwr-l

TECHWR-L is supported by ads and sponsorships...and donations.
You can help maintain the TECHWR-L community with donations
at http://www.raycomm.com/techwhirl/abouttechwhirl/donate.html

---
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.