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:Chuck Martin <cwmartin -at- US -dot- ORACLE -dot- COM> Date:Tue, 10 Nov 1998 11:58:00 -0800
Barb Ostapina 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?
By making the connection that the interface itself is documentation,
quite possibly the only documentation that the user will get.
That almost sounds simplistic. What about online Help? Tooltips?
Wizards? And so on.
The interface, whether is be of software, machinery, or day-to-day
objects, communicates with users. That communication can help a user
grok the object's use. Or it can hinder, often by hiding what a user
needs to know. In software, the placement, look and feel, and labelling
of interface items communicates something to users. Whether or not each
individual peice, as well as how they are all structured, communicates
to the user will be borne out by usability testing.
One of the absolutely best books I ever read on how design communicates
to users is "The Design of Everyday Things," by Donald Norman. (ISBN:
0-385-26774-6)
You take what you learn in usability clases and you use it to integrate
yourself better into the development team. No longer just a writer, you
begin to identify areas in the software interface that do not
communicate clearly. Then, as time goes on, you get involved earlier in
the development cycle, before coding actually begins. The result, if
management and programmers are open to your ideas, is better designed
software, and that design was put together solidified early on, rather
than hacked together in peices.
--
Chuck Martin
Principal Technical Writer, Oracle Developer
Tools Division, Oracle Corporation
