I am writing this from Driving Assessment 2007, a conference on automobile safety, held this year on the beautiful shores of the Columbia River in the state of Washington. Members of the HCI community would feel comfortable at this conference: Issues of design, workload, and distraction dominate.
Two years ago I wrote a column for <interactions> entitled "There's an Automobile in HCI's Future." This conference reinforces and adds to my view: The problems of interface design are ever present in the automobile, but are accompanied by new issues, especially that of safety.
New technologies are rapidly entering the automobile. New forms of automation interact with the driver (some don't even bother to interact, but simply take over), controlling speed, braking, lane-keeping, distance from the vehicle ahead or behind or to the sides, and automatic parking. Automatic instructions, navigation, warnings, and suggestions can also be present. There is also an ever-increasing number of third-party add-ons, such as music players, videogame players, cell phones, handheld navigation systems, and computers. All this gives rise to the potential for distraction and the danger of objects flying through the air during a collision. Altogether, there are major implications for safety. The HCI profession is used to dealing with confusion and frustration. Here is a situation where physical injury is involved. As one researcher at the conference commented, "What I really like about this area is that our research saves lives."
All of our proud, graphically oriented screen devices, especially those with touch-sensitive screens and a paucity of physical controls, may be delightful to use while in a comfortable environment, but they become safety hazards when combined with driving a car. Studies show a dramatic rise in accident rates if a driver's eyes leave the road for even two seconds. Try selecting a song or a cell contact or programming a street address into a navigation system in less than two seconds: impossible. Moreover, because the driver's attention is shifting back and forth, not only must the eyes shift from road to device and back again, but all the context must be restored: memory structures, intentions, planned activities. Task switching lengthens the time needed for each task considerably, thereby magnifying the danger. So here is a scientific question for which I do not know the answer. Suppose we have n tasks, T1, T2, ... Tn. Now suppose we do them all simultaneously, switching among them. How long does it take to do n tasks when switching between them? I am sure the answer is task-dependent, but I would not at all be surprised to discover that the time to do n tasks in this manner is between two and ten times the sum of the times required to do the tasks separately, without switching. In other words, if in a pure, pristine laboratory test, someone can change a radio station or dial a phone number in T seconds, while on the road, this same task might take 2T to 10T seconds while timesharing. Think of the added danger.
But, you may complain, people shouldn't be programming navigation systems while driving, dialing telephone numbers, changing radio stations, or selecting which piece of music to listen to. Yes, that is logically true, but, as usual, we must be guided by people's real behavior, not by logic.
How can we design the devices people insist on using in the car so that they do not increase danger? How do we design the automatic warning systems for speed, distance from the car ahead, curve speeds, lane-straying, and all of the other safety features now being designed so that they are truly of assistance and not just a nagging, annoying set of sounds, buzzes, light flashes, and vibrations? There is an interesting design problem here: Although accidents are common, they occur with very low frequency for any individual driver. Thus, although more than a million people are killed every year in automobile accidents across the world, with tens of millions injured, according to the World Health Organization, the chance that any individual will actually have an accident is remarkably low. So warnings of an impending accident, though of great importance, will almost always be a false alarm.
If we could design a system so that there were no false alarms, then drivers would seldom receive warnings, and when one occurred, they might now know how to respond. But we know that false alarms cause people to lose trust in the system. So we need a system in which the continual information about potential threats is considered reassuring and useful, so that when the situation is critical, the driver responds appropriately. Right now, engineers grapple with this problem: More behavioral scientists and HCI professionals need to be in on the act.
But before you rush off to join this important new area, be aware that it will feel like going back decades, when getting anyone to listen about usability was a full-time occupation at computer companies. Research on automobile human factors and safety is picking up in research laboratories, but within the automobile companies, engineers rule. Human-factors professionals within the automobile companies complain that management doesn't take them seriously. "How much data will they need" one researcher asked me, "before they can be convinced to add these safety features?" Ah, yes, there is that old familiar refrain: us against them, those silly, uninformed, opinionated executives. Statements like this show the huge gulf between the view of the company as seen from management and the narrow, department-centered view seen at lower levels.
The automobile industry is badly in need of guidance on human factors. Excellent people already work in this area, but they suffer the same problems faced within the consumer electronics and computer industries over the past few decades. This is an important arena, one in which human-centered design skills are essential. But success will come only when our discipline can provide seasoned managers who know how to work across disciplines, with engineers, designers (stylists), manufacturing, marketing and, of course, upper management. There should be an automobile in HCI's futurebut to make this happen presents a challenging problem in management, politics, and diplomacy.
Donald A. Norman
About the author
Don Norman wears many hats, including cofounder of the Nielsen Norman group, professor at Northwestern University, and author. His latest book, The Design of Future Things, deals with the problems of automation in the automobile and home. He lives at www.jnd.org.
Disclaimer for this article:
Norman serves on a Toyota advisory board, has a research contract from Ford, and has executive representatives from Ford, Chrysler, and General Motors on his advisory board for the MMM (MBA + MEM) program at Northwestern University.
©2007 ACM 1072-5220/07/1100 $5.00
Permission to make digital or hard copies of all or part of this work for personal or classroom use is granted without fee provided that copies are not made or distributed for profit or commercial advantage and that copies bear this notice and the full citation on the first page. To copy otherwise, to republish, to post on servers or to redistribute to lists, requires prior specific permission and/or a fee.
The Digital Library is published by the Association for Computing Machinery. Copyright © 2007 ACM, Inc.