RE: This too is technical communication

["Lauren" <lt34 -at- csus -dot- edu>]

Gene,

What you are saying here about a technical writer's knowledge is in contrast
to many of the contracts that I have completed.  My clients tend to tell me
something to the effect that they have a unique product, system, or process
and that the users vary in skill level.  I can say that I know the type of
situation that they describe, but I cannot say that I know their exact
situation.  I can describe how I have tackled situations like this and I
usually need to describe my information gathering skills.  I can see how
using a term like, "clueless idiot" can have the wrong connotation in an
interview, but it doesn't seem bad as personal state of mind when
approaching project.  

I have only been on one technical writing team and the entire environment is
different from what I know.  I imagine that a manager would have
reservations about seemingly self-deprecating comments made by employees.
Negative personal comments can reflect on the entire team.

Knowing a user still requires some process to get from not knowing to
learning and then to knowing.  Technical writers are not born "knowing."
How could it be possible that an interviewee would "know" the new situation?
What is that person's learning process?  I would be concerned with somebody
that came in saying they know everything when they are new.  Wouldn't that
attitude present the risk that the person may assume too much?

Lauren
 

> -----Original Message-----
> From: techwr-l-bounces+lt34=csus -dot- edu -at- lists -dot- techwr-l -dot- com 
> [mailto:techwr-l-bounces+lt34=csus -dot- edu -at- lists -dot- techwr-l -dot- com] On 
> Behalf Of Gene Kim-Eng
> Sent: Wednesday, June 06, 2007 11:02 AM
> To: techwr-l -at- lists -dot- techwr-l -dot- com
> Subject: Re: This too is technical communication
> 
> I would be very unhappy with any writer working for me who
> described his or her role or the job description of a technical 
> writer in this manner.  The role of a writer is never to "not know"
> something, and any suggestion that it is, even on a "let's pretend"
> basis, is a bad idea because inevitably somebody will forget the
> part about pretending.  The role of the writer is to *know:*
> 
> To know about the product and its underlying technology
> To know about the user
> To know what the user is likely to know and to not know
> To know what the user will need to know
> 
> It is far more productive to present yourself as someone who
> knows these things than as someone who doesn't know 
> something, either for real or pretend.  Of course, you need to
> make sure you really *do* know them.
> 
> Gene Kim-Eng
> 
> 

^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

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

True single source, conditional content, PDF export, modular help.
Help & Manual is the most powerful authoring tool for technical
documentation. Boost your productivity! 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.