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.
Steven Brown wondered: <<I'd like to hear from those of you who've had
the opportunity to conduct or observe usability studies that involved
online help. What did you learn from the experience? What observations
did you make that have affected the way you write, design, or implement
help?>>
Not necessarily what you're looking for, but a couple data points:
Several years back, I attended an STC session by (I believe) Scott
DeLoach, who reported the results of a study of software users: the
statistics are long gone from my memory, but the message I took away is
that a great many people don't use help because they don't know it's
there; another large chunk know it's there but haven't figured out how
to use it, and won't try; and another large chunk have used poorly
executed help before and hated it so much they won't ever go back.
On that basis, I included a short "how to use the help system" section
in my manual. I also persuaded my colleague who was delivering training
on the software to spend 5 minutes on introducing the help system. I
have no hard statistics on this, but he seemed very happy at the
results: greatly reduced tech support calls. Since he was supporting
the software and doing training in addition to his full-time job, I
take this as a success story with a moral in it. <g>
Of course, to account for the third group of help users, you need to
devote enough time to create a kickass help system. Scott's data, plus
many anecdotal data I've seen/heard/read over the years, suggest that
it only takes one bad experience with your help system to ensure that
the user will never use it again if they have any other alternative.
This suggests you need to have a usability review to make sure your
system is as useful as you think it is.
Also, since many users start their search with the index, you need to
create a kickass index. If you don't know how to do that yourself, hire
an indexer to do the work--or at least pay for a couple hours of their
time and bring them to your workplace to train you how to create a
competent index yourself.
New from Quadralay Corporation: WebWorks ePublisher Pro! Easily create
14 online formats, including 6 Help systems, in a project-based
workflow. Live, online demo! http://www.webworks.com/techwr-l
Doc-To-Help 2005 now has RoboHelp Converter and HTML Source: Author
content and configure Help in MS Word or any HTML editor. No
proprietary editor! *August release. http://www.componentone.com/TECHWRL/DocToHelp2005
---
You are currently subscribed to techwr-l as:
archiver -at- techwr-l -dot- com
To unsubscribe send a blank email to leave-techwr-l-obscured -at- lists -dot- techwr-l -dot- com
Send administrative questions to lisa -at- techwr-l -dot- com -dot- Visit http://www.techwr-l.com/techwhirl/ for more resources and info.
