Making a Paper Prototype - Paper Prototyping: The Fast and Easy Way to Define and Refine User Interfaces - page 72

addition to the incredibly intelligent help technique, here are some tips for technical writers and trainers.
Content and Method of Access
If you happen to already have print documentation and/or online help from the previous version of the
interface, sometimes you can include this material in the paper prototype test. Think of help/doc as
having two aspects— method of access and content. The method of access includes whatever the user
does to get to the material: click a Help button, type a term into a search engine, or open a manual to
the index. The content is what they see once they get there. Depending on the stage of your
development, you might have the method of access, the content, or both. (For training, it's a bit simpler.
The method of access is "the person attends a class," so trainers only need to be concerned with
content.)
Here's an example where we tested the help content but not the access to it. A company called Brix
Networks makes Web-based tools for Internet service providers. With all the technical concepts
inherent in their product, the development team anticipated that even their sophisticated target market
would sometimes want clarification of terms. For example, in setting up something called a verifier
group, users had to select one of five configurations from a drop-down list. One of the developers wrote
a description of each configuration on a sticky note—that was the "help content" for the task. If a
question came up about the options, we plopped down the sticky note on the interface ( Figure 4.20 ).
Eventually, this information was incorporated into the online help. Note that this method didn't tell us
whether or how users would access the help, but it did allow us to refine the help content.
Figure 4.20: The five options for verifier groups involved technical concepts. The handwritten
explanations allowed us to determine what wording would clarify the terminology. Eventually, this
information was incorporated into the online help.
Preparing Material for Testing
To simulate the method of access, if you have an existing manual index that has most of the right terms
in it, you (or rather, the person facilitating the usability test) could give it to the users and ask them to
show you how they'd look up their question. Similarly, if users say they'd go into online help and there's
no context-sensitive help topic for their current screen, the facilitator could ask them what they'd type
into the search engine. In any case, you should pay attention to the users' language and the terms they
naturally use—these are prime candidates for index and search terms, even if users don't use the
"correct" terminology.
If you don't prepare any content ahead of time, you can use the incredibly intelligent help technique. If
you do have time to draft some content, review the tasks and look for the top five or so areas where
you anticipate the user running into difficulty (especially in regard to concepts as opposed to the
mechanics of accomplishing a task) and start with those. There may be material from the existing
interface you can scavenge, or you might want to quickly write something. You don't need to cover
everything, however, and don't spend a lot of time documenting an interface you haven't tested yet.