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:the role of the tech writer From:helen cygnarowicz <bigh -at- SLIP -dot- NET> Date:Fri, 7 Nov 1997 19:41:37 -0800
wanda jane makes a good point. what little i know is that when she says
What if we told them how to correlate existing processes to the new
product? Where you once pulled this lever after centering the boards,
now you select *alignment* followed by the command *cut*.
i believe she has hit the nail on the head. yes, people feel quite
uncomfortable with change. but when you describe the change
transparently to them as her example shows, it eases them to a more
comfortable spot, and as their ability to see further analogies to what
they already know increases, so does their comfort level. even those of
us who use all sorts of application software feel better once we have
figured out that "MS does this this way but Corel does this that way and
Adobe does it yet a different way but they all do the same thing in the
end so which one do i like best (makes me least uncomfortable)?" i think
this is a matter that comes out in any usability test. how closely does
it relate to what i already know? how well does the tech writer draw me
into that comfort zone? if i'm really comfortable, i think i will find
the tech writing more usable.
there's is one thing that bothers me though. no amount of good writing
can make up for poor software or faulty hardware. so the engineering
developers have a stake in this comfort level too, and as tech writers,
we need to be in on the development as part of the team because we know
our users and how they might feel when there is drastic change for
cleverness rather than change for improved functionality.
thank you wanda for bringing this to my attention. i'll be more aware of
it when i write the next revision of our publication library.
