TechWhirl (TECHWR-L) is a resource for technical writing and technical communications professionals of all experience levels and in all industries to share their experiences and acquire information.
For two decades, technical communicators have turned to TechWhirl to ask and answer questions about the always-changing world of technical communications, such as tools, skills, career paths, methodologies, and emerging industries. The TechWhirl Archives and magazine, created for, by and about technical writers, offer a wealth of knowledge to everyone with an interest in any aspect of technical communications.
Andrew Plato wrote:
>
> "Amy Janczy" <Amy_Janczy -at- uclid -dot- com> wrote in message...
> >
> > I've been asked to perform usability testing for the documentation for our
> > main product,
> >
> > I'm at at loss for how to start....Can anyone provide me with any practical
> > tips for how to do a "quick and dirty" usability test that can help point
> > out key problems with the documentation?
>
> Have you considered just sitting down and actually using the product? I mean, I
> realize you may not be a CAD monkey, but shouldn't you try to become one, at
> least to understand the tool you document.
>
> No book or theory or mindless tips from me will replace hands-on experience. If
> you want to do some REAL usability testing - USE THE PRODUCT!
>
True, but in order to really use the product, one must understand what
it is used and what it is supposed to do. There must also be at least a
modicum of understanding. Indeed all too often instructions and help
files are written without any understanding of what the function is
supposed to do. Let's take a simple cut and paste. Every word processing
help file tells how to cut and paste. How many have the same function
indexed under "move text."
I know of many who have wasted a lot of time because of that simple
deficit.
--
Peter
Arguing with an engineer is like mud wrestling with a pig.
You soon realize they both enjoy it.
