Help
Development: "Just in time, and just enough"
by Verlane
Edwards
You've heard it before.
It's the popular mantra for training initiatives; it should be a guiding
principle for every technical communicator; and it's a lot more of a challenge
than it might appear to be. "Just in time" means that as users discover
a learning need, they are able to immediately access a resource to satisfy
that need. "Just enough" means that learners can find the answer to a
question quickly without having to weed through volumes of unwanted data.
For example, if the learner simply wants to know how to use the Internet,
she shouldn't have to sit through a course or access a resource that waxes
on about the history of Internet development or the vagaries of HTML.
All the user is thinking is "give me the steps, and give them to me now."
Too often technical
writers fall into the "tell them everything and tell them all at once"
pit. Guided by a well-meaning desire to "educate" users, what these writers
typically do is overwhelm them. Finding the information you need when
you need it is a key to success in every business function of every
company. Therefore, technical communicators who are able to provide their
customers with quick and useful knowledge bring an incredible added value
to a beleaguered work force constantly expected to do more and to do it
faster.
That's probably never
truer than in online software assistance. Whether you are a seasoned user
or someone who's never opened the program before, you should expect the
Help system to make it easy to access the information you want, when you
want it. So how can we help users in their "how do I do this"
searches?
Here are three fundamental
suggestions to get you started.
-
Focus on the
users' actions, not the program's functionality.
Anyone writing
end-user support material needs to get away from the narrative-focused
"what the program does" descriptions, and concentrate on action-focused
(and user-centered) "what do you want to do?" instructions.
| Since
much of what we do in the workplace is task-oriented, it's only
logical that the knowledge resources we use be designed the way
we work. That is not to say learners should never be given the "why."
In some cases, an understanding of why something is being done is
essential, but often a quick tag line, such as "in order to balance
your statements accurately…" is sufficient—versus a two-paragraph
didactic soliloquy on the importance of accuracy. Save the speeches
for the CEO. Keep the Help topics short and simple. |
"The
ultimate metric that I would like to propose for user-friendliness
is quite simple: If this system were a person, how long would
it take before you punched it in the nose?"
—Tom Carey
|
Field-level definitions:
If you can provide one-click-away field-level help to answer those "what
does this mean?" questions, all the better. If you're only able to provide
window/subject-level support, then provide a link to the field definitions
for that window, so the users have quick access if that's all they really
need.
Remember what
help is…and isn't: Keep in mind that application Help is there to
"help" users do the job they already know how to do using this new tool
they may not know anything about. It is not to teach them how to do
their jobs. That's another educational need—save that kind of assistance
for tutorials or other training tools. If you remember your purpose
and keep the Help focused on the user's action needs, you will neither
overwhelm new users nor insult experienced ones.
-
Structure single
topic actions, with logical relationship links.
|
Remember
that the user can access the Help from any point. That means
that each topic should completely cover that single topic only.
If the topic is "Drawing…" it shouldn't cover how to add color.
However, if they need to set something up before they can draw,
maybe Step 1 is a relationship link to that "set up" topic.
When you've covered "how to draw," logically relate it to similar
topics. That's what your Help system's navigation is for. Use
it the way your users would.
As a general
guideline, create no more than three key, related-topic items.
Your goal is not to supply users with a sea of potential clicks
that will keep them sailing through your Help facility until
they forget at what port it is they need to dock. If the topic
is "How to Draw Circles," this is the place to link to "How
to Add Color to Circles" and "How to Create Multiple Circles,"
but it isn't necessary to link to a topic on "How to Draw Squares."
They can get to that new topic another way, such as the table
of contents or the index.
|
"Technical
writing... requires understanding the audience, understanding
what activities the user wants to accomplish, and translating
the often idiosyncratic and unplanned design into something
that appears to make sense."
—Donald Norman,
The Invisible Computer
|
- Make easy navigation
a design priority.
No matter how
complex the application, Help should be easy to read and its navigation
should be simple to use. Ideally, access to major support topics in
Help should be no more than three clicks away. What those major support
topics are varies based on the context of what you are documenting,
of course, but again think "What will the user want to do?" and organize
access to those actions accordingly.
Easy navigation
includes a common sense, high-level table of contents that enables
a quick scan of major action items. The table of contents is a key
navigation tool for many users, so, again, it's important not to overwhelm
them with every detail in the Help. Save the minutiae (and their synonyms)
for the index. A thorough search feature allowing users to get at
every detail when they want to do so is a navigational must.
*
* *
Tailoring Help to
user needs and offering it instantaneously is a challenging goal, but
it's a target at which every Help developer aims. Just in time and just
enough also hits the mark in terms of how
we learn and how we retain information. We're more likely to remember
that which is most relevant to us and that which we can apply soon and
often. We can assist those who use Help by providing "just enough" precise
instructions that answer their key performance-improvement question: "How
do I do this?"
Verlane
writes for GuideOne Insurance in West Des Moines.
|