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 and Tech Writing From:Mark Magennis <markmagennis -at- YAHOO -dot- COM> Date:Wed, 11 Nov 1998 02:02:46 -0800
---Barb Ostapina <Barb -dot- Ostapina -at- EXPERIAN -dot- COM> wrote:
>
> I see and hear a lot about the value of software usability -- having
it,
> testing for it, and so on. And I'm not disputing its value in the
least.
> But, I have trouble bringing it to a practical level in *my* work as a
> technical communicator. How do you (Marni and anyone else) *apply*
what
> you learn in a usability training session to your day-to-day technical
> communication tasks?
I have never taken a usability course though I do have an academic
background in Human Computer Interaction. I have recently read Jeffrey
Rubin's book "Handbook of Usability Testing". I would heartily
recommend this to anyone wanting to try out some usability testing but
not knowing where to start. It's published by Wiley, ISBN 0-471-59403-2.
After reading some of this book I planned and carried out a usability
test of our new company documentation standard (a set of Word
templates, instructions for use, and a written style guide). The test,
though small, was tremendously successful, resulting in significant
improvements to the templates and the guide. I was able to discover
major problems users had understanding the guide and using the
templates which, in some cases, effectively prevented them from
producing any kind of documentation at all.
Here's a simple example:
The original documentation template included 3 sections.
1. The title page
2. A table of contents
3. The body of the document
1 and 2 were automatically generated. Users only had to fill in the
body of the document. To "help" them, a prompt was included at the
start of the body section - "First heading - start writing here". The
accompanying instructions were to "Begin by going to the bottom of the
document and typing the first section heading in place of the text
'First heading - start writing here'". However, due to the table of
contents being automatically generated, the first contents entry was
also "First heading - start writing here". During the usability test,
I observed one participant typing the entire document into the table
of contents section, a "mistake" she was unable to recover from.
Other similar unforseen problems were noted, resulting in 63
recommended changes to the templates, instructions, and style guide.
The new design bore very little resemblance to the original and it has
been a grat success. It is now usable.
An unexpected spinoff is that the practice of usability testing may
well now be applied to other areas of our business, such as developing
the software. I will certainly be using it again in the development of
online help.
My advice to anyone would be to try it and see. Start with a small
test, say a set of instructions for performing a task. It's amazing
what problems real people will have using what may look perfectly
staightforward to you and me.
Mark
_________________________________________________________
DO YOU YAHOO!?
Get your free @yahoo.com address at http://mail.yahoo.com