Teaching without seeming to teach!

["Geoff Hart (by way of \"Eric J. Ray\" <ejray -at- raycomm -dot- com>)" <ght -at- MTL -dot- FERIC -dot- CA>]

George Hayhoe observed that <<Before 99% of the potential user base
can "read to do" in a user's guide or online help... they need
conceptual information before they can deal with the procedural
information...>> However, this poses a Catch-22: <<As Deb and Eric
say, the problem is that novice users don't want to be bothered with
the underlying concepts--they've got other work to do. But without
those concepts, the cookbook instructions in software documentation
make--at best--only limited sense.>>

You prefaced your original message with the note that some tasks
(e.g., databases) aren't at all familiar to users. I won't object to
the general point that our audiences are increasingly being asked to
do complex, unfamiliar jobs, but I strongly dispute the notion that
it's our responsibility to document something truly alien: If the
tasks are truly unfamiliar to users, they simply shouldn't be using
the software. Nobody gets handed a fighter aircraft and told "here's
the user manual... now fly it!"

That's an exagerration, obviously, but we simply can't be expected to
serve as a substitute for people taking responsibility for their own
education and knowing when to tell their managers "I'm sorry, I
simply lack the knowledge to do this task without some training." We
_can_ do much of the job of teaching in almost every case given that
_every_ computer task has a "real world" equivalent, even if not a
really familiar one. For example, even though few of us have studied
"project management", everyone has marked appointments on a calendar,
tied a string around a finger to remind them to do something, or made
a list of groceries before inviting friends to dinner. Each of those
represents a potential analogy for project management software.

I think that the trick here is to think far outside the documentation
box here and don one of our other hats, that of the "instructional
designer". I agree that users don't want to attain a degree in some
area before they can use the software: they just want to use it.
This suggests that the solution is to use our audience analysis
skills to identify all the common tasks users will want to do,
something that we're already good at doing. But instead of
documenting these tasks as "dead", noninteractive text, we should use
that task list to develop something like a "wizard" that walks users
through the tasks while surreptitiously teaching them how to do it
on their own.

Let me qualify this statement: wizards can be really, really annoying
(i.e. patronizing and slow), and should probably represent a shortcut
to learning, not a replacement for it. So the trick is to build the
learning information into the wizard: "Step 27. Click the [] icon on
the toolbar to print your document. (You can also press control-P.)"
How does this achieve our goal? First, it lets neophyte users step
through <shudder> 27 steps without having to remember any of the 27
steps. Second, after one or two repetitions, the users will gradually
learn what must be done.

Let's back up a step further and look at higher level tasks. "OK, so
you've been told you're a project manager, and you don't understand
what either of those words mean. Don't panic. Have you ever made a
list of tasks to do (e.g., drop the cat at the vet's) before going
grocery shopping? Congratulations! You're a project manager. Now
let's use that as an example of how Projectmaster can plan projects."
That's obviously simplistic, but it demonstrates the overall approach
quite well: start with a familiar task, demonstrate how the software
does something similar, then make repeating the process painless via
wizards, without requiring power users to use the wizards.
--Geoff Hart @8^{)}
geoff-h -at- mtl -dot- feric -dot- ca

When an idea is wanting, a word can always be found to take its place.--Johann Wolfgang von Goethe

 From ??? -at- ??? Sun Jan 00 00:00:00 0000=