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.
> Howdy,
>
> This is where I will argue with Andrew. As a technical writer, I believe
> I have a completely unique view point. Engineers are wonderful
> at making something work. Most of the time, they could care less
> why they need to make it work (there are always exceptions).
> As a technical writer, I can watch the pain an engineer goes through
> to make something happen. I can also see the problems a user
> might have. Most engineers appreciate this view point (just as I
> appreciate feedback on my manuals). I am surprised at how many
> times I have said, "how do you think a user would like this?" and
> the engineer looks at me blankly. Most engineers focus on trying to
> solve a problem, not on how people will use the tool.
>
> I think part of this is semantics. It sounds like Andrew does the exact
> same things I do, he is just more subtle. And when it comes to letting
> someone know something is wrong with their baby, tact is ALWAYS
> necessary and subtlety is often required. And if they don't listen,
> they don't listen. Why should I waste my time beating my head against
> a stone wall? The last place I worked I did stamp my foot a bit about
> one problem. They decided not to fix it. Then the tech support calls
> sky-rocketed. Needless to say, the next time they considered my input.
>
> This is one of the main reasons I enjoy tech writing. I am a balance
> of the artistic and the technical. I get to delve into technology while
> also studying people. I grew up in a technical family then went to
> school in the liberal arts. I'm perfect for this type of job. I bring a
> unique point of view to my company. Now, my company can choose
> to take advantage of that or not. I offer it; if they don't want it, I let
> it go.
>
> Melonie R. Holliman
> Technical Writer
> CPD Marketing
> Advanced Micro Devices
>
> -----Original Message-----
> From: Andrew Plato [SMTP:intrepid_es -at- yahoo -dot- com]
>
> This is where the whole "advocate for the user" concept breaks down.
> The
> "user-advocacy" concept assumes that you as a tech writer have some
> unique
> vision into the mind of users. The truth, you have no better vision
> than the
> next guy - engineers included. There are plenty of cases where what
> seems like
> a stupid UI decision actually makes sense once you understand the
> engineer's
> intentions behind the design. Therefore, in a rush to defend the
> tender
> sensibilities of the user, it is easy to forget to ask a simple
> question - "why
> did you do that?"
>
>