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.
Subject:usability testing From:Anne Halsey <Wrdfinesse -at- AOL -dot- COM> Date:Wed, 18 Nov 1998 21:41:00 EST
As promised, here is the summary of responses I received
after my recent query about whether the list believes
"getting feedback from the customer about the
product and its documentation" is usability testing.
George Hayhoe writes:
"It's amazing but true. Most technical communicators are
woefully ignorant of what "usability testing" means.
Anything that smacks of feedback--from beta testers'
comments to tech support questions to reader response
cards--is regarded as a means of testing the usability of
products and their documentation."
"I tend to look at usability testing also as a task that occurs
before the product reaches the customer."
According to Barbara Srour:
"In my experience, it is the companies' belief. I think a lot of companies
believe that no complaints = quality product. This way, they don't incur
the expense of quality control and usability testing. By excluding time
(and therefore, cost) for usability testing / quality control, the company
is able to bid a lower price and shorter time frame for the
project.Regardless of policy, I have ALWAYS tested the product, the
documentation, and then the documentation against the product, sometimes on
"my own time" so I didn't have to justify the expense and time to
management; if my name is going on a document, it will meet MY standards,
which are typically much higher than management.
As a related note, even when it is policy not to test, if there ARE any
problems or mistakes that the client complains about, it usually comes back
to the documentation staff, as management demands to know WHY no one caught
any errors or usability issues. And, of course, the fact that company
policy does not allow for this quality control and testing is never
considered justification by management.
In fairness, though, policy makers and senior management typically have
little software development experience (outside of management), and I have
yet to meet any manager who has experience in tech writing. Therefore, a
large part of this is due to ignorance on their part."
And, finally, Lorin Ledger says:
"Excellent question, Anne. I do not think that "feedback only" is
reliable, and that one must make a concerted effort to test the
usability of a program, on-line help, manuals, or what have you.
However, my manager thinks usability testing is "looks good to me," and
that I should just "go by what everybody else does" when writing on-line
help. So much for winning an STC competition ... "
Oh yes. Plus one rather abrupt request to "cut Mandy some slack because
she's just a student." <g>
Not an overwhelming response, but, perhaps, sadly indicative of