RE: An Engineer has infected my young mind!

["Giordano, Connie" <Connie -dot- Giordano -at- FMR -dot- COM>]

Eddy, Sierra, and other listers willing to wade through this:

I respectfully disagree on several points.  And in other places, you are
right on the money.

Most users are intelligent non-doofus types who may, but often don't have
experience with windows-based software, much less web software.  My user
base went from mainframe green screens to a windows-based program to a
web-based version in less than three years.  They are extraordinarily
bright, but have trouble understanding overly complex navigation, unfamiliar
terminology, and workflow not based on how they do their particular jobs.

An application that requires a reference manual that the designer/engineer
believes needs to be read cover-to-cover 2-3 times is probably not
well-designed.  Which is why UI design and traditional technical
communications are merging professions.

I have spent almost 8 years in tech writing, more than 16 in writing
professionally.  I have never, ever seen a user return a feedback card.
Which is why I push for tech writers/trainers to go on-site with users and
do one-on-one training and observation.  When you actually see how they use
it, when they cuss at it, and when they say "way cool" then you have viable
information to use in designing improvements to the software and the
documentation.

Some of my best friends are engineering types,  others are marketing types,
and others are customer service types.  Makes for valuable perspective in
designing a documentation set that works for a product that works for
audiences that actually like to use it.

Who creates whose job--without information designers, UI experts,
customer-service feedback and a whole plethora of other communicator-type
jobs, engineers wouldn't have anything to design.  Chicken-and-the-egg, or
vicious circle, however you look at it, we need each other.  I respect the
engineers who take the time to figure out why it should do what they want it
to do, and don't patronize me because I don't write code for a living. I
contribute to their process, they contribute to mine, and we all end up with
good products that give us satisfaction to produce. There are some truly
wonderful engineers out there, and just as many devils incarnate.  

It may be easier to let go of the writers before the engineers (and
unfortunately usually true), but every company I worked for that did that
ended up going bankrupt--says something about how integral communications is
to a company's success.

MTC
Connie Giordano
Senior Technical Writer
Advisor Technology Services
704-330-2069
e-mail:  Connie -dot- Giordano -at- fmr -dot- com

"Try not to have a good time...this is supposed to be educational. " -
Charles Schulz



[SNIP]
Not everyone that uses an application is a doofus who inherited a 
P-III when his nerd uncle died from a disk crash. Most of today's users are
pretty informed, and know what they're buying and why. 

[More snipping]
I would believe that the engineer has spent a lot more time on the project
than you have. If the application is well-designed, that means, the user has
been profiled well and the application synergizes with their regular
procedure and work flow. The first release of a software application is
usually aimed at a market that will gobble up the product. You may be
surprised to learn that many of these users need a whole lot less explaining
than YOU did. 

A reference manual is usually what accompanies a first release. Further
tutorials and user guides should be based on feedback 
via an informative feedback form that goes with the reference 
manual. 
[even more snipping]

The engineer is not your enemy. He is the one that creates a job 
for you. Respect his opinion, ask him for reasons, evaluate them 
and then give good reasons for not accepting them. If he has an attitude
problem, you are not going to make work easier by wearing one of your own.
And remember, no matter how good your boss thinks you are, it is easier to
let go of a writer than an engineer.