The lonliness of the GUI designer

[Michael Alan Dorman]

On Fri, 1 Dec 1995, Joe Schallan wrote:
> >_Then_--once I've invested tons of work in fleshing out the proposal--and
> >only then can I actually get opinions out of people. 
> You say people respond much better to a fully fleshed-out proposal.
> This is a problem?

Sorry, I must not have stated this well. 

As a professional programmer, I have found it very hard to extract
opinions about user interfaces --- even such blanket statements as "I like
this" or "I don't like this" --- from users without going beyond paper and
sketches and prototypes actually creating the program.  Only after I have
invested the time to effectively finish the project in question can I get
feedback. 

Personally, I would love to have had the luxury of working in an
environment that acknowledged the need for iterative design, multiple
prototypes, etc.  I never have --- all too often my projects have shown up
on my doorstep with a "the president of the company wants the department
to have this implemented in a month", or "we promised a client we could do
this type of billing, and we start the contract next month." 

> >Of course, by the time I've been able to coax something worth hearing out
> >of these people (a long arduous process involving you doing everything up
> >to and including constructing sentences for the individual), I no longer 
> >have time to make any changes.
> Shouldn't we _always_ be able to make changes?  My web pages, for
> example, are never finished.  I consider eternal tweaking part of
> continuous improvement.

I will admit to a bias such that I do not consider creating HTML documents
to be "programming", any more than I consider creating my proposals using
LaTeX to be "programming" --- it's markup.  It has little or no relation
to writing payroll software or address book programs or even shell
scripts. 

The comment I was responding to was decrying the state of User Interfaces
and blaming it all on programmers and their poor taste --- I was
responding in that context. 

> End users will always think of ways to use your system that never
> occurred to you.  Or to them, before their moment of discovery . . .

I'm not talking about end users thinking of a new use that needs
modification --- I'm thinking about them ignoring the lack of a field on
an input scree without which it was useless. 

I will admit, though, that you couldn't know that, since you weren't in
the room when it happened to me. 

> They will change their minds.  This is the way humans work.  Do we
> build static systems that can never change?  Do we fit the end user to
> the Procrustean bed?  Or do we try to be adaptable? 

I would not be so foolish as to say people may not change their minds.  I
was discussing the fact that often feedback that I, in my former life as a
professional programmer, have seen many instances where the users give 
inadequate or outright misleading feedback.

As far as building static systems: at some point, you do have to decide on
a feature set and implement _that_ program and worry about upgrades and
such later because otherwise it never gets finished.

> I suspect programmers are given vague, conflicting directions, and it must
> be hell for them.  But somewhere in your organization is someone who 
> does understand both the design side and the end-use side, and all the
> trade-offs involved.  Seek them out.  Ignore the whiners.

Again, I'm not bitching about my current situation which doesn't involve
any truly large-scale programming.  I'm trying to point out that
programmers are not alone in perpetrating the crime of poor user interface
design, as the original message I replied to alleged.

> Have we attracted too many humanities types into the programs?  People 
> weak in mathematical skills?

Careful, your unconscious biases are showing.

Mike.
--
Michael Alan Dorman                                   Head of Systems
mdorman at caldmed.med.miami.edu           Louis Calder Memorial Library
(305) 243-5530                     University of Miami Medical School