Brian Sherwood Jones

from MANPRINT MAIL No. 9, March 1993


MANPRINT MAIL readers are doubtless aware that the RN version of MANPRINT has been termed Human Factors Integration. Recent discussions with fellow HF practitioners have led to the realization that there are two views of Human Factors Integration in circulation.

For the purposes of this article, I have termed them View A and View B. The very sketchy analysis to date would seem to indicate that View A is mainly associated with customer organizations and View B is largely concerned with supplier organizations.

The purpose of this note is to set out both views in the hope that both viewpoints can be promoted, eventually leading to a unified view of HF integration. The differences between the views include:

- the emphasis on what HF Integration is,

- the understanding of what problems have led to the need for a change,

- what we have to do to get there (with different views of "there") .

By and large it seems that these two views are complementary rather than in conflict, and it is not my wish to encourage any 'navel contemplation'. Certainly both views are aimed at achieving greater use of HF in system design. However, it is considered that the aim will be achieved more readily if we understand and try to implement both views of HF Integration.

The rest of this article consists of:

- a summary table of the 2 views of HF integration

- some brief amplifying text and discussion

- a note on the consequences of the present position (of partial understanding of the different meanings of HF Integration)

- some 'way ahead' ideas.

Views of HF Integration

View A
View B
Beneficiary Customer, making sure that requirements are expressed and are consistent Supplier, making sure that equipment can be shown to meet user needs
Orientation HF Community Centred 'HF-User' Centred
Viewpoint Inward looking Outward looking
Basis of decomposing HF Different HF specialist resources Different potential users of HF data
Profile High profile Specialist engineering, another "-ity"
Aspiration Empire building, focal point Resource to support other activities, largely fitting in, plus some new bits Can be tackled using established
Status New and different Can be tackled using established engineering management techniques. Build on approaches used for say ARM, EMC i.e assess and manage
Type of activity New and different Offering assurance, improving traditional craft methods
Reason for HF non-use HF is fragmented and ignored HF specialists do not meet the needs of their users
Emphasis in HF specification Clear stand-alone section covering all domains Distributed HF requirements in 'user' sections
Driver on tool development Showing that specialist tool support is available Integration into CASE, IPSE
Standards and Guidance that would help Descriptions of what HF is, and what it should do. Ways for the customer to check that HF has been carried out. Descriptions of what HF should supply to others and how they should use it. Ways for the customer to check HF has been used.
Immediate benefit to HF specialist Influence, an audience Power, some teeth


As hinted above, it is hypothesised that the reason behind the two different views of HF integration is that there are two main stakeholders to system supply - the customer and the supplier - and that one needs View A and the other needs View B.

The difference in Orientation is straightforward and summarises the difference between the two viewpoints; View A is concerned with bringing together the various specialisms within MPT and Human Engineering and Health and Safety etc. This is vital to a customer organization (where the different specialisms may be scattered throughout the organization) as it ensures that the system being bought can fit in with all aspects of the customer organization and anticipate any organizational changes and their interaction. The consequential viewpoint is looking for integration within the HF community.

In contrast, View B is vital to the supplier; The supplier will deliver a piece of equipment not an "ergonomic", and so HF endeavours only find their realization in someone else's handiwork. The integration of HF with other design activities is vital to its application to the product in question. Within a project, HF can be taken as a single entity, with a reporting structure set up for that project. Defining the precise form of dialogue with safety, systems analysis etc is important to success here, and requires an orientation that is concerned with the users of HF data. HF practitioners must be user-centred in our own work. Who are the users of our own activities? Is our approach 'user-centred'? There have been many criticisms of the usability of usability guidelines, and Crosbie tells us that "Quality is defined by the customer".

This brings us to the next topic; the breakdown of the subject (say as headings in a plan or a specification). View A would encourage the use of headings relating to different HF specialisms, while View B would encourage headings that relate to the different users of HF so that everything to do with ILS would be in one place for example.

On one recent non-MoD project we are working on at the moment the customer needs to draw together (and fund) people from diverse parts of the organization (training, health and safety, computer systems and real users ) to form a common view of the system. Our HF practitioners operate their own 'hub and spoke' dealing with all the different aspects of system design, installation, change management and operation.

The next set of aspects is to do with how HF is portrayed - what sort of PR we give ourselves. View A seems to be associated with a high profile and much razzmatazz. View B on the other hand is doing its best to say that HF is much like 'real' engineering and can be properly managed using established methods. The soft sell being pursued by View B is to say that established disciplines (architects, equipment designers, software analysts) have all been doing a splendid job, but we could do with a bit more assurance that people will be able to use the equipment they are given. In contrast, View A is saying that HF is new and different and will revolutionise everything it touches. View A is needed to get the customer organization to change its focus from buying equipment to buying a capability, while View B does not frighten the horses in an environment where any hint of empire building would close doors very firmly. View A is predicated on the assumption that HF has not 'happened' so far because it has not been possible to translate between the different domains Thus if some automation cannot be afforded, the user selection criteria may have to change or the training people have to train the user to do the job manually. This 'implications advising' role of HF is absolutely vital, as is assumptions tracking. The assumption behind this view is that HF Integration will not happen until means of making such translations are formalized. View B takes a different predicate, which is equally valid; HF is not used because too many HF-users (e.g. designers) have been given long-winded gobbledygook rather than an answer to their question. We really need remedies to both problems. However, what is not entirely true is the View A portrayal of HF waiting in the wings with perfect answers; this may have been rumbled by the person you are trying this on, and will do our credibility no good.

View A is associated with the plethora of tools emerging from the MANPRINT programme; it seems that every HF group with a Mac is doing something in Hypercard TM Whilst this is entirely healthy if viewed as a prototyping process, View B-type integration within a project insists that HF tools are integrated into CAD, CASE etc and meet proper quality standards (with a much bigger product development cost).

The two viewpoints have different standards needs; View A needs a clear description of how to bring together the diverse aspects of HF, while View B needs a clear presentation of the interfaces to other design activities. "You can't push a rope", and although Def Stan 00-56 (on hazard analysis) includes ergonomic criteria, there is no obligation on the hazard analyst to talk to (or listen to) the HF specialist. It would also seem to be the case that View A is concerned with the major milestones in the life-cycle which are the moments when a customer HF practitioner can exert some influence, while View B is concerned with what happens in between. The HUSAT Guide perhaps reflects View A, while MIL-H-46855B is more aligned with View B.

The HF practitioner in a customer organization needs to be heard; the 'soft costs' of a system are often much greater than the hard costs, and visibility of this is the first priority. What an HF practitioner in a supplier organization needs is some teeth, and the customer is the only person who can supply them by imposing mandatory requirements that register with a budgetconscious project manager.

Some Consequences

At the moment, it would appear that full implications of meeting the needs of both sorts of HF integration are only starting to emerge. However, at the moment

- View B proposals or specifications with little bits of HF all through them are giving problems to View A reviewers who have to read the whole document rather than an isolated section,

- Designers are getting away with supplying unusable functionality because HF does not have to talk to them and they do not have to consider HF implications,

- Working out the manning implications of a system is a 'three pipe problem' for the customer.

Some Suggestions

The way ahead will become easier if we can gain a clearer understanding of what is meant by HF integration. There are a number of ways of encouraging both forms of integration - the current interest in total system acceptance criteria may be one of the more effective routes.

Crown Copyright 1993

Back to top

Back to Processforusability home page