Re: This too is technical communication

[Chris Borokowski <athloi -at- yahoo -dot- com>]

This is a good point, because it illustrates that more
than anything else, we are shepherds of the interface
between user and product and its actual use. No one
else can afford to think of this; developers write
code, project managers watch budgets, QA people look
for bugs. We are looking at the big picture.

My comments were not meant to advocate using technical
writers as (for example) copywriters, but to suggest
this kind of involvement. We should not be "I don't do
QA" or "I don't do code reviews" type people, but
should in the process of getting to the
write-the-manual stage, be the kind of people who
enmesh themselves in the development process and
become champions of making the product work right by
the users and their goals.

We are the only people focused on the person-computer
interface... we should not only capitalize on that,
but view it as the responsibility that it is. We can
save people time, frustration, sadness, rage, or we
can just get bitter, WTFM, and go home.

--- Troy Klukewich <tklukewich -at- sbcglobal -dot- net> wrote:

> While STC has a mandate to raise the visibility of
> the technical writing field as a whole, it is up to
> each and every technical writer to understand and
> communicate their own value and documentation
> leadership on the teams that they serve. In my
> experience, defining our own value is a never-ending
> series of contextual discoveries. It's a process,
> not an end point.
>  
> I've seen far too many writers taking unthinking
> direction from misguided developers who do not
> understand or appreciate the technical writing field
> as a discipline. Some developers think it is their
> job to tell us what to do. But most developers don't
> really know what we do. They have their own ideas
> based on little, if any involvement with the
> technical writing field itself. Who can blame them?
> They work with what they have. The end result is
> mediocre documentation and increasingly unhappy
> customers. 
> 
> It's up to us to set boundaries, give guidance,
> share our skillful expertise, and educate, educate,
> educate. Communicating our value in a professional
> way, especially under the duress of deadlines, takes
> courage and confidence. I've found with some gentle
> suggestions here and there, developers quickly
> realize that I know what I'm talking about and can
> do a better job at defining documentation
> deliverables than they can. It's all I do. I should
> be good at it. 


User Interface design blog
http://user-advocacy.blogspot.com/
Code::Design::UI::Consulting
http://www.dionysius.com/


       
____________________________________________________________________________________
Get the free Yahoo! toolbar and rest assured with the added security of spyware protection.
http://new.toolbar.yahoo.com/toolbar/features/norton/index.php
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

Create HTML or Microsoft Word content and convert to Help file formats or 
printed documentation. Features include support for Windows Vista & 2007 
Microsoft Office, team authoring, plus more.
http://www.DocToHelp.com/TechwrlList

Now shipping: Help &amp; Manual 4 with RoboHelp(r) import! New editor,
full Unicode support. Create help files, web-based help and PDF in up
to 106 languages with Help &amp; Manual: http://www.helpandmanual.com

---
You are currently subscribed to TECHWR-L as archive -at- web -dot- techwr-l -dot- com -dot- 

To unsubscribe send a blank email to 
techwr-l-unsubscribe -at- lists -dot- techwr-l -dot- com
or visit http://lists.techwr-l.com/mailman/options/techwr-l/archive%40web.techwr-l.com


To subscribe, send a blank email to techwr-l-join -at- lists -dot- techwr-l -dot- com

Send administrative questions to admin -at- techwr-l -dot- com -dot-  Visit
http://www.techwr-l.com/ for more resources and info.