🚀 go-pugleaf

>The notion that it is "human factors" that are needed to make programs
>"user-friendly" is a dangerous fallacy perpetrated by human factors "experts"
>in the interests of job security.
>
>What is really needed is more understanding of the problems
>the computer is being used to model, understanding that only the eventual
>users of a system (the people with the problem, remember them?) have.  I was
>graphically reminded of this when I consulted on a project which the 
>software engineers had nearly complexified into extinction.  We went to
>the application engineers, the ones who knew about the problem the system
>was trying to solve, and had them design the interface.  The software
>engineers had to implement the system, though, and nearly ruined it again.
>
>Put me down for one vote against "human factors" and one vote for "user
>factors".

I see you complain of "Human Factors 'experts'" and then give a perfect example
of their necessity! If you read your own "what is needed..." statement again,
you will realize that you have perfectly defined the job done by GOOD human
factors people. The point of human factors research is to keep in mind the
ultimate user. In the case of your example, the people who did the engineering
lost sight of this because they were too close, so the application engineers
served the function of human factors people.

Remember, most engineers feel somewhat threatened by human factors people,
because they raise the specter of "control" being taken elsewhere. Also, it
seems that EVERYBODY considers himself a God-given expert on human factors
for his own project.

Yes, I'm grinding my own axe here. No, I am an engineer, not human factors
person. Yes, I've watched a lot of engineers screw it up because of ego or
whatever preventing them from accepting someone else's expertise. Consider
carefully, what are your REAL qualifications for determining how your users
do their work, or how they should do their work? It is tough to answer this
question honestly, but it is definitely an issue of engineering ethics and
professionalism.

-- 
-Brian Diehm     (SDA - Standard Disclaimers Apply)
Tektronix, Inc.
briand@tekig4.TEK.COM   or  {decvax,cae780,uw-beaver}!tektronix!tekig4!briand