Authors Rubinstein and Hersh recognize this problem (they cite this comment in their introduction) and they seek to overcome it in two ways: by carefully articulating a very practical philosophy of human factors design and by providing a set of nearly 100 guidelines for designers to follow. Now books and papers proposing various guidelines abound, but it is the consistent philosophy of human factors, not as an arcane discipline but as an integral part of systems engineering, that distinguishes this book from the others.

In the very beginning the authors note that "in a sense, good human factors engineering is just good engineering. It is based on a thorough analysis of the problem, broadly conceived." Bravo! Just as we humans are part of the problem, so, too, should we be part of its solution. It is pure folly (and a continuing manifestation of engineering arrogance) to define the users out of a system. How many times have we all heard, "It's not a system failure, it's a user error"? Now we're beginning to realize they're the same thing.

Rubinstein and Hersh know the limitations of guidelines: they "cannot be easily generalized," "taken out of context they may be misleading," and "knowing when and where to apply [them) is a skill [learned] by experience rather than by formal instruction." Nevertheless the authors do suggest some specific rules that they recommend be tempered by the designer's intuition (deriving from his "skill, taste, experience, and knowledge") and by the use of "causal models or theories of user behavior" that may be unique to the particular system being developed.

The book covers task analysis and use models, interface language style, information presentation and representation, and system testing. Within each area, the guidelines range from detailed ("avoid error codes") to broad ("don't distract"). Ironically, in this book devoted to user friendliness, I found it somewhat unfriendly that although the guidelines are numbered and set apart from the rest of the text with horizontal lines and italicized type, they are never summarized anywhere as a straightforward list of do's and don'ts. Perhaps the authors felt that if the guidelines were read completely out of context they would be misapplied, but it will undoubtedly disappoint those methodical designers and developers who, whether for inspiration or decoration, like to post lists of good ideas around their desks. In their "Parting Thoughts," the authors do summarize their guidelines in 10 fundamental ideas, and these are quite valuable, for they express the authors' philosophy in ways that clearly lead to action.

An important point that recurs throughout the book is "designers make myths; users make conceptual models." Expressed so compactly this may appear abstruse, but the idea is fundamental to good interface design.

Users rarely know exactly what goes on in the bowels of the system. From the users' point of view, the system responds to something they do. Whenever such a cause and effect relationship appears to exist, most people naturally begin to develop explanations for the computer's behavior. They may be logical ("The system is programmed to create a new record for this product if one does not already exist") or they may be illogical ("If the system thinks it knows you it won't ask you for your password"). Regardless of how well the users' ideas about how a system functions approximate its actual functioning, the point is that users develop "conceptual models" to feel satisfied that they know what's going on.

In view of this, Rubinstein and Hersh contend that designers must not only design systems that make it easy for users to come up with useful conceptual models, but must actually anticipate and shape what those models will be. This is important since "conceptual models ... provide the basis for expectations." The authors go on to note that "if users can easily build consistent models of the computer, they will perceive the system as easy to learn. If they must build complex models, they will perceive the systems as difficult and confusing."

The key to properly influencing the users' conceptual models is to present and maintain a "consistent myth" of how the system functions. It's not especially important that the users' models be accurate; it is much more important that they be clear, consistent, and effective in helping the users know how the system will behave in all circumstances.

Another central theme in this book is that good designs are "user centered." In the introduction, the reader is admonished to "know thy user, for he is not thyself," and the authors dedicate themselves to describing what you should know about users, how to acquire this knowledge, and what to do with it. To those ends the authors describe the principles of task analysis (what is being done, what needs to be done, and how) and use models (given a specific system implementation, how and by whom will it be used). And they illustrate these methodologies by applying them (and their other points throughout the book) to a single case study - designing an automated teller machine (ATM) for a fictitious bank in New York City.

Exactly 200 years ago the Scottish poet Robert Burns commented that the best laid plans of mice and men often go astray, and today's computer systems are no exception. Since errors are a fact of life, we must design systems to run in "error mode." Rubinstein and Hersh are well aware of this and spend some time discussing how, when, and where to report on error situations. Some of their recommendations seem painfully obvious ("distinguish between success and failure"), but when I reflect on the sad state of the many system interfaces with which I'm familiar, I realize one man's obvious is another's obscure. Most important, the authors advise designers to "design the error behavior of the system" and "state errors in terms of the external myth" they are presenting. These thoughts and the attitudes they foster are invaluable if you plan to do more than stamp your brochures, "New! User Friendly!"

While the authors have done an admirable job of identifying and illustrating some of the central issues in good human factors design, I was disappointed not to see any discussion of two points that frequently come up in practice.

First, to what extent should new systems emulate and simply accelerate the work methods now in use, as opposed to offering radically new ways of addressing the same problems? The use models the authors propose approach this issue but do not tackle it head on. In most cases it may be more effective to design new systems to "go with the flow" of established user procedures. However, where these procedures are not amenable to an automated implementation (as is often the case in time-triggered sequences of events) or where the basic task objectives can be far more easily accomplished through new work methods, these should be seriously investigated. Users, like the rest of us, are creatures of habit and tend to accept the familiar more readily than the new, but designers should be cautioned against approaches that simply automate the status quo.

A second point that the authors skirt concerns the industry-wide problem of multiple "good" interfaces. When designers are involved in delivering more than one system to the same users or to overlapping communities of users, how should several good, but different, interface methods be integrated or reconciled so that the users are not confused? I have often found it more difficult to keep straight the external myths of several well-designed systems that I use regularly than to deal with one less friendly but more comprehensive system that offers all the applications I need.

Unfortunately, individual designers and even design teams often find it difficult to solve this problem since users frequently combine packages from several different suppliers to support their various requirements. In this respect the industry as a whole must look seriously for some interface standards not based simply on physiological factors such as the width of the average male fingertip, but on the much more important (and more difficult to measure) psychological and emotional criteria that govern how we perceive and process information.

For the individual designer, this multiplicity of systems in the user's environment remains a critical problem that cannot be ignored. Designers who are responsible for several related systems must seriously consider the collective interface presented by the entire constellation of programs and they must be prepared to compromise some desirable local features in order to achieve a global harmony.

Rubinstein and Hersh conclude their book with a short but valuable appendix in which they outline an approach to teaching human factors design. Given the wide range of good solutions that might be proposed for many interface design problems, the authors advocate an unorthodox class structure in which the instructor is not the grader. This, they feel, will promote a more collegial atmosphere of mutual learning between the instructor and the students, increasing creativity and minimizing the intellectual regurgitation of formula solutions that is so often a consequence of the scramble for grades. They suggest a series of student exercises that are imaginative and challenging and that should effectively reinforce the book's main themes.

All in all, The Human Factor provides us with a valuable review of enlightened guidelines for designing better, not just friendlier, systems. Rubinstein and Hersh have confined their remarks to that which today is practical and, in most cases, cost effective and I have no doubt that their recommendations, if heeded, will make life a little easier for all of us, designers and users alike.

- D. Verne Morland