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 feel that tech writers advocates for the user as well. My documentation is
produced for users, and its prime raison d'etre is to ensure that the user can
learn the software, and use it in an efficient, effective manner. This task
becomes more complicated if the user interface is *ugly* - therefore I almost
always make suggestions and get involved in helping to design the interface.
Thankfully, I work for a company that not only allows me to do this, but
appreciates it, and recently this task was added to my responsibilities
formally. I also get involved in user testing of new software, and they have
added this responsibility as well.
The benefit of being involved in systems development *outside the box* are:
* closer involvement with the developers - from the first step of system
development
* the ability to analyze user test feedback and objectively decide which
problems are best solved by changing the software, or reworking the
documentation
* less time spent by the department in rewriting software after a user test
Of course, this is all based on my current situation and experience. Other
companies may take a different approach, but overall I have found this to be
the best process for all parties involved.
Suzette Seveny
Markham, Ontario, Canada
sseveny -at- petvalu -dot- com or suzette -at- yesic -dot- com
------------------------------------------------------------------
DISCLAIMER:
Any opinions expressed are MY opinions.
Feel free to have your own.
Let's agree to disagree
But Please - Don't Flame Me.
Curiosity killed the cat, but for a while, I was a suspect.
Someone (forgot who) wrote:
> > Furthermore, this issue beckons the misguided notion that tech
> > writers are
> > "advocates" for the user. I do not feel technical communication
> > has anything
> > to do with being a "advocate" for the user. This is something a
> > lot of tech
> > writers use to distract themselves from their primary task -
> > production of documentation.
>
Then Tracy Boyington wrote:
> You mean the notion is misguided in YOUR opinion. I disagree. If you're
> not producing the documentation for the user, who are you producing it
> for? Why bother? That's like saying the "primary task" is typing, and
> thinking about what you should say simply distracts you from the primary
> task of typing.
>
