Tech doc usability

[Chaunsee at aol.com]

In a message dated 1/10/2008 4:24:46 P.M. Eastern Standard Time,  
Deborah.McConnell at trizetto.com writes:

This  discussion group seems highly focused on usability of software  and
Web-based interfaces. But could any one briefly share his/her  experience
with usability testing of end-user tech docs?

Why did you  do it?
How did you do it?
Was there a resulting business  benefit?
Other advice?
 
Hello Deborah,
 
Documentation usability has a long history and there are a variety of  
methods for testing documentation.  One of the issues that I think is  important is 
the definition of documentation.  My view is that  documentation starts with 
the labels and graphics of the user interface so when  you are testing software 
or hardware interfaces, that is the "first" level of  documentation.  The 
goal here is that the interface is self-documenting as  much as possible.  
Conducting menu testing is, to me, documentation  usability testing, for example.
 
Many years ago, I compiled a list of documentation usability techniques  
including methods like:
 
1.  Read and locate test (give people a question and see how long  it takes 
to find it using any type of documentation or documentation aid).
2.  Usability edit (also called "user edit") where a user reads  through 
procedural documentation and uses the product as described in the  documentation.  
This is the most powerful type of testing for procedural  information, but is 
not well know.  It can be done as a lab study or  designed for 
self-administration. You are looking for the following things in a  usability edit (which is 
not a technical or copy edit):
   a.  Missing information
   b.  Incorrect information
   c.  Unnecessary words
   d.  Correct references to files and sample data
   e.  Confusing information.
3.  Concept testing.  This is a simple method where you ask  someone to read 
conceptual text that is important for users to understand and  then ask them 
to write down, in their words, what their interpretation of the  concept was.  
So, if you were developing something on the "semantic web"  and had important 
concepts like "ontologies" you might see if your conceptual  documentation is 
understand.
4.  Diary studies.  These are studies where people describe their  
interactions with online documentation or performance aids.  I conducted a  study where 
people pushed a big red button to record whether  documentation was useful or 
not and then pushed it again to turn the recorder  off.  Old technology, but 
it worked well (there was a small red light  on when the recorder was working). 
 One of the issues with documentation  testing is that in many venues (though 
not all), documentation use is  sporadic and you need to gather data over a 
period of time.
5.  Documentation surveys.  Surveys get a bad rap in our  field.  Good 
surveys require significant design work and a really  good survey can yield quite 
useful information.
6.  Logging studies that note feature use as well as documentation use  
(including "documentation" like tooltips, help, and other performance aids). 
7.  Documentation inspections (like user interface  inspections, but more 
focused on documentation).
8.  Documentation prototype testing where you create a doc prototype  and ask 
people to use the prototype.
 
I think that I listed about 30 methods, but I don't have the file  right at 
hand now.
 
There are some good case studies of the benefits of documentation  usability 
evaluation in the STC archives and the work of Ginny Redish and  Joanne Hackos.
 
Chauncey  



**************Start the year off right.  Easy ways to stay in shape.     
http://body.aol.com/fitness/winter-exercise?NCID=aolcmp00300000002489
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.stc.org/pipermail/stcusesig_l/attachments/20080110/5fc260f6/attachment.html