Database Reference
In-Depth Information
The prototype is likely to change rapidly, so wait until it has stabilized before making the documentation
consistent with it.
Although I often suggest hand-drawing a paper prototype rather than creating it on a computer, I make
an exception for documentation; because of the greater amount of text, it's probably faster to draft the
content in a word processor and print it out. Whether handwritten or typed, avoid the temptation to do a
lot of formatting—first-level headings are about the right level of detail for now.
Prioritizing the Informational Needs
If you're a writer or trainer, testing a paper prototype will show you what information users truly need, as
opposed to what's nice but not necessary. You'll also get a sense of where users look for information
(for example, do they notice the context-sensitive help?) Years ago I helped conduct some tests of
Lotus 1-2-3 with a couple dozen spreadsheet users, and we found that no one had trouble changing
font size, color, style, and so on. This was true even for people who weren't familiar with the
application. Naturally, the manual had a whole section pertaining to cell styles, but not one user looked
at it. On the other hand, there were some tasks that users found more difficult, and for those they did
turn to the manual.
I'm of the belief that not everything needs to be documented. I like to joke that the tech writers at Lotus
could have replaced all the nouns in that chapter with names of vegetables and no one would have
noticed. Although that's a funny image, the serious issue is that someone had spent time documenting
functionality that was self-explanatory, whereas harder-to-use functions remained undocumented. Even
tech writers who believe that everything should be documented may still find it useful to know the
relative priority of all the material they're responsible for. That way, they can devote more time to the
things that are harder for users.
Search WWH ::
Custom Search