Re: User Interface Design

["Wing, Michael J" <mjwing -at- INGR -dot- COM>]

>The thing that has me concerned most these days is what I consider to
>be a very poor user interface design. It irks me that we tech writers
>were not
>consulted on the design in the first place, and now we have what used
>to be a
>prototype that just evolved into the final product. And it's
>embarrassingly,
>frustratingly inadequate.

>I wonder how many of you software documenters are consulted in the user
>interface design process. Do you have a lot of input? Do you have any
>guidelines for what constitutes a good UI design?

>Karen

I've always found that a Technical Writer's input into UI is earned.
Technical Writers are often neglected on the interface design because
much of the industry regards technical writing as a "soft" skill.  If
you are not a programmer, UI specialist, Physicist, Mathematician,
Engineer, or possess other "hard" skills, it is difficult to have a say
on design aspects without proving yourself.

(I am referring to the terms of "soft" and "hard" skills as how industry
thinks of them in relation to researching and developing a product, and
not in terms of how hard or easy it was to obtain a degree and expertise
in a discipline.)

However, as a Writer shows a good aptitude in using and understanding
the product, their feedback to Development can become appreciated
(uninflatable egos and existing animosity not withstanding).  Often, and
frustratingly so, response to their initial feedback is, "Where were you
when we were designing this?".  Thus, a catch 22.  Despite the catch 22,
the next project or next go-around of the current project may find the
Technical Writer's input more highly valued.  After all, the Programmer
concentrates on getting the thing to work (no sense in choosing the
color of the paint if the engine won't turn).  Getting useful input on
the UI (the paint) may assist the Programmer in their design.  Learning
about interface standards, requirements, and so forth doesn't hurt
either.

To me, the approach and attitude that the Writer takes to expanding
their borders and other's perceptions of the Writer's abilities makes a
difference.  If the approach and attitude is adversarial ("I demand that
the Writer be part of the design.", "I'm sick of being treated as an
inferior and am not going to take it", "I'm a Writer and nothing else",
"I'm going to show these <fill in favorite developer stereotype> how to
make a useful interface") whether vocalized or tacitly implied, is a
recipe for failure.  However, if the Writer works their way into the
fabric of the design team with the approach and attitude that they
understand what the Developer is trying to achieve, what compromises
they have to make to get it to work, and the constraints under which
they work, the Developer may then appreciate someone who sees the
product with the hood down.  IMO, this relationship takes time, but it
does work.

Mike


_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/
_/
_/   Michael Wing
_/   Principal Technical Writer
_/   Infrastructure Technical Information Development
_/   Intergraph Corporation
_/   Huntsville, Alabama
_/   (205) 730-7250
_/   mjwing -at- ingr -dot- com
_/

                  TECHWR-L List Information
To send a message about technical communication to 2500+ list readers,
E-mail to TECHWR-L -at- LISTSERV -dot- OKSTATE -dot- EDU -dot-  Send administrative commands
         ALL other questions or problems concerning the list
       should go to the listowner, Eric Ray, at ejray -at- ionet -dot- net -dot-