In some traditional forms of participant observation the
background of the observer may have little impact on the setting, and it may have been the intention that it should have none at all. In insider action research and autoethnography, however, where the researcher has the dual role of participant and observer, the researcher does have direct influence on the events being studied. Under those circumstances, I suggest that it is required to gain insight into the researcher and his or her background, to subsequently make meaning of understandings and interpretations: “Who the researcher is, is central to what the researcher does” (Bullough & Pinnegar, 2001, p. 13).
The present section is provided as a mean towards this end.
The ATOMOS II Pilot
My first real exposure to Human Factors was when Dr. Schuffel of TNO in the Netherlands walked into my office in the middle of 1994.
The purpose of Dr. Schuffel’s visit was to suggest that we should work together in an EC project revolving round the interaction between the human element and technology in maritime transport. Happily
accepting this offer, we subsequently cooperated on the ATOMOS II project (1999), and a further number of projects following downstream.
One of the tangible results from this cooperation was a suggested standard for the human-centered development of Ship Control Centers (ATOMOS, 1998), which at best can be described as a marinized version of ISO 13407 (1999), up to and including that the ATOMOS work actually refers the FDIS version (Final Draft International Standard) of this standard.
The work on ATOMOS II (1999) counts to some extent as a pilot for the work undertaken in the current context, however with the significant difference that ATOMOS II was a pure research project, and not an industrial undertaking. The point is that while many things of a more or less experimental character can be trialed, and maybe even accomplished, in a research environment, it does not mean that subsequent industrial application is necessarily possible.
One of the lessons learned in ATOMOS II related to the work in multidisciplinary teams, which is an inherent part of UCD
(ATOMOS, 1998; ISO9241-210, 2009; ISO13407, 1999; Nielsen, 1993).
In this project, I spent 18 months having fruitless discussions with one of the team members, who was a psychologist. I honestly did not fully appreciate why we were arguing, or not necessarily even what we argued about. To me, the case was quite simple: We were designing a range of maritime instruments, with some novel functions. We needed someone to design the corresponding HMI. The ‘someone’ was the psychologist. The HMI should be uniform across the instruments. It should have good usability. The designer should use the latest cognitive knowledge in the design. Yet nothing happened, or actually, what I then saw as stalling tactics happened, in the form of apparently irrelevant questions, which the multidisciplinary team in any case could not answer at that point of the design stage: The actual tasks to be undertaken by the user, the allocation of functions between user and instruments, and hence the functions provided, how they worked, and so on. Why, I asked myself more than once, could the psychologist not just do the design in a general sense, and then we could tweak it a bit later on, when the details became available?
Another lesson learned from ATOMOS II related to
communications. Apart from the incessant arguments about the HMI design, the psychologist and I also seemed to talk past each other on most other occasions, in spite of the fact that we got on well together, at the personal level. The word ‘system’ caused a lot of what I took to be unfathomable problems. What was the issue? In a ship, you have a lot of different systems, some for fuel oil, lubrication oil, ballast water, fresh water, hydraulics, compressed air and so on. Being a naval architect, I knew more than most about this. Yet, why was the psychologist always telling me that I had to understand the ‘system’?
In hindsight, these problems might appear to be banal or maybe even naive, but they were not at that time: they were actually causing a lot of friction, lack of project progress, and general unhappiness in the team at large (since various subgroups in the team seemed to side with either of us).
Resolution came in shape of a very long nocturnal conversation on a park bench. During this conversation, I finally grasped two distinct issues: Firstly, the HMI was not a discrete, isolated component where the only concern was look and feel – it was the direct connection between the user’s mental model of the process and the process itself, and it could not be usefully designed without that knowledge. Secondly,
in the psychologists terminology, ‘system’ did not mean the mechanical
‘systems’ I was talking about, and which were to be managed from the HMI – it meant the socio-technical ‘work-system’, considering the human-machine combination.
The Client HMI Pilot
More recently, meaning during the last decade, I have been applying usability development principles on select cases – at least to the level of involving end-users in the design. For a Client, I have initiated and conducted the design of a Human Machine Interface (HMI), which served to demonstrated the value of user involvement in the design process for those involved: easier user acceptance of the final result, and reduced rework, also providing risk mitigation of the
business risks associated with software development (McConnell, 1996).
At the corporate level, we have also been using select usability principles on a mid-sized scale, concretely as the methodology for HMI development of a new series of operator panels – focusing on
consistency across a series of different sizes of panels, with different interaction means. In this case, the main issue was to design an intuitive HMI which grew in functionality as the corresponding hardware grew in capability – from the very simple, to the rather complex. An important aspect of this work was that it involved some of the same players as the main projects reported here did, including Pegasus4 and Crux, and that this project similarly was sanctioned by Leo, a manager in my
organization.
The Impact of Pilot Studies
In summary, the above paints a picture of me as a ‘human-factors aware’ project manager, with some experiential knowledge regarding UCD under the belt. It should also, importantly, provide the understanding that the organization I work for was (and is) both
4. In some parts of this thesis, persons are named after the larger constellations close to Earth (and thus known and valuable to mariners for guidance), for the sake of anonymity
‘human-factors aware’ and ‘human-factors sympathetic’. I cannot take the credit for the latter: Leo participated in ATOMOS II (1999) as well as I did, worked on the conceptual standard for ship control center design, as I did (ATOMOS, 1998), and got hooked, as I did, on the importance of human factors engineering during that phase. Our sharing of that reference frame is invaluable in the current context: Not only did it provide a gravitational force towards UCD as such, but it pre-empted any discussion about applying UCD in Project Alpha at all:
We saw this as natural, given the ‘once-in-a-lifetime’ opportunity to redesign our HMI from the ground up. Our shared beliefs also provided the stamina to hold on to the decision during that project, even when challenged from various points.