HCI/E(U) Approach

The HCI/E(U) Conception of the HCI Engineering general design problem is expressed informally as: ‘to design human interactions with computers for effective working.’ (C1) The EU Conception is a unitary view of a general design problem; its power lies in the coherence and completeness of its definition of the concepts, which can express that problem. Engineering knowledge, in the form of principles, would be expressed in terms of those same concepts). (C2) (F1)

The HCI/E(U) Conception of the HCI Engineering design problem presupposes an associated HCI Discipline having three primary characteristics: a general problem; practices providing solutions to that problem; and knowledge supporting those practices. (C3) The EU conception of the design problem belongs to the class of general design problem and includes the design of artefacts (for example, bridges) and the design of states of the world (for example, public administration). (C4)

The HCI/E(U) Conception has the necessary property of a scope, delimiting the province of concern of the associated discipline of HCI Engineering. (C5) The scope includes: humans, both as individuals, groups and as social organisations. It also includes computers, both as programmable machines, stand-alone and networked, and as functionally embedded devices within machines. Its scope also includes: work, both as concerns individuals and the organisations in which it occurs.

The HCI/E(U) Conception categorises HCI Engineering design problems as ‘hard’ or ‘soft’. Hard and soft problems are distinguished by the need for engineering design solutions, as specified by HCI design practices, to be determinate. The design practices vary in the completeness of their specification before implementation. ‘Specify then implement’ design practices (based on formal design knowledge, such as principles) implicate more complete specification. ‘Implement and test’ design practices (based on informal design knowledge, such as guide-lines) implicate less complete specification. (C8) (F2) Taken together, the dimension of problem hardness, characterising HCI general design problems and the dimension of specification completeness, characterising HCI practices, constitute a classification space for approaches to HCI engineering, of which EU engineering is one. (C9)

The HCI/E(U) Conception of the HCI Engineering design problem asserts a fundamental distinction between behavioural systems, which perform work and a world in which work originates, is performed and has its consequences. (C13)  Effectiveness derives from the relationship of an interactive worksystem with its domain of application, assimilating both the work performed by the worksystem and the costs it incurs. (C14) The concern of the associated HCI Engineering discipline is to design the interactive worksystem for performance. (C15). The interactive worksystem is constituted of two separate, but interacting sub-systems, that is, a system of human behaviours, interacting with a system of computer behaviours. (C16)

According to the HCI/E(U) Conception, the general design problem of HCI Engineering is to produce implementable designs of human behaviours, which, interacting with computer behaviours, are constituted within a worksystem, whose performance conforms with some desired performance. (C17) The interactions take place in a world in which work originates and has its consequences. (C18) This work arises at the intersection of organisations and computer technology and is expressed in terms of objects. The latter may be both abstract, as well as physical and are characterised by their attributes. (C19) Abstract attributes are of information and knowledge. Physical attributes are of energy and matter. The different attributes of an object emerge at different levels within a hierarchy of levels of complexity. (C20) Attributes of objects are related in two ways – at different levels of complexity and within those levels. (C21) Attributes have states, which change or are changed over time. Thus, objects exhibit an affordance for transformation, expressed by their attributes’ potential for change of state. (C22) A domain of application is conceptualised as: ‘a class of affordance of a class of objects’. (C23)

Following the HCI/E)U) Conception, organisations are conceived as having domains as their operational scope and requiring the realisation of the affordance of objects. It is a requirement satisfied by work. (C24) Organisations express their requirement for the transformation of objects by formulating goals. A product goal specifies a required transformation, realised by means of the affordance of objects. (C25) The concept of Quality describes the variance of an actual transform with that specified by a product goal. An EU HCI Engineering problem exists, when actual Quality is not equal to desired Quality. (C26) Conception of the domain is of objects, characterised by their attributes and exhibiting an affordance, arising from the potential changes of state of those attributes. (C27)

The HCI/E(U) Conception identifies interactive worksystems, consisting of human and computer behaviours together performing work. (C28) Humans formulate goals and their corresponding behaviors are said to be intentional (or purposeful). Computers are designed to achieve goals and their corresponding behaviours are said to be intended (or purposive). An interactive worksystem is a behavioural system distinguished by a boundary, enclosing all human and computer behaviours, whose purpose is to achieve a common goal. (C29) Worksystems achieve goals by the transformation of objects, that is, by producing state changes in the abstract and physical attributes of those objects. (C30) The behaviors of the human and computer are conceptualised as behavioral sub-systems of the worksystem – sub-systems, which interact. (C31) Behavior may be loosely understood as ‘what the user does’ in contrast with ‘what is done’, that is, attribute state changes of the domain. More precisely, the user is conceptualised as a system of distinct, but related, human behaviours identifiable as the sequence of states of a person interacting with a computer to perform work and corresponding with an intentional transformation of objects in a domain. Although possible at many levels, the user must be at least conceptualised at a level commensurate with the level of description of the transformation of objects in the domain. (C32)

In the HCI/E(U) Conception, worksystem behaviours are both physical and abstract. (C33) The latter process information, concerning object-attribute-state changes in the domain, whose transformation is required by goals. Physical behaviours are related to, and express, abstract behaviors. In addition, the user is conceptualised as having cognitive (knowing), conative (trying) and affective (experiencing) aspects. (C34) The user may include both on-line and off-line human behaviours. On-line behaviours are associated with the computer’s representation of the domain; 0ff-line behaviours are associated with non-computer representations of the domain or the latter itself. Conceptualisation of the user as a system of human behaviours is extended to the structures enabling behaviours. (C37) There is a one-to-many mapping between a human’s structures and the behaviours they might enable. The structures may support many different behaviours. Physical human structures are neural, biomechanical and physiological. Mental structures consist of representations and processes, which transform them, (C38)

Work performed by interactive worksystems incurs ‘resource costs’. (C39) Certain costs are associated with the user and distinguished as structural human costs and behavioural human costs. Structural human (‘set-up’ or learning) costs are incurred in the development of human skills and knowledge, as in training and education. Such costs are both mental and physical. (C40) Behavioral human costs are incurred, when the user recruits human structures to perform work. Such costs are both mental and physical. (C41)

In the HCI/E(U) Conception of the HCI Engineering design problem, effectiveness derives from the relationship of an interactive worksystem with its domain. Effectiveness assimilates both the quality of the work performed by the worksystem and the costs incurred by it. (C42) Quality and costs are the primary constituents of the concept of performance through which effectiveness is expressed. A desired performance of an interactive worksystem is conceptualised such that desired performance might be either absolute or relative, as in a comparative performance to be matched or improved upon. (C43) This EU Engineering Conception of performance has the following implications.

First, the quality of the transform, expressing performance, is distinguished from the effectiveness of the worksystem, which produces it. (C44) Second, optimal human behaviours are conceived as those incurring the minimum resource costs in producing a given transform. (C45) Third, common measures of ‘human performance’ – such as ‘time and errors’- are related to performance, as conceived here. (46) Errors may increase resource costs and/or reduce quality. The time taken by human behaviours may (very generally) be associated with increased user costs. Fourth, structural and behavioural human costs may be traded off in performance. (C47) Finally, fifth, user and computer costs may also be traded off. (C48) This concludes a summary of the EU Conception of the HCI Engineering design problem.

The Conception is a unitary view of the necessary concepts and their relations to express that design problem and so, any design solution. In addition, it is a pre-requisite for developing formal HCI Engineering design knowledge as principles to support ‘specify then implement’ HCI engineering design practices. A complete version of the Conception can be found in the short and full versions of the Dowell and Long (1989) original paper – see 2.4 and 2.5.

The EU Conception of the HCI Engineering general design problem is expressed informally as: ‘to design human interactions with computers for effective working.’ (C1) The EU Conception is a unitary view of a general design problem; its power lies in the coherence and completeness of its definition of the concepts, which can express that problem. Engineering knowledge, in the form of principles, would be expressed in terms of those same concepts). (C2) (F1)

The EU Conception of the HCI Engineering design problem presupposes an associated HCI Discipline having three primary characteristics: a general problem; practices providing solutions to that problem; and knowledge supporting those practices. (C3) The EU conception of the design problem belongs to the class of general design problem and includes the design of artefacts (for example, bridges) and the design of states of the world (for example, public administration). (C4)

The EU Conception has the necessary property of a scope, delimiting the province of concern of the associated discipline of HCI Engineering. (C5) The scope includes: humans, both as individuals, groups and as social organisations. It also includes computers, both as programmable machines, stand-alone and networked, and as functionally embedded devices within machines. Its scope also includes: work, both as concerns individuals and the organisations in which it occurs.

The EU Conception categorises HCI Engineering design problems as ‘hard’ or ‘soft’. Hard and soft problems are distinguished by the need for engineering design solutions, as specified by HCI design practices, to be determinate. The design practices vary in the completeness of their specification before implementation. ‘Specify then implement’ design practices (based on formal design knowledge, such as principles) implicate more complete specification. ‘Implement and test’ design practices (based on informal design knowledge, such as guide-lines) implicate less complete specification. (C8) (F2) Taken together, the dimension of problem hardness, characterising HCI general design problems and the dimension of specification completeness, characterising HCI practices, constitute a classification space for approaches to HCI engineering, of which EU engineering is one. (C9)

The EU Conception of the HCI Engineering design problem asserts a fundamental distinction between behavioural systems, which perform work and a world in which work originates, is performed and has its consequences. (C13)  Effectiveness derives from the relationship of an interactive worksystem with its domain of application, assimilating both the work performed by the worksystem and the costs it incurs. (C14) The concern of the associated HCI Engineering discipline is to design the interactive worksystem for performance. (C15). The interactive worksystem is constituted of two separate, but interacting sub-systems, that is, a system of human behaviours, interacting with a system of computer behaviours. (C16)

According to the EU Conception, the general design problem of HCI Engineering is to produce implementable designs of human behaviours, which, interacting with computer behaviours, are constituted within a worksystem, whose performance conforms with some desired performance. (C17) The interactions take place in a world in which work originates and has its consequences. (C18) This work arises at the intersection of organisations and computer technology and is expressed in terms of objects. The latter may be both abstract, as well as physical and are characterised by their attributes. (C19) Abstract attributes are of information and knowledge. Physical attributes are of energy and matter. The different attributes of an object emerge at different levels within a hierarchy of levels of complexity. (C20) Attributes of objects are related in two ways – at different levels of complexity and within those levels. (C21) Attributes have states, which change or are changed over time. Thus, objects exhibit an affordance for transformation, expressed by their attributes’ potential for change of state. (C22) A domain of application is conceptualised as: ‘a class of affordance of a class of objects’. (C23)

Following the EU Conception, organisations are conceived as having domains as their operational scope and requiring the realisation of the affordance of objects. It is a requirement satisfied by work. (C24) Organisations express their requirement for the transformation of objects by formulating goals. A product goal specifies a required transformation, realised by means of the affordance of objects. (C25) The concept of Quality describes the variance of an actual transform with that specified by a product goal. An EU HCI Engineering problem exists, when actual Quality is not equal to desired Quality. (C26) Conception of the domain is of objects, characterised by their attributes and exhibiting an affordance, arising from the potential changes of state of those attributes. (C27)

The EU Conception identifies interactive worksystems, consisting of human and computer behaviours together performing work. (C28) Humans formulate goals and their corresponding behaviors are said to be intentional (or purposeful). Computers are designed to achieve goals and their corresponding behaviours are said to be intended (or purposive). An interactive worksystem is a behavioural system distinguished by a boundary, enclosing all human and computer behaviours, whose purpose is to achieve a common goal. (C29) Worksystems achieve goals by the transformation of objects, that is, by producing state changes in the abstract and physical attributes of those objects. (C30) The behaviors of the human and computer are conceptualised as behavioral sub-systems of the worksystem – sub-systems, which interact. (C31) Behavior may be loosely understood as ‘what the user does’ in contrast with ‘what is done’, that is, attribute state changes of the domain. More precisely, the user is conceptualised as a system of distinct, but related, human behaviours identifiable as the sequence of states of a person interacting with a computer to perform work and corresponding with an intentional transformation of objects in a domain. Although possible at many levels, the user must be at least conceptualised at a level commensurate with the level of description of the transformation of objects in the domain. (C32)

In the EU Conception, worksystem behaviours are both physical and abstract. (C33) The latter process information, concerning object-attribute-state changes in the domain, whose transformation is required by goals. Physical behaviours are related to, and express, abstract behaviors. In addition, the user is conceptualised as having cognitive (knowing), conative (trying) and affective (experiencing) aspects. (C34) The user may include both on-line and off-line human behaviours. On-line behaviours are associated with the computer’s representation of the domain; 0ff-line behaviours are associated with non-computer representations of the domain or the latter itself. Conceptualisation of the user as a system of human behaviours is extended to the structures enabling behaviours. (C37) There is a one-to-many mapping between a human’s structures and the behaviours they might enable. The structures may support many different behaviours. Physical human structures are neural, biomechanical and physiological. Mental structures consist of representations and processes, which transform them, (C38)

Work performed by interactive worksystems incurs ‘resource costs’. (C39) Certain costs are associated with the user and distinguished as structural human costs and behavioural human costs. Structural human (‘set-up’ or learning) costs are incurred in the development of human skills and knowledge, as in training and education. Such costs are both mental and physical. (C40) Behavioral human costs are incurred, when the user recruits human structures to perform work. Such costs are both mental and physical. (C41)

In the EU Conception of the HCI Engineering design problem, effectiveness derives from the relationship of an interactive worksystem with its domain. Effectiveness assimilates both the quality of the work performed by the worksystem and the costs incurred by it. (C42) Quality and costs are the primary constituents of the concept of performance through which effectiveness is expressed. A desired performance of an interactive worksystem is conceptualised such that desired performance might be either absolute or relative, as in a comparative performance to be matched or improved upon. (C43) This EU Engineering Conception of performance has the following implications.

First, the quality of the transform, expressing performance, is distinguished from the effectiveness of the worksystem, which produces it. (C44) Second, optimal human behaviours are conceived as those incurring the minimum resource costs in producing a given transform. (C45) Third, common measures of ‘human performance’ – such as ‘time and errors’- are related to performance, as conceived here. (46) Errors may increase resource costs and/or reduce quality. The time taken by human behaviours may (very generally) be associated with increased user costs. Fourth, structural and behavioural human costs may be traded off in performance. (C47) Finally, fifth, user and computer costs may also be traded off. (C48) This concludes a summary of the EU Conception of the HCI Engineering design problem.

The Conception is a unitary view of the necessary concepts and their relations to express that design problem and so, any design solution. In addition, it is a pre-requisite for developing formal HCI Engineering design knowledge as principles to support ‘specify then implement’ HCI engineering design practices. A complete version of the Conception can be found in the short and full versions of the Dowell and Long (1989) original paper – see 2.4 and 2.5.

Key concepts are shown in bold on their first appearance only.

2.6.1 Problem

The concept of problem can only be understood in conjunction with the concept of solution. A problem is an unwanted (F1) state-of-affairs (F2) (C1). Once identified (F3), a problem requires a solution (F4). The solution resolves the problem by changing the unwanted state-of affairs to a wanted state-of-affairs. (C2) The concepts of problem and solution are thus closely linked. However, not all problems have a solution (F5); but all solutions have problems. (F6) Problems may have more than one solution (F7) and solutions more than one problem. (F8) (C3) Solutions may be novel or known from their resolution of earlier problems. (F9) (C4)

2.6.2 Design

The concepts of ‘design’ and ‘implementation’ are closely linked to each other. (F1) In general, designs are for implementation and implementations are of designs. (F2) (C1) (C7) A design represents (F3) an object or artefact. (C6) An implementation realises (F4) the object or artefact. (F5) (C2) However, designs may remain unimplemented and implementations may not have been designed. (F6) (C3) (C4) (C5)

2.6.3 Design Problem

The concept of ‘design problem’ is a conjunction of ‘design’ and ‘problem’. (C1) However, the order makes clear, that design qualifies problem and not the reverse. (F1) (C2) Here, the concept of design problem is defined by intersecting the concept of design (2.6.1) with the concept of problem (2.6.2), a definition in which the latter is qualified by the former. (C3) A design problem is a state-of-design affairs (F2), which is not as wanted. (F3) Once identified, a design problem requires a design solution, which represents the designed state-of-affairs and which, if implemented, realises that state-of-affairs. (F4) (C4) (C5) However, not all design problems have design solutions and not all design solutions are implemented. (C6) But all design solutions imply design problems. (F5) Design problems may have more than one design solution and design solutions more than one problem. (C7) The latter may have more than one implementation. (C8) Design solutions may be novel or known from their resolution of earlier design problems. (F6) (C9)

3.6.1 Design
The concepts of ‘design’ (C1) and ‘implementation’ are closely linked to each other. (F1) (C2) In general, designs are for implementation and implementations are of designs. (F2) A design represents (F3) an object or artefact. (C4)  An implementation realises (F4) the object or artefact. (F5) (C5) However, designs may remain unimplemented and implementations may not have been designed. (F6) (C3)

3.6.2 Knowledge
Knowledge can be contrasted with ‘belief’. Once assured, belief becomes knowledge. It remains, however, only assured belief. (F1) Assurance, here, is acquired through experience and can be expressed as: facts; information; descriptions; representations; skills; principles; laws etc. (C2) Knowledge has two primary modes of expression. Knowing that (something is the case, that is, for example, a fact) and knowing how (that is, a skill in doing something). Usually both modes of knowledge are used to take effective action to achieve goals. (C1) Similarly, both are used to increase the assurance, which can be ascribed to a belief. (F2) Useful contrasts between types of knowledge include: theoretical/practical; implicit/explicit/ formal/informal; and systematic/nonsystematic. (F3) (C3)

3.6.3 Design Knowledge

The HCI Design Practice Conception pre-supposes an associated HCI Discipline having three primary characteristics: a general problem; practices, providing solutions to that problem; and knowledge supporting those practices. (C5) The general HCI problem is: to design people’s use of computers to do something as wanted. (F1)

The HCI Conception, then, is unequivocally one of design practice and its support by knowledge. (C1) HCI design practice is the product of research and practice, both of which solve HCI design problems. (F2) (C2) Such practice may be private or public, formal or informal. It may assume a number of forms, for example, codified; experienced; proceeduralised; demonstrated; exemplified as in methods; skills; theories; guidelines; heuristics; rules-of-thumb; principles; hints-and-tips etc.  (C3)(C4)

HCI design practice may be maintained in a number of ways: for example, it may be expressed in journals; example solutions to design problems; methods; learning systems; communities; good practice; procedures; word-of-mouth; tools etc.  HCI practice is, therefore, a necessary characteristic of the HCI discipline, its practices and its design problem. (F3)

This wide range of HCI design practices is matched by an equally wide range of HCI design knowledge, together seeking, specifying and implementing solutions to the HCI design problem. Such design practices include: ‘specify-then- implement’ (specification precedes implementation); ‘specify-and-implement’ (specification and implementation proceed together); ‘implement-and-test’ (implementation occurs without specification, as in ‘trial and error’ and ‘implement and iterate’). In addition, all of these practices may include iteration and test in a variety of different ways. (F4) (C6) (C7)

Key concepts are shown in bold on their first appearance only.

4.6.1 Design

The concepts of ‘design’ (C1) and ‘implementation’ are closely linked to each other. (F1) (C2) In general, designs are for implementation and implementations are of designs. (F2) A design represents (F3) an object or artefact. (C4)  An implementation realises (F4) the object or artefact. (F5) (C5) However, designs may remain unimplemented and implementations may not have been designed. (F6) (C3)

4.6.2 Practice

Practice can be contrasted with knowledge. (F1) (C1) The latter has two primary modes of expression. Knowing that (something is the case, that is, for example, a fact, a theory etc) and knowing how (that is, a skill, a method etc for doing something). Practice recruits both types of knowledge to take effective action to achieve goals. (F2) (C2) Knowledge, then, is ‘put into action’, that is, used, made use of, utilised, applied etc. Useful contrasts between types of practice include: theory/action; implicit/explicit/formal/informal; and systematic/non-systematic. (F3) (C3)

4.6.3 Design Practice

The concept of ‘design practice’ is a conjunction of ‘design’ and ‘practice’. However, the order makes clear, that design qualifies practice and not the reverse. (F1) Here, the concept of design practice is defined by intersecting the concept of design (4.6.1) with the concept of practice (4.6.2), a definition in which the latter is qualified by the former.

A design problem (see 2.6.3) is a state-of-design affairs, which is not as wanted. (F2) Once identified, a design problem requires a design solution, which represents the designed state-of-affairs and which, if implemented, realises that state-of-affairs. Design practice is supported by knowledge to solve the design problem. (C1) The support can be substantive (knowing what) or methodological (knowing how) or both. (F3)

However, not all design problems have the necessary design practice for their solution. But all design  is intended to addresses one or more design problems. Design  may be novel or carried forward from its resolution of earlier design problems. (C2)

Towards a Conception for an Engineering Discipline of Human Factors

Short version

John Dowell and John Long

Ergonomics Unit, University College London, 

26, Bedford Way, London. WC1H 0AP. 

Abstract  ……… The paper is in two parts. Part I examines the potential for Human Factors to formulate engineering principles. …….. A conception would provide the set of related concepts which both expressed the general design problem more formally, and which might be embodied in engineering principles.

In P. Barber and J. Laws (ed.s) Special Issue on Cognitive Ergonomics, Ergonomics, 1989, vol. 32, no. 11, pp. 1613-1536.

Part I. Requirement for Human Factors as an Engineering Discipline of Human-Computer Interaction

1.1 Introduction;

1.2 Characterization of the human factors discipline;

1.3 State of the human factors art;

1.4 Human factors engineering;

1.5 The requirement for an engineering conception of human factors.

1.1 Introduction

Assessment of contemporary HF (Section 1.3.) concludes that its practices are predominantly those of a craft. Shortcomings of those practices are exposed which indict the absence of support from appropriate formal discipline knowledge. This absence prompts the question as to what might be the formal knowledge which HF could develop, and what might be the process of its formulation. By comparing the HF general design problem with other, better understood, general design problems, and by identifying the formal knowledge possessed by the corresponding disciplines, the potential for HF engineering principles is suggested (Section 1.4.).

However, a pre-requisite for the formulation of any engineering principle is a conception. A conception is a unitary (and consensus) view of a general design problem; its power lies in the coherence and completeness of its definition of the concepts which can express that problem. Engineering principles are articulated in terms of those concepts. Hence, the requirement for a conception for the HF discipline is concluded (Section 1.5.).

1.2. Characterisation of the Human Factors Discipline

Most definitions of disciplines assume three primary characteristics: a general problem; practices, providing solutions to that problem; and knowledge, supporting those practices.

1.3. State of the Human Factors Art

It would be difficult to reject the claim that the contemporary HF discipline has the character of a craft …….. Characteristic of a craft, the execution and success of its practices in systems development depends principally on the expertise, guided intuition and accumulated experience which the practitioner brings to bear on the design problem.

……..

The dogma of HF as necessarily a craft whose knowledge may only be the accrued experience of its practitioners, is nowhere presented rationally.

……Third, HF practices are inefficient. Each development of a system requires the solving of new problems by implementation then testing. There is no formal structure within which experience accumulated in the successful development of previous systems can be recruited to support solutions to the new problems, except through the memory and intuitions of the designer. These may not be shared by others, except indirectly (for example, through the formulation of heuristics), and so experience may be lost and may have to be re-acquired (Long and Dowell, 1989).

The guidance may be direct – by the designer’s familiarity with psychological theory and practice, or may be indirect by means of guidelines derived from psychological findings. In both cases, the guidance can offer only advice, which must be implemented then tested to assess its effectiveness. Since the general scientific problem is the explanation and prediction of phenomena, and not the design of artifacts, the guidance cannot be directly embodied in design specifications which offer a guarantee with respect to the effectiveness of the implemented design.

…….. These four deficiencies are endemic to the craft nature of contemporary HF practice. They indict the tacit HF discipline knowledge consisting of accumulated experience embodied in procedures, even where that experience has been influenced by guidance offered by the science of psychology .Because the knowledge is tacit (i.e., implicit or informal), it cannot be operationalised, and hence the role of HF in systems development cannot be planned as would be necessary for the proper integration of the knowledge. Without being operationalised, its knowledge cannot be tested, and so the efficacy of the practices it supports cannot be guaranteed. Without being tested, its knowledge cannot be generalised for new applications and so the practices it can support will be inefficient. Without being operationalised, testable, and general, the knowledge cannot be developed in any structured way as required for supporting the systematic and intentional progress of the HF discipline.

It would be incorrect to assume the current absence of formality of HF knowledge to be a necessary response to the indeterminism of human behaviour………. The extent to which human behaviour is deterministic for the purposes of designing interactive computer-based systems needs to be independently established. Only then might it be known if HF discipline knowledge could be formal.

1.4. Human Factors Engineering Principles

HF has been viewed earlier (Section 1.2.) as comparable to other disciplines which address general design problems: for example, Civil Engineering and Health Administration. The nature of the formal knowledge of a future HF discipline might, then, be suggested by examining such disciplines. The general design problems of different disciplines, however, must first be related to their characteristic practices, in order to relate the knowledge supporting those practices.

……..

there exists no pre-ordained relationship between the formality of a discipline’s knowledge and the hardness of its general design problem. In particular, the practices of a (craft) discipline supported by experience – that is, by informal knowledge – may address a hard problem. But also, within the boundary of determinism, that discipline could acquire formal knowledge to support specification as a design practice.

…….. Generally, the established engineering disciplines possess formal knowledge: a corpus of operationalised, tested, and generalised principles. Those principles are prescriptive, enabling the complete specification of design solutions before those designs are implemented (see Dowell and Long, 1988b). This theme of prescription in design is central to the thesis offered here.

Engineering principles can be substantive or methodological (see Checkland, 1981; Pirsig, 1974). Methodological Principles prescribe the methods for solving a general design problem optimally. For example, methodological principles might prescribe the representations of designs specified at a general level of description and procedures for systematically decomposing those representations until complete specification is possible at a level of description of immediate design implementation (Hubka, Andreason and Eder, 1988). Methodological principles would assure each lower level of specification as being a complete representation of an immediately higher level.

Substantive Principles prescribe the features and properties of artefacts, or systems that will constitute an optimal solution to a general design problem. As a simple example, a substantive principle deriving from Kirchoff’s Laws might be one which would specify the physical structure of a network design (sources, resistances and their nodes etc) whose behaviour (e.g., distribution of current) would constitute an optimal solution to a design problem concerning an amplifier’s power supply.

1.5. The Requirement for an Engineering Conception for Human Factors

The contemporary HF discipline does not possess either methodological or substantive engineering principles. The heuristics it possesses are either ‘rules of thumb’ derived from experience or guidelines derived from psychological theories and findings. Neither guidelines nor rules of thumb offer assurance of their efficacy in any given instance, and particularly with regard to the effectiveness of a design. The methods and models of HF (as opposed to methodological and substantive principles) are similarly without such an assurance. Clearly, any evolution of HF as an engineering discipline in the manner proposed here has yet to begin. There is an immediate need then, for a view of how it might begin, and how formulation of engineering principles might be precipitated.

……..Such a conception is a unitary (and consensus) view of the general design problem of a discipline. Its power lies in the coherence and completeness of its definition of concepts which express that problem. Hence, it enables the formulation of engineering principles which embody and instantiate those concepts. A conception (like a paradigm) is always open to rejection and replacement.

…….. It is inconceiveable that a formulation of HF engineering principles might occur whilst there is no consensus understanding of the concepts which they would embody. Articulation of a conception must then be a pre-requisite for formulation of engineering principles for HF.

Part II. Conception for an Engineering Discipline of Human Factors 

2.1 Conception of the human factors general design problem;

2.2 Conception of work and user; 2.2.1 Objects and their attributes; 2.2.2 Attributes and levels of complexity; 2.2.3 Relations between attributes; 2.2.4 Attribute states and affordance; 2.2.5 Organisations, domains (of application)2.2.6 Goals; 2.2.7 Quality; 2.2.8 Work and the user; and the requirement for attribute state changes;

2.3 Conception of the interactive worksystem and the user; 2.3.1 Interactive worksystems; 2.3.2 The user as a system of mental and physical human behaviours; 2.3.3 Human-computer interaction; 2.3.4 On-line and off-line behaviours; 2.3.5 Human structures and the user; 2.3.6 Resource costs and the user;

2.4 Conception of performance of the interactive worksystem and the user;

2.5 Conclusions and the prospect for Human Factors engineering principles

2.5. Conclusions and the Prospect for Human Factors Engineering Principles

…….. The extent to which HF engineering principles might be realiseable in practice remains to be seen. It is not supposed that the development of effective systems will never require craft skills in some form, and engineering principles are not seen to be incompatible with craft knowledge, particularly with respect to their instantiation (Long and Dowell, 1989). At a minimum, engineering principles might be expected to augment the craft knowledge of HF professionals. Yet the great potential of HF engineering principles for the effectiveness of the discipline demands serious consideration. References Ashby W. Ross, (1956), An Introduction to Cybernetics. London: Methuen.

Bornat R. and Thimbleby H., (1989), The Life and Times of ded, Text Display Editor. In J.B. Long and A.D. Whitefield (ed.s), Cognitive Ergonomics and Human Computer Interaction. Cambridge: Cambridge University Press.

Card, S. K., Moran, T., and Newell, A., (1983), The Psychology of Human Computer Interaction, New Jersey: Lawrence Erlbaum Associates.

Carey, T., (1989), Position Paper: The Basic HCI Course For Software Engineers. SIGCHI Bulletin, Vol. 20, no. 3.

Carroll J.M., and Campbell R. L., (1986), Softening up Hard Science: Reply to Newell and Card. Human Computer Interaction, Vol. 2, pp. 227-249.

Checkland P., (1981), Systems Thinking, Systems Practice. Chichester: John Wiley and Sons.

Cooley M.J.E., (1980), Architect or Bee? The Human/Technology Relationship. Slough: Langley Technical Services.

Didner R.S. A Value Added Approach to Systems Design. Human Factors Society Bulletin, May 1988. Dowell J., and

Long J. B., (1988a), Human-Computer Interaction Engineering. In N. Heaton and M . Sinclair (ed.s), Designing End-User Interfaces. A State of the Art Report. 15:8. Oxford: Pergamon Infotech.

Dowell, J., and Long, J. B., 1988b, A Framework for the Specification of Collaborative Research in Human Computer Interaction, in UK IT 88 Conference Publication 1988, pub. IEE and BCS.

Gibson J.J., (1977), The Theory of Affordances. In R.E. Shaw and J. Branford (ed.s), Perceiving, Acting and Knowing. New Jersey: Erlbaum.

Gries D., (1981), The Science of Programming, New York: Springer Verlag.

Hubka V., Andreason M.M. and Eder W.E., (1988), Practical Studies in Systematic Design, London: Butterworths.

Long J.B., Hammond N., Barnard P. and Morton J., (1983), Introducing the Interactive Computer at Work: the Users’ Views. Behaviour And Information Technology, 2, pp. 39-106.

Long, J., (1987), Cognitive Ergonomics and Human Computer Interaction. In P. Warr (ed.), Psychology at Work. England: Penguin.

Long J.B., (1989), Cognitive Ergonomics and Human Computer Interaction: an Introduction. In J.B. Long and A.D. Whitefield (ed.s), Cognitive Ergonomics and Human Computer Interaction. Cambridge: Cambridge University Press.

Long J.B. and Dowell J., (1989), Conceptions of the Discipline of HCI: Craft, Applied Science, and Engineering. In Sutcliffe A. and Macaulay L., Proceedings of the Fifth Conference of the BCS HCI SG. Cambridge: Cambridge University Press.

Marr D., (1982), Vision. New York: Wh Freeman and Co. Morgan D.G.,

Shorter D.N. and Tainsh M., (1988), Systems Engineering. Improved Design and Construction of Complex IT systems. Available from IED, Kingsgate House, 66-74 Victoria Street, London, SW1.

Norman D.A. and Draper S.W. (eds) (1986): User Centred System Design. Hillsdale, New Jersey: Lawrence Erlbaum;

Pirsig R., 1974, Zen and the Art of Motorcycle Maintenance. London: Bodley Head.

Rouse W. B., (1980), Systems Engineering Models of Human Machine Interaction. New York: Elsevier North Holland.

Shneiderman B. (1980): Software Psychology: Human Factors in Computer and Information Systems. Cambridge, Mass.: Winthrop.

Thimbleby H., (1984), Generative User Engineering Principles for User Interface Design. In B. Shackel (ed.), Proceedings of the First IFIP conference on Human-Computer Interaction. Human-Computer Interaction – INTERACT’84. Amsterdam: Elsevier Science. Vol.2, pp. 102-107.

van Gisch J. P. and Pipino L.L., (1986), In Search of a Paradigm for the Discipline of Information Systems, Future Computing Systems, 1 (1), pp. 71-89.

Walsh P., Lim K.Y., Long J.B., and Carver M.K., (1988), Integrating Human Factors with System Development. In: N. Heaton and M. Sinclair (eds): Designing End-User Interfaces. Oxford: Pergamon Infotech.

Wilden A., 1980, System and Structure; Second Edition. London: Tavistock Publications.

This paper has greatly benefited from discussion with others and from their criticisms. We would like to thank our collegues at the Ergonomics Unit, University College London and in particular, Andy Whitefield, Andrew Life and Martin Colbert. We would also like to thank the editors of the special issue for their support and two anonymous referees for their helpful comments. Any remaining infelicities – of specification and implementation – are our own

1. HCI Engineering Discipline

All the EU research is grounded in an EU Conception of an HCI Engineering discipline, itself a product of the research. The Conception was published in Long and Dowell (1989) and a full version of the Conception and the paper is presented in 1.5. To make the Conception more accessible to a wide range of researchers: a complete expression appears in a short version of Long and Dowell in 1.4; a summary version in 1.3; a generalised HCI Engineering version in 1.2; and finally, a generalised HCI version in 1.1. The latter also serves as an introduction to the Conception.

Researchers of both engineering and non-engineering persuasions can access the Conception in all these different versions, depending on their interests. Finally, the concepts carried forward by the Conception appear in 1.6 and the EU research illustrations of HCI Engineering in 1.7.

As appropriate, a version is supported by citations (C) from the original Long and Dowell paper, which allows readers to check the derivation of the version from the original. (F) indicates footnotes.

1.1 General Conception of HCI Discipline

The General Conception of the HCI Discipline is generalised from the General Engineering Conception of the HCI Discipline (1.2)

General Conception of HCI Discipline

1.2 General Conception of HCI Engineering Discipline

The General Conception of the HCI Engineering Discipline is generalised from the EU Conception of HCI EDngineering Discipline (1.3)

General Conception of HCI Engineering Discipline
1.3 EU Conception of HCI Engineering Discipline: a Summary

The EU Conception of the HCI Engineering Discipline is a summary of the complete version (see 1.4 and 1.5).

EU Conception of HCI Engineering Discipline: a Summary

1.4 Short version of Long and Dowell (1989)

Long and Dowell present conceptions for a number of possible HCI Disciplines, including Craft and Applied Science. For ease of access, however, only the complete EU Conception for the Engineering Discipline is presented here. The full paper is presented in 1.5.

Long and Dowell (1989) – HCI Engineering Discipline Short Version

1.5 Full Version of Long and Dowell (1989)

Here, the paper of Long and Dowell is presented in its entirety, including a complete version of the EU Conception of the HCI Engineering Discipline.

Long and Dowell (1989) – Full Version

1.6 Concepts Carried Forward

The concepts carried forward in this section are: Discipline; Engineering; and Human-Computer Interaction.

Discipline; Engineering; and Human-Computer Interaction

1.7 Illustrations of HCI Engineering Discipline from EU Research

1.7.1 Hill (2010) Diagnosing Co-ordination Problems in the Emergency Management Response to Disasters

Hill uses the HCI Engineering Conceptions to distinguish long-term HCI knowledge ( as principles) support for design from short-term knowledge of methods and models ( as design-oriented frameworks support) – see especially Section 1.1 Development of Design-oriented Frameworks and models for HCI.

Hill (2010) Diagnosing Co-ordination Problems in the Emergency Management Response to Disasters

1.7.2 Salter (2010) Applying the Conception of HCI Engineering to the Design of Economic Systems

Applying the Conception of HCI Engineering to the Design of Economic Systems, Salter uses the Conceptions to distinguish different types of HCI discipline and to apply them to the HCI engineering design of economic systems – see especially Section 1 Introduction

Salter (2010) Applying the Conception of HCI Engineering to the Design of Economic Systems

1.7.3 Stork and Long (1994) A Specific Planning and Design Problem in the Home

Stork and Long use the Discipline Conception to locate their research on the time-line of the development of the HCI discipline and the characteristics of such a discipline – see especially Introduction and Engineering Sections

Stork and Long (1994) A Specific Planning and Design Problem in the Home

The General Conception pre-supposes an associated HCI Engineering Discipline (F1) comprising: HCI Engineering knowledge, which distinguishes the interactive system of user and computer, the tasks it performs as desired and the goodness of that performance in terms of specific criteria (C1) The practice is supported by HCI Engineering knowledge seeking to solve design problems. Design problems here include specification, followed by implementation, of users interacting with computers (the interactive system) to perform tasks as desired in some domain of application. (C3)

The HCI Engineering Conception, then, is unequivocally one of design practice. (F2) HCI Engineering practice is the product of research practice and design practice itself. Such practice is public and ultimately formal. (F3) It may assume a number of forms, for example, codified, proceduralised, formal etc, as in methods, theories, principles etc. It may be maintained in a number of ways; for example, it may be expressed in journals, learning systems, procedures, tools, methods etc. HCI Engineering practice is, therefore, a necessary characteristic of the HCI Engineering Discipline. (C2)

The discipline of HCI Engineering, aims (in the longer term) to solve its general problem of design by the specification of designs before their implementation – as in ‘specify then implement’ design practices. (C6) (C7) (C9) The latter is made possible by the prescriptive nature of the knowledge supporting such practices – knowledge formulated as HCI Engineering methodological (and substantive) principles. (C4)

However, a pre-requisite for the formulation of any HCI Engineering principles is a Conception. The Conception, from which the HCI Engineering Conception is generalised, is a unitary view of the HCI Engineering design problem; its power lies in the coherence and completeness of its definition of the concepts, which can express that problem. (F4) (C8) (C12)

Engineering principles are articulated in terms of those self-same concepts. The latter include: user; computer; interaction; task; domain of application; system; and desired performance (for a full listing – see 2.2).

Thus, the Conception of HCI Engineering methodological (and substantive) principles assumes the possibility of a codified, general, and testable formulation of HCI Engineering discipline knowledge and practice. The latter might be prescriptively applied to designing humans and computers interacting to perform tasks as desired. Such principles would be unequivocally formal and operational. Indeed, their operational capability would derive directly from the formality of their concepts. (C4) HCI Engineering methodological (and substantive) concepts would be generalisable over classes of design problem solutions. Since the principles are operational, their application (expressed as design solutions) would necessarily be specifiable. They would also be testable and so their reliability and generality could also be specified. (C5)

In this way would the principles, expressed in terms of the Conception of Engineering design practice, be validated Such validated Engineering methodological (and substantive) design principles would offer a better guarantee (that is, more assurance – see 3.6.1)) of solving the HCI general design problem. Better, for example, than the experiential trial-and-error practice of craft HCI or the guidelines/heuristics and methods of Applied Science HCI. (C11)

HCI Engineering principles, following the Conception of Engineering design practice, can be methodological and substantive. Methodological principles prescribe the methods for solving the general HCI design problem. Methodological principles would assure complete specification of all necessary levels of design solution representation. Substantive principles prescribe the features and properties of HCI systems that constitute solutions to the HCI Engineering design problem. (C10)

The extent, to which HCI engineering principles might be realiseable in practice, in the longer term, remains to be seen and demonstrated. In the meantime, craft practice (F5) in whatever form – models, methods, heuristics, guidelines, experience, procedures etc cannot be other than recruited to solve HCI design problems both by researchers and practitioners. (C13)

Key concepts are shown in bold on their first appearance only.