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:Re: Usability Testing From:Kris Olberg <kjolberg -at- IX -dot- NETCOM -dot- COM> Date:Tue, 23 Jun 1998 22:08:46 -0500
-----Original Message-----
From: Rowena Hart <rhart -at- INTRINSYC -dot- COM>
To: TECHWR-L -at- LISTSERV -dot- OKSTATE -dot- EDU <TECHWR-L -at- LISTSERV -dot- OKSTATE -dot- EDU>
Date: Tuesday, June 23, 1998 10:57 AM
Subject: Usability Testing
>As Carol and George Hayhoe pointed out, technical writers
>are not qualified to perform usability testing. I would love to
>hire someone to do it but, as it stands, we don't have the cash
>or the time to bring in professionals. That means the task
>will be given to the person who needs the data most -- me.
You can't afford NOT to hire usability testing professionals. It has been
shown time and again that companies that employ sound usability testing
practices produce more usable products. Per Jared Spool, you can spend the
money up front and build solid affordances into the product, or you can
spend A LOT more money later paying for expensive support techniques--call
centers, training, and documentation.
>I'm still in the early stages of researching usability tests, but I'm
>a bit curious that the idea of carrying out usability testing in
>the beta release stage of a software product's life cycle has
>been soundly rejected. Why? Isn't usability part and parcel
>of identifying "whether there are any operational problems that
>haven't surfaced in the limited testing that is built into most
>development processes," as George writes?
The beta stage is too late to usability test a product. Information obtained
from such tests will, at best, be used for the next release. However, new
releases often introduce new features/concepts that bring new, untested
features into play and make previous usability testing results irrelevant.
This means you're always one behind. Besides, as George Hayhoe points out,
beta testing should be a focused event.
>however. Usually the documentation is in pretty rough shape
>at the beta stage, a result of crazy production deadlines and
>rampant "we don't have time for documentation right now"
>attitudes among engineers and programmers.
I'm a programmer. During a development project, I don't have time to
contribute to documentation. Why? Not because an attitude I have but because
of an expectation by my managers that I will meet a schedule. If I spend ten
percent of my time working on documentation, that's about one hour a day I
DON'T devote to programming. Imagine what might happen to you if you spent
one hour a day helping someone else. If you want to change this, you're
going to have to work on the management to allocate programming resources to
the documentation.
Regards...Kris
-----------------------------
kolberg -at- actamed -dot- com
kris -at- olberg -dot- com
