Re: Practical Usability Testing

[Sandra Law <sandra -at- qmaster -dot- com>]

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!

How you test a product depends very much on your background and expertise.  I agree
that you have to sit down and use the product, to get a sense of the various
components, how they fit together and how they do or do not serve your purposes.
During a recent software evaluation exercise, I found that my group members and I,
while arriving at similar conclusions about the product, had very different
feelings about it (i.e. very frustrated with the product to the point of totally
discounting its useful ... in any context, to yes this product has limitations but
can be of use to certain people with these interests and expertise).

It was Project Management software and clearly designed for use by Project Managers
or Sub Project Managers, in a business or industry setting.  The group member who
came to 'loathe' the software conducted a case study analysis of software in terms
of how well it dealt with a recent project she undertook in her school.  This was
an assignment for a course in Project Management in an Instructional Technology
context.

To sum up I think that testers should 'play' with the software, push it to its
limits, but consider their own biases, the learning curve involved, and the target
audience of the software.  We're not all expert users/beta testers who can quickly
gauge the failure or success of software on first or second or even third
encounter. That is, while you can play with CAD, you don't know the the exact needs
of draftspersons, architectural technologists, etc..  Maybe a quick survey of their
opinions or their reviews of the software should be a required part of the software
testing procedure.  Maybe the testers are part of these expert populations.  That
information wasn't provided in the original message.

Sandra Law