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.
I have had my share of the experiences you mention, which is why I decided to
fight back
rather then knuckle under. I spent 7 years at Microsoft where I, and alot of
other writers and
editors, spent ALOT of time educating program managers and developers about our
role as
interpreters; spent even more time learning all we could about usability,
ergonomics,
interface design, and other things so we would sound like we knew what we were
talking about;
and then get involved in helping design the tools we would use to produce our
online systems.
When I left last year, things were not perfect, and not every group had reached
the same level
of cooperation between user education and development, but things continued to
move in that
direction. Microsoft Publisher was designed by a marketer and a CBT author. Cue
Cards were
invented by a technical writer. The changes you will see in Chicago Help come
from a
cross-fertilization of ideas between the developer writing the Help system and
nearly ALL of
the Help writers at Microsoft. I now earn my living designing user interfaces,
Help systems,
and consulting with small software companies on how to create better products
through building
user-centered product teams. The latter isn't easy work and it will not happen
in every
instance, but I think it is our professional responsibility to keep trying to
move in that
direction wherever we are.
I think you will find the January issue of Technical Communications very
illuminating when the
results of the study on measuring the value of technical communicators is
published. Judy,
Janice and (someone who names I am forgetting) have great ideas for how to build
a business
case for why your role increases the value of your product. And this is great
ammunition when
arguing for increased involvement in the design process.