Abstract
This is an eclectic issue of Ergonomics in Design. It contains three very different articles, but three articles that I hope you will find equally interesting.
Mallam et al. describe an extremely creative and effective way to incorporate ergonomics into ship design. As they point out, creating an ergonomic ship requires the collaboration of three categories of professionals: ship designers, ergonomists, and end users. They also point out that there are more human-interface issues than those encompassed by the traditional focus on safety and ease of use. The human factors/ergonomics professional can also, for example, improve onboard productivity and reduce costs.
But how can ergonomics be incorporated early enough? Interviews with end users can generate lists of requirements, but such lists are difficult to accommodate by designers, and ensuring the accuracy of such lists is challenging. Traditional usability testing requires some sort of mock-up or prototype, which, for a ship, is a major undertaking and can be made available only late in the design process, when making changes is expensive and difficult.
Mallam et al. addressed these issues by developing a software tool they call “E-SET,” for Ergonomic Ship Evaluation Tool. E-SET enables the ergonomist to incorporate information from task and link analyses directly into computer-assisted design (CAD) drawings of the ship. The tool allows the ergonomist to work with end users, who know the tasks that have to be performed aboard a ship. Then the ergonomist performs task analyses and link analyses for the various tasks. The results of these analyses are incorporated into CAD mock-ups, so the designers can see patterns of use graphically. E-SET includes algorithms that provide metrics (e.g., the distance walked and the number of stairways that have to be climbed for a given task), which can, in turn, be optimized by the designers.
As Mallam et al. point out, because ship designers are not inclined to digest complex ergonomic treatises (also true in my experience of product designers), mapping information (e.g., movement patterns) directly onto CAD models using graphic representations is much more effective. Another advantage of E-SET is that it can be used for a variety of other purposes once the ship is built, for example, new crew familiarization, task planning, and safety training.
Mallam and colleagues have provided a brilliant example of how HF/E can be effectively incorporated at an early design stage.
I’ve gone into some depth in describing their article because I believe Mallam and colleagues have provided a brilliant example of how HF/E can be effectively incorporated at an early stage into the design of large, complex systems. I’m hopeful that such an approach can be applied to other complex design problems, such as aircraft design and architecture.
Patrick Hew provides a real-world example of how a somewhat esoteric theoretical approach − Edwin Hutchins’s notion of “distributed cognition” − can be applied. Hutchins’s idea is that the notion of cognition, developed to characterize individuals, can also be applied to systems that include one or more humans and automation of some sort.
Hew uses the example of determining the trajectories of munitions. The insight is that the representation of a trajectory does not exist in any one part of the human−machine system but is, in effect, a higher-order phenomenon within the distributed system. My sense is that as the “tsunami” of the Internet of Things comes online, and we all make the transition from designing things to designing complex adaptive systems, this notion of distributed cognition will have wide application.
Finally, Nemire et al. present a case study that shows how human factors can effectively apply to an accident investigation. Their example is an alcohol lamp that generates an invisible flame. A user lit it but didn’t recognize that it was lit and so added more fuel, causing an explosion. The authors show how a careful analysis can provide methods for addressing such a hazard. A superficial analysis of such an explosion would, perhaps, identify the cause as “user error,” a cause that fails to lead to a solution − just as the old notion of “pilot error” served as a barrier to improving aviation safety.
Nemire et al., show how a more thorough root-cause analysis identifies causes that can, in fact, be addressed. They apply the “accident-prevention hierarchy” − design out the hazard if you can; guard if you can’t design it out; warn if you can’t address the hazard by an engineering solution. For the alcohol lamp, the accident could have been prevented by
adding an agent to the alcohol so that the flame would no longer be invisible,
adding a flame arrestor that would prevent an explosion even when fuel was poured onto the flame,
improving the container so that it wouldn’t explode when fuel was added to the flame, and
providing adequate warnings so people would know to expect an invisible flame.
Nemire et al. remind us that all this could have been thought out before the product was developed so that such accident investigations would not be necessary. They remind us of the important role the human factors professional can play in making products safe.
As always, I hope you find the issue useful and interesting. Please keep those submissions coming.
