Skip to content

Archive for April, 2009


System Observers

I don’t like just ascribing new terminology when the old one did just fine, but I think we should consider one particular change in terminology when talking about designing interfaces for complex systems. I have no idea what actually constitutes a complex system, or when a system turns into a complex system, but once it does; once it is a complex system, as interface designers, we need to draw a distinction between the activities of those who interact with the system. Plenty of people have drawn the distinction between users and administrators or operators. However, I believe we need to draw distinction between operator tasks: those who observe and those who repair: System Observers and System Administrators.

Interface designers need to think about ways of empowering users to keep a watchful eye on the technology, since their natural senses aren’t any use. The problem of sensor-disconnect becomes profound for users who must monitor really complex systems. By thinking about them, not as administrators that must diagnose and repair a problem, but rather as observers that must be able to perceive a problem, or an opportunity for that matter, we can focus our interface design efforts. In other words, I believe we should stop trying to tie the activities of identifying a problem to the activities of diagnosing a problem.

For example, parents know that they can let the children play, and even roughhouse in another room while they work on something else. They can hear the children playing, and even fighting, but don’t necessarily drop what they’re doing to make sure everything’s alright. But, depending on how the children were already acting that day, what the parent’s mood is, and unique characteristics of the sounds coming from the other room (yelling, shrieking, laughing, thumps and thuds, or even a crash), the parent will first go check up on the kids before running to get bandaids or try to break them up. There’s a distinction in those activities between perceiving the situation and diagnosing it and ultimately mitigating it.

However, for complex systems, we do not enable users to do the same. The tools we provide them are designed to inform them of every little parameter we can create sensors for. And then we compound the problem by linking those sensors, via thresholds, to alarms that force them to disrupt their work. As a result, we are forced to rely on simple perceptual design methods to improve dashboards, such as highlighting and prominence techniques; or we have to rely on automation to rapidly analyze all those sensors to recognize problem – essentially moving the observation task away from the human to the machine.

Dashboards, reports, and alarms are all tools that enable an administrator to diagnose a problem, or know that a particular problem demands their attention. But that’s not what they need – they first need a better way to perceive the system itself. I believe that if we, as interface designers, separate the tools that we create into those that enable a user to observe and those that enable them to administrate and diagnose, we can ultimately create a stronger connection between the user and the complex system.