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: User-centered design From:"Susan W. Gallagher" <sgallagher -at- EXPERSOFT -dot- COM> Date:Mon, 8 Feb 1999 11:07:24 -0800
At 01:21 PM 2/8/99 -0500, you wrote:
>There's a wonderful book titled "The Design of Everyday Things"...
>I can't tell you the author's
>name...
Donald Norman, creator of Lotus Notes, professor emeritus of
Cognitive Science at UC San Diego, and now, partnered with
Jacob Nielson in a new venture, Nielson Norman Group. http://www.NNgroup.com/
(for info on Jacob Nielson, see www.useit.com )
>At 08:25 AM 2/8/99 -0600, Kristin Zibell wrote:
>>How does a tech writer implement user-centered design techniques into their
>>information development process? What are some chanllenges that tech
>>writers face when doing so? I am asking these questions because
>>"user-centered design" is all I hear about a work, and I am curious how
>>other tech writers use it. Any information would be helpful, thanks.
One of the most basic ways to make your documents user-centered is
to make them task-based rather than interface-based. What that means
is that you don't just look at the interface and document each menu
item in it's turn; you think about how you expect the person behind
the keyboard to use the program and write about each of the tasks
you expect them to perform.
The challenges? First and foremost, looking at the product from the
user's POV -- particularly challenging when you've been in Industry X
for 10 years and know the information inside and out.
Convincing management that you need a better audience analysis than
your part-time mar-com butterfly can provide goes hand in hand with
learning to user's POV -- how can you see a POV when you don't know
who's eyes to use??? ;-)
And once you've got a handle on who the user is and how you think
the software will be used, there's the chore of convincing project
management that it's the right approach to use -- old dog/new trick
time!
