RE: Encouraging users to read online help

[SIANNON -at- VISUS -dot- JNJ -dot- com]

I originally sent the post appended below straight to Michelle, but seeing 
the number of "the help must be bad if the users won't use it" arguments 
submitted, I felt I should pass on some of the reasons I have found 
_upon_questioning_users_ that they won't use a helpfile.  They often have 
nothing to do with the quality of the help, but rather the quality of the 
training (or complete lack thereof).

I often see certain assumptions of competency show up in discussions here, 
-- not a problem, if you work in an environment where those assumptions are 
true, but many of us work in an environment where employee training does 
not include basic subjects like use of the operating system (users are 
expected to already know it by media osmosis, apparently), trainers who do 
not write the materials gloss over or skip subjects they deem unnecessary 
because they don't know their own audience, and users only find out about 
training and reference materials by word of mouth.
     A quick example: I had a developer who was convinced the users 
couldn't be trained on the system until they got their userIDs set up; this 
despite the fact the security form used to set the IDs up requires a 
signature verifying that the person has been trained on the use of the 
system. It turns out the developer (who was also the trainer) was so used 
to on-the-job training, he wasn't using the training materials when he had 
them, thereby reinforcing the idea in the users' minds that the materials 
weren't useful.  I only found out after crashing a training session that he 
wasn't bothering to even *mention* the online reference manual's existence 
(the developers didn't bother to incorporate *any* link to help from within 
the app., so I had to make it a standalone file accessible through the 
LAN).

Anyway,...

------forwarded text:------------
Dunno if this will work, but it's an idea:

Talk to the HelpDesk people.  Express your interest in reducing their 
workload by getting users to use the help available instead of going to 
them for every piddlin' little thing (usually tech support gets sick of 
"how do I use this, where's the Any key?" kinds of questions anyway, so it 
shouldn't be too hard to enlist their help). Ask if (possibly following 
some training from you on how to use the helpfile to its best effect) they 
could walk users through the helpfile whenever they call in with those 
kinds of questions, rather than just answering the questions for them 
directly.
     *Showing* the users how the answer was at their fingertips all along 
can address several causes of this behavior: (1) fear of using help 
(something a lot of techies underestimate or dismiss offhand, but which has 
been given to me _by_users_ as the reason they won't use help...it confuses 
them, because the commonly-understood conventions of helpfiles really 
aren't, and few people train users on how to use the helpfiles when they 
train them how to use the app.  Usually, helpfiles are referenced in 
training as a "by the way, if you hit help you'll get the helpfile" which 
accomplished nothing.), (2) pure ignorance over helpfile content (I've had 
users not realize what kinds of information are available in a helpfile 
simply because it had never come up...many users are unaware of 
context-sensitive help unless they are specifically shown it as part of the 
training), and (3) impatience/arrogance (finding the answer to a question 
so easily available can embarrass arrogant, difficult users into going to 
help first so they don't look like an idiot in front of people they feel 
are their peers or subordinates).

-------------end forwarded text------------------------------

While the "customer is always right" is usually a necessary maxim to 
follow, sometimes the customer simply isn't. Sometimes, they just want 
things to work their way, so they don't *have* to learn how to use the 
product. Before arbitrarily redesigning the help, it would be good to 
verify whether or not the problem might be coming from another element in 
the communication loop. Communication requires reception of the message, as 
well as projection of the message. If something impedes reception, you can 
rework the message all you want and they'll never get it.


Just my opinion, but I figured that part 
of the issue was underrepresented so far,
Shauna
(now watch, Geoff will have posted this amazingly clear, concise post that 
says everything I just tried to say and more while I've been sitting here 
typing)



^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
Collect Royalties, Not Rejection Letters! Tell us your rejection story when you 
submit your manuscript to iUniverse Nov. 6 -Dec. 15 and get five free copies of 
your book. What are you waiting for? http://www.iuniverse.com/media/techwr

Have you looked at the new content on TECHWR-L lately?
See http://www.raycomm.com/techwhirl/ and check it out.

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