Ignorance of Interaction
Programming Is Killing People
Harold Thimbleby

Future Interaction Technology Lab (FIT Lab), Swansea University | [e-mail]

[ 1] Thimbleby, H. Press On: Principles of Interaction Programming. Cambridge: MIT Press, 2007.

Almost a century ago, the April 9, 1929, issue of the International Herald Tribune reported the death of three young brothers. All of them had been given a dose of thallium acetate 10 times what was intended, because of a decimal-point error.

Decimal-point errors occur regularly. For instance, on October 7, 1998, The New York Times reported the death of a 10-month-old from a decimal-point error. In May 2001, the Canadian Institute of Safe Medication Practice (ISMP) reported two deaths caused by decimal-point errors: In two separate cases, . 5 mg of morphine was misread as 5 mg. The ISMP report mentioned that decimal-point errors were among the first safety issues the Institute had dealt with when it was founded almost 10 years ago. We are still risking such errors every day.

worlds—programmers discount human factors, and usability people discount programming. Users do not understand design; neither they nor interface designers can articulate the full intricacies of computerized problems. Yet programmers think their own programs, so intuitive, so easy to demonstrate, need no hard work to become usable. But all of us need to work together.

These ideas will become clearer by exploring interactive medical devices.

September + October 2008

interactions

What Is Interaction Programming? The title of this article mentions “interaction programming,” a term I’ve introduced to distinguish the programming aspects of interaction from the more-often-emphasized human aspects [ 1]. Human factors and design, together with user-centered processes, are often taken to be all there is to interaction design, but the hidden partner is the details of how things work

when they are used. As they say, the devil is in the details, and this is a matter of programming.

This article shows that the programming matters a great deal. A crucial point is that good interaction programming has to be engineered into a device’s design by good programmers; it cannot be established by inspection after it is working.

A very simple example is the Cardinal Health Alaris GP infusion pump, a new model introduced in 2006. I have one, and its firmware failed, so the manufacturers replaced it. The replacement has a new user interface quite different from the old, but of course the physical ergonomics are identical. Although there are some obvious differences between the old and new user interfaces, the exact differences (all of which affect users) cannot be established by inspecting the device. Interactive programs are too complex for unaided human comprehension; instead, good user-interface-design requirements must be engineered into programs by rigorous, formal processes.

User-centered methods and processes are essential, and, quite rightly, are emphasized by the usability community, but they are not sufficient to assure safe interaction. For too long user-centered methods and programming have lived in different

Details Matter National agencies make detailed recommendations on how to write drug dosages: Always write fractions like 0.2 mg with a leading zero, never have a trailing zero, as in 1.0 mg (it might be read as 10, not 1), and so on. There are rules for not confusing micrograms and milligrams (µg badly written could be confused with mg, causing a factor of 1,000 error). Write milliliters as mL, not as ml, which might be confused for m1. Write slash in full as “per,” that is, write “mL per hr,” not mL/hr, so the / won’t be confused. Don’t use unnecessary decimal precision: 20. 4 mg might be read as 204 mg. And so on. Unfortunately, little if any of this basic life-saving advice seems to have been picked up by manufacturers of interactive medical devices.