1. HUMAN CENTERED DESIGN

1.1 User Interface Clones

Despite increased attention to software user interface design in recent years, it rarely goes beyond mimicry.

At first every "user friendly" system attempted to be a lawsuit-proof Mac clone, itself a derivative of Xerox PARC's STAR System. Procedures like dragging a file name across the screen to an iconic trash can soon became the standard, though arguably not the best (much less the only) way to remove a file. Some have replaced it with a black hole, presumably appealing to "power users", and we can easily imagine recycling bins for the environmentally conscious, but the basic concept is the same. Wisely (but just barely), the industry avoided a debilitating intellectual property rights battle over the concept of electronic trash and its disposal.

All too often user interface design simply means providing "windows" (which are more akin to stacks of paper) and "GUIs" that relegate all computer interaction (save actually typing text) to point-and-click operations. Interface design often simply means complying to the "look and feel" guidelines of the host operating system, which are themselves all the same except for minor differences among widgets like buttons and scroll bars. Companies employ visual designers to create clever icons, fine tune the graphical layout and spec typography, but essentially one size fits all.

The copycat and faddish character of interface design is arguably becoming counter-productive. As icons proliferate, many are as cryptic and obscure for visual memory as the alphanumerics they were meant to replace. Consequently, we must often rely on an associated text label to derive an icon's meaning, and the icon itself is reduced to little more than a target for the mouse cursor, not a medium for information.

Groping for a workable conceptual model, the software industry has been a-buzz with the latest fad concept, for example that of "metaphors", a useful but obvious and simplistic idea, but hardly a complete design paradigm. Certainly it is important to leverage off the existing skills of the user community. But while they may be appropriate for the extremely inexperienced user, isometric drawings of an office desk complete with notepad, clock, desk calendar, file cabinet, and the mandatory trash can seem somehow archaic for a technology that is supposed to be "enabling". What metaphors exist for downloading a graphic image to your car's cellular phone-cum-fax machine, or turning email text into sound and forwarding it to somebody's voicemail?

1.2 Interface Standards

Afraid of being left out or left behind, many companies clamor for interface design standards just as they do for engineering standards. Whether for Mac OS, MS Windows or UNIX Motif, the assumption seems to be that the art has been reduced to a science. While consortium efforts like COSE/CDE may offer mechanical benefits in cross-platform engineering and an apparent tour de force against a common competitor, standardizing on primitive interfaces is a way to institutionalize the mediocre - to everyone's disadvantage. Any company that cannot or will not go beyond copying everyone who is copying everyone else is guaranteeing its products won't be any better than those of its competitors. The auto industry standardized on nuts and bolts, not the look and feel of the Model T.

1.3 Usability and Productivity

People use software in ways that are familiar but absurdly inefficient. No surprise to most software engineers, this is even true for non-technical people working for the companies that produce it.

Consider the seemingly simple task of writing and printing an ASCII file. People typically use fancy word processing applications, suffering the slow performance of unnecessary overhead, only to save to "text file" before they pull down a menu to print. Others will use a mail system to compose the document, mail it to self, then drag and drop the mail message on the printer icon. Infatuation with the mouse has led to bizarre and counter-intuitive canons: the typical word processing package requires mouse movements for all operations except entering text itself, a sort of writing by drawing. Old fashioned text editors at least keep your fingers on the keyboard, but they are only used by "techies" because the editing key-stroke sequences are baroque and poorly documented.

Other examples abound for every major operating system and application. To illustrate, we will pick on two of the most popular. As late as 1995 configuring a modem on UNIX (the system invented by The Phone Company) requires manually editing at least two obscure text files and considerable esoteric knowledge to get it to communicate at speeds faster than 2400 baud. And it was standard operating procedure on MS DOS (the system then running on 75% of the world's PCs) to constantly diddle startup files so that applications could run in the 640K of "conventional memory", even if you had 32 MB or more to spare. The producers plead backward compatibility, but are we being productive yet?

Tempted as some are to blame the user instead of the system design, or at best responding with wrappers that treat users as morons, these inefficient behaviors are not the result of user stupidity. They are a function of learning a way to get from "a" to "b" in spite of being intimidated by ominously thick manuals, being flummoxed by obscure command-line syntaxes and meaningless icons, and being burnt by mysterious error messages that read as so much technobabble. Faced by the alternatives of expensive "support" contracts, long distance phone calls, thick manuals of technical jargon, and lost time in the face of production deadlines, most users default to coping with what they have learned to work, inefficient as it may be.

As software interface experts like Bill Buxton and Bruce Tognazzini point out, the problem here is not simply ease of use - it's productivity. Users will employ the best way they know to accomplish a task, but the performance of the user-system ensemble is often far from expert. While the producers of these systems claim to have "enterprise solutions", most have yet to fully realize that the system is the interface. No amount of visual interface styling or homey metaphors is going to fix a system that is fundamentally broken.

1.4 Customer Feedback and User Requirements

For all its rhetoric, the industry's supposed "customer focus" in the design of software systems and products is basically a sham. The truth is that almost nobody really listens to the user community. There is a lot of schmoozing of CEOs and CIOs (the guys with the money), and engineers like to talk shop with other engineers, but hard information with heuristic value regarding user requirements is scarce.

Software companies typically have no ongoing market research program that provides a steady stream of customer feedback or insight about changing trends. Product requirement documents from marketing are often too vague or too obvious to be of any real help to engineering, and trip reports from customer site visits often say nothing more than, "They like us." Too often customer research efforts like Focus Groups ask the wrong questions, subtly biasing answers a priori to suggest safe, boring, and ultimately inconsequential line extensions of the status quo. Cutting edge software companies are establishing usability labs, but these often concentrate on finding glitches in current products (and sometimes in new prototypes), rather than observing real users in real work situations to ferret out breakthrough solutions.

There is more to the total systems interface than the look and feel of a GUI clone; there is more to human factors than visual perception and mouse-motion ergonomics. What about the psychological needs of security and privacy, for example? What about the social human factors involved in fostering effective teamwork? For that matter, what about other sensory modalities like sound, touch and the kinesthetics of space?

We sometimes forget that there are more users than the "end user". Considered throughout its life cycle and in all its modes of existence, there are others who must deal with "the system". What about the sales person demoing it? What about the CS personnel supporting it? What about the distributor upgrading it? What about the OEM bundling it? A well-designed software product would respond to the requirements of all of these "users".

To be fair, quality improvement programs, recommendations from marketing and sales personnel, analysis of bug reports and RFEs, and the findings of usability labs and human factors analysts often yield bits of design insight. Even so, there is typically no formal or standard process to get the user requirements into the software development process, either at the level of steering committees or of routine engineering. Indeed, formal software engineering procedures typically begin with steps for implementing ideas but say virtually nothing about basing those ideas on hard customer or user data.

1.5 Extended User Requirements

The software industry can and must do much better. The survivors will separate from the crowd by expanding the definition of "the users" and their "human factors" and by employing design research methods aimed at discovering what really makes them tick. This requires a software design process that starts with insights about user requirements, correlates them with other design considerations, then proceeds to develop creative and effective design solutions.