Online help requirements questions for user advisory group?

["Hart, Geoff" <Geoff-H -at- MTL -dot- FERIC -dot- CA>]

Victoria Mezydlo (welcome to the fray!) is developing <<... a list of
questions regarding online help requirements to 
present to an User Advisory Group. This group represents the end users who
will eventually use the online help in their departments. The questions are
supposed to help generate the group's input on how we should design the help
interface and organization of the help topics (such as procedures, policies,
general information, etc.).>>

An excellent idea, and congratulations on the opportunity; try to get this
perceived as standard operating procedure, and keep a wary eye open for
grumblings that might lead someone to cancel the program (e.g., a manager
who starts muttering about how much time you're spending). Here are a few
thoughts on the types of questions you should ask:
- What types of tasks do the users perform commonly and perform rarely?
(Both must be documented, but this may provide insights into how to
prioritize help development. It can also suggest which tasks the developers
should make simpler to use or perhaps even automate.)
- What kinds of information do they need to support these tasks? (We tend to
assume that there are only two types: procedural steps and "this field
contains only numeric data" types of reference material, but often we
discover that users also need contextual information to see how a series of
tasks fit together, tips and tricks, and so on.)
- What levels of detail do they need for typical tasks? (Sometimes they'll
want each step explained; other times they'll just want to follow the steps,
without bothering with explanations. Sometimes they'll want both, and you'll
have to provide an initial summary of the steps at the start of a topic for
those who just want steps, followed by detailed explanations of the steps
for those who need the details.)
- How often do they use tables of contents, indexes, and search tools to
find information? (Again, this tells you how to allocate your efforts to
developing these aids, but in addition, it may point out other problems; for
example, if nobody uses the index, it may mean that you need to relearn
inadequate indexing skills, teach them how to use the index, or something
else entirely.)
- "Contextual inquiry": Under what working conditions do they consult the
docs? (This can tell you what to include and what to avoid; for example, if
they all use "dumb" non-graphical terminals to a mainframe computer, forget
about animations and sound and myriad floating windows; if they work with a
cluttered screen full of fields and buttons, you have to keep the help
system small so it doesn't obscure the work area, and this suggests you may
need to build much of the help into the interface itself via "affordances",
or even redesign the interface.)
- What problems do they typically encounter with help systems and with the
interface? (Find out the source of the problem--which can be tricky to
distinguish from the symptoms--and see what you can do about solving it. Use
this to guide your design.)
- Open the floor to general questions and suggestions, and make sure they
know that they can contact you directly to provide confidential, private
feedback if they're embarrassed to ask questions publicly. See if you can
identify "typical" users willing to give you some of their time when you
need to explore issues in more depth. Formally set up a testing program so
you can do iterative design: determine how to solve a problem based on their
feedback, solve the problem, then test to see whether you solved the correct
problem, really did solve the problem, and didn't introduce new problems.
Redesign, and try again.

<<I have researched design/organization requirements from a developers
perspective, but I am looking for information on how to get the end users to
help make suggestions instead of the developers just assuming how the help
will be used.>>

Given that you've got the chance to talk directly with the users, invite a
developer or two to attend each meeting and listen in (with the explicit
rule that they can't be defensive, but can ask questions to clarify
problems!). Developers often exist in their own world, with their own
stereotypes of the users, and often learn valuable lessons from listening to
actual users. I've read a few anecdotal reports of developers exclaiming
"they're not supposed to do it that way!" while watching users use their
products, then getting a clue and going "oh... maybe I should redesign the
interface to support doing it that way".

--Geoff Hart, FERIC, Pointe-Claire, Quebec
geoff-h -at- mtl -dot- feric -dot- ca
"User's advocate" online monthly at
www.raycomm.com/techwhirl/usersadvocate.html

"The most likely way for the world to be destroyed, most experts agree, is
by accident. That's where we come in; we're computer professionals. We cause
accidents."-- Nathaniel Borenstein

^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

*** Deva(tm) Tools for Dreamweaver and Deva(tm) Search ***
Build Contents, Indexes, and Search for Web Sites and Help Systems
Available now at http://www.devahelp.com or info -at- devahelp -dot- com

A landmark hotel, one of America's most beautiful cities, and 
three and a half days of immersion in the state of the art:
IPCC 01, Oct. 24-27 in Santa Fe.  http://ieeepcs.org/2001/

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