writing around desgin flaws

[Gwen Barnes <gwen -dot- barnes -at- MUSTANG -dot- COM>]

-> not talking about a few bugs in a program.  I'm interested in how people
-> write around serious flaws for which there is no logical explanation.  And,
-> for the sake of discussion, let's assume that there is no way to get rid of
-> these design flaws.

That's a last resort. I bring my concerns about user interface to the
engineers (well prepared with alternatives and suggestions), and discuss
with them the implications of a bad design as opposed to a good design.
I don't always turn out to be right, but I do get a better understanding
of the product whether or not my input is useful, and everybody wins. I
use any chance I can get to test and ponder each screen and procedure,
and I'm both frank and constructive about how to change things that
don't seem right. My position is somewhat unusual, I gather, but I
wouldn't have it any other way.

A bad design means people will fail to understand how to use the
product, and most of them will call tech support rather than picking up
the manual. If tech support is not a profit center for the company, the
more tech support calls a product produces, the less profitable the
product will be.

A good design is a LOT less trouble to document. If it's consistent
throughout, it requires less explanation for each instance of a
particular type of command. If things are arranged thoughtfully on a
screen, in order of importance or grouped by category, it reduces input
errors because users can make the right assumption on a new screen about
where the important stuff is located. People like to use the product,
they think we're great people, and they keep coming back for more.

Cheers,                                                 @DISCLAIMER@
Gwen                                         gwen -dot- barnes -at- mustang -dot- com
http://www.mustang.com                         ftp://ftp.mustang.com
MSI * Connecting the world                              805-873-2500