In the software business, most folks work in an office. Maybe a quiet, private one, or one of the dastardly open plan ones. But not usually, say, a sports arena. Or in a moving vehicle.
Sometimes, this fact is lost on the people making the software. They design buttons that are washed out when the surveyor on a phone or tablet views it outside in the sun. Or they use too many external libraries in the HTML and end up swamping users who are on high-latency connections.
Most of the time, these bugs (either in design, specification, or implementation) merely create confusion and decreased user satisfaction.
Occasionally, however, they kill people.
Although the three deaths from the Therac-25 are ultimately classified as engineering failures, mainly resulting from lack of testing and other process deficiencies, it’s possible that they could have been detected earlier if someone had observed the users operating the system:
The fifth accident occurred at the same location as the fourth. As a result, someone besides the AECL engineers had knowledge that more than one possible accident transpired while using the Therac-25. A physicists [sic] from the hospital where the two accidents occurred investigated both accidents thoroughly, discovering that the accidents were due to the quick changes made to the setup parameters by the machine operators. Through a quick series of returns, the physicists could reproduce the “Malfunction 54” error, something that AECL never could do (Leveson and Turner, 1993).
One day, back in college, I was interning at a software company that made software and hardware that powered ready-mix concrete plants. We had front-office ticketing software that ran on a PC and batch-plant automation hardware that ran on a real-time OS.
These plants are noisy, exposed to the elements, and somewhat dangerous. Sitting in our comfortable chairs in the middle of central Ohio, it was too easy to forget that the users were in considerably different environments.
To that end, the head of engineering kept a framed picture on his desk of a typical ready-mix user, complete with hard-hat, operating the system. Below the picture was the description: “Remember your target audience!”
I carry that philosophy with me every day. In every company I’ve worked, I’ve setup personas that have pictures and bios of actual customers attached and posted them in prominent positions. Not only does this put a face to the name, but helps everyone on the product team use them in discussion “Yeah, but how would Rosie use this?” – building empathy with and understanding of the customer.
If possible, I also organize “field-trips” to customer sites to actually see how users operate our software in the field – ensuring we never forget who uses our products, and how.
