Re: Overcoming Technophobia

[Bonni Graham <Bonni_Graham_at_Enfin-SD -at- RELAY -dot- PROTEON -dot- COM>]

Kim asks:
So, would you be willing to mention how you tried to help the technophobics?
--end of original message

Turn down an opportunity to pontificate?  Moi?

Seriously, I followed a couple of rules:

1) Write cleanly and clearly.  Use grammatical sentences (especially for
teachers!!!!).  Use simple words.  Explain each new term before using it
further, and try to find the simplest word for it.  Match the terminology to the
program (i.e., if they call it a dialog box, don't call it an information
window, no matter how much more sense it may make).  I had to break a rule of
mine -- don't say "the X key/button".  Normally I hate that construction.  It's
wordy and obvious -- non-phobic users will know what "press ENTER" means.  BUT,
phobic users might spend a few minutes looking for the OK key on the keyboard if
you don't specify that it's a button.  Be sure to make it clear that buttons are
on the screen and keys are on the keyboard.

2) Use a clean, familiar, easy-to-read typeface.  I used Century Schoolbook
(anyone wanna guess why?) and Helvetica (even though I don't like it, its clean,
easily recognizable lines made sense here).  I also used a keypress font (one
that comes with CorelDRAW) for things like ENTER, TAB, etc.

3) Sound like an expert.  These people want their hand held by someone who
really knows what they're doing -- don't be too colloquial in your word choice.
On the other hand, DEFINITELY don't use jargon if there is ANY way around it.
If you HAVE to use it, explain it in the text AND put it in the glossary.  BTW
_their_ industry jargon is OK to use -- it will make them feel at home.

4) Know what they're phobic about.  In my case, I'd worked with teacher enough
to know that they were primarily worried about a) hurting the hardware and b)
corrupting their data.  So I made a big point of warning them where a misstep
would hurt the database.  If there was no warning, they could be comfortable
know that they probably couldn't mess it up at that step.  And, since I had
warned them so consistently about the data, they knew I would tell them if
something would hurt the hardware -- since I didn't, it must not be possible.

5) Be graphical.  Non-phobic users probably don't need a screen shot of every
screen.  Phobic users do, because they're never really sure they're at the right
place until you tell them they are.  I included a screen shot of every dialog
and important warning message (except the two I couldn't get the right sample
data to produce -- but I'm fixing that in the next iteration).  I placed a
little mouse icon in front of steps that required mouse action and a keyboard in
front of steps that required typing (Windings, for those who're interested).

6) Make it look easy.  Keep procedures to about ten steps.  If this is
difficult, see if you can group steps into an overall step and substeps.  e.g.:
   1) Load the file:
      a) select File from the menu bar
      b) select Load from the File menu
      c) double click on the file you want to use, etc.
As in the example above, always provide some kind of navigation (from the menu
bar, from the File menu), but always put it last.  After they are familiar with
the selection location, they can stop reading after "File" or "Load".

7) Think carefully about information placement.  I split the doc into two
sections.  Information that answered the question "What is it/what does it do?"
went online.  Information that answered the question "How do I do it?" went on
paper.  This solved two problems:

   a) How can the users have the information on how to use the product open
      while they used it? (ANSWER: they can put the book in their laps, on the
      desk, etc.  They can also take it home to familiarize themselves with the
      procedures.)

   b) How can the users get descriptive information quickly without having to
      puzzle out what the feature is called, risk paper cuts from flipping
      through pages, etc.? (ANSWER: they can press F1 and get context-sensitve
      help for the dialog.  They'll probably only want this specific data entry
      information while they're actually entering data into the program)

So far, this split has been the biggest hit of the doc set.  In every screen
shot, I included a keypress character (F1) that reminded them that help is
available for this screen.  The programmer is also adding a status line to each
screen to remind them of the same thing.  They can't miss online help.
Splitting the manual this way also helps keep the procedural steps simple and
uncluttered.

I'll probably be using this info as the basis for one of my 1994-95 conference
year paper topics, so let me know if any of you want a copy once I've gotten the
paper together (or have any good ideas that I didn't use in this project -- I'll
credit you, of course).  Until then, hope this helps!

Bonni Graham                               | font, n. Loosely, a typeface
Technical Writer                           | or family of typefaces.  A
Easel Corporation, ENFIN Technology Lab    | bit-mapped font is one that
Bonni_Graham_at_Enfin-SD -at- relay -dot- proteon -dot- com | displays a typeface on the
President, San Diego STC                   | screen of a computer.  Type-
                                           | faces for laser printers,
NOTE: apparently my email address needs    | which must be kept in
to be typed exactly as it appears here,    | the Blessed System
punctuation and all, or the system gets    | Folder, are known as bap-
upset.                                     | tismal fonts.
                                           |          --Ezra Shapiro