“Black-on-black” is a metaphor I use to cover a variety of befuddling design shortcomings at the interface between otherwise sophisticated equipment and the user.

It derives from the proliferation of entertainment products that feature black knobs and pushbuttons and black cabinetry or housings. Who thought this up? Minuscule icons or alphanumeric callouts silk-screened or otherwise imprinted on or near the controls in dishwater gray do little to help. In a dimly lit room one needs a jeweler’s loupe to distinguish one button from another.

I sometimes suspect, perhaps unjustly, that the sleek but user-unfriendly consumer products are designed by artists hoping to win some prestigious design award. Where are the engineers who designed the sophisticated stuff that’s inside? Have they no input? And who represents the customer?

The solution does not end with the visibility of controls. Their physical layout enters in: they are seldom standardized in location or sequence. Do you have a new digital watch with the usual options for time, alarm and resetting? If you think the mini-buttons are in the same place as those on the watch you just discarded, forget it. Misplace the tiny roadmap that accompanied the watch, and you’ll have to hack out the programming sequence. It should take no longer than five minutes. Why do the watch designers do this? Is it not invented here, or do they really think their sequence and button location is better than everyone else’s?

From knobs and buttons we can segue easily to the topic of computers. Everything that software designers and programmers do may be based on machine logic, but to many computer users, logic seems to end at the mouse and the keyboard. This is not a good thing, say the critics, who include the application designers themselves. With computers we find ourselves in the realm of operating requirements and sequences that are arbitrary and require memorizing. And each application is generally a new learning experience. What must be learned by rote is easily forgotten and thus needs frequent refreshing. When something goes awry, troubleshooting is not a logical process. Get a troubleshooter on the phone and his most useful phrase seems to be, “Now let’s try this…” Average citizens aren’t the only ones found in the Barnes & Noble computer manual aisle. I think I’ve spotted a well-known computer professional in dark glasses surreptitiously searching for a guide called computer something-or-another for dummies.

Is it too late?

Perhaps we are too far into the computer age to stem the proliferation of complex, arbitrary procedures, cryptic nomenclature and rampant acronyms. The younger computer-using generation may accept it as the norm — a fair price for the computer’s enormous capabilities.

The human factors engineer is charged with simplifying the interface between machine and user, but sometimes, perhaps, enters the fray too late to do much to aid a given design project. Concurrent engineering, too, may leave little time to evaluate and improve the human-machine interface of a system before it is deployed.

Donald Norman, a professor of computer science at Northwestern University, may have identified part of the problem. He speculates that in the design process, the design engineers may become so conversant with the idiosyncrasies of their own designs or their unusual operating requirements that they do not appear at all troublesome.

Those who believe the user warrants more consideration offer some suggestions:

• Involving customers and potential users early in the design process

• Engaging human factors specialists at an earlier stage in systems design

• Seeking operating sequences in which an action, its effect and confirmation of the expected consequence are obvious to the operator

Human factors specialists tend to concentrate on health and safety issues, as well they should. But this emphasis may downgrade the concern for annoying and inefficient operating requirements, although the two may in fact be linked. In some cases, you can’t have one without the other. Consider the controls of a modern airliner, the air traffic control system, or a nuclear power plant control room.

At the university level, human factors studies seem generally to be part of the industrial engineering discipline, so it is questionable whether students specializing in this area find themselves on teams made up principally of electrical and computer engineering students. It might be a good idea. Another way to foster an appreciation of user-centered system design would be to assign one student to play the role of a demanding customer in a design project exercise.

In any event, there is an upside to the downside of human-machine interface foibles. There’s so much room for improvement that progress ought to be expected, and in many cases, easily accomplished.

Perhaps we should begin with those black-on-black buttons.

For more about human factors engineering and user-centered design, see:

• Norman, D.A., The Design of Everyday Things, Basic Books, 2002.

• Chapanis, A., The Chapanis Chronicles: 50 Years of Human Factors Research, Education, and Design, Aegean, 1999.

• Shaw, R.E., and J. Bransford, Perceiving, Acting, and Knowing, Erlbaum Associates, Hillsdale, NJ, 1986.

• Norman, D.A., and S.W. Draper, User Centered System Design: New Perspectives on Human Computer Interaction, Erlbaum Associates, Hillsdale, NJ, 1986.

• Mindell, D.A., Between Human and Machine: Feedback, Control, and Computing Before Cybernetics, The Johns Hopkins Press, 2002.

• Publications of the IEEE Systems, Man, and Cybernetics Society, www.ieeesmc.org.

• Publications of the Human Factors and Ergonomics Society, www.hfes.org.

Please send your thoughts and comments to us by clicking on the link above or by e-mailing us at todaysengineer@ieee.org. Be sure to include your name, home city and state, and IEEE membership level (if applicable). IEEE-USA Today’s Engineer reserves the right to publish letters in future issues.

 

E-mail this page to a friend Tell us what you thought of this article