Re: Educating Rita

[Andrew Plato <intrepid_es -at- YAHOO -dot- COM>]

> I would very much like to get my oar in before the
> development of this interface goes too far, so
> that we don't get some god-awful color scheme like
> last time, or confusing button labels (OK and
> Accept on the same screen)etc.
>
> My question:  What's an effective way to approach
> a touchy, rather defensive SME to offer help in
> designing a GUI?

In my opinion it is not your place to be giving ANY "suggestions" unless they
are requested.

You're a technical writer, not an engineer, correct? Your job is to write
documentation about what engineers design. It is not your job to design the UI.
That is the engineer's job.

Give the engineer what she asks for and let her chart her own course. If she
designs a crappy UI -  so be it. It is arrogant presumption to assume you can
design an interface better than her.  How will she learn if you butt in and
tell her how to do her job?  If you don't allow people to make mistakes they
will never learn anything.

Moreover, you cannot criticize people's work until you earn their respect. You
have to let them screw up first and then, when asked, help them to do better.
Respect is not something that comes easy.  You have to build a rapport with the
engineers.  Then slowly and consistently demonstrate that your perspective has
value.

In my line of work, consulting, butting in on an engineer's work would be a
easy way to get term'ed off a contract. If I was not hired to design a UI, then
I am not going to act like I am. If the client wants to design a bad UI, they
have that right.  Likewise, if an engineer wants to build a crappy program, let
them. Let their incompetence shine, then people will be begging for your help.

I've see plenty writers stick their nose issues where they weren't invited only
to then wonder why the engineers don't respect them.  How would you like it if
an engineer told you how to format a document, what fonts to use, or the
"correct way" to write. You'd be pissed.

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.

Technical writing is information delivery, or as I like to say, "ramming as
much information down the user's throat as painlessly as possibly." Deliver
good information and let the user find his/her own way.

It's like ordering a pizza. You order a pizza, a guy delivers it to your house.
How would you like it if after delivering a pizza, the delivery guy came into
your house and told you the correct way to eat the pizza.  Likewise, how would
you like it if when your ordered a pepperoni pizza, the guy taking the order
said "I'm going to put onions on that for you because you need them."  You
reply "I don't want onions." He demands, "I know what tastes good on a pizza so
I am putting onions on it."  Sounds stupid right?  Well, that's what you're
doing when you play the "user advocate" card. Just give the user what they
ordered.

There is nothing worse than an advocate nobody wants.  Likewise, there is
nothing more irritating than someone assuming a job that does not exist.

Just my thoughts.  I am sure many will disagree.

Andrew Plato
President / Principal Consultant
Anitian Consulting, Inc.
www.anitian.com




_________________________________________________________
Do You Yahoo!?
Get your free @yahoo.com address at http://mail.yahoo.com

 From ??? -at- ??? Sun Jan 00 00:00:00 0000=