HCI/E(U) Approach

Towards a Conception for an Engineering Discipline of Human Factors 

John Dowell and John Long Ergonomics Unit, University College London,  26, Bedford Way, London. WC1H 0AP. 

Abstract  This paper concerns one possible response of Human Factors to the need for better user-interactions of computer-based systems. The paper is in two parts. Part I examines the potential for Human Factors to formulate engineering principles. A basic pre-requisite for realising that potential is a conception of the general design problem addressed by Human Factors. The problem is expressed informally as: ‘to design human interactions with computers for effective working’. 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. Part II of the paper proposes such a conception and illustrates its concepts. It is offered as an initial and speculative step towards a conception for an engineering discipline of Human Factors.

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

Part 1. 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 …….. This paper is concerned to develop one possible response of HF to the need for better human-computer interactions. It is in two parts. Part I examines the potential for HF to formulate HF engineering principles for supporting its better response. Pre-requisite to the realisation of that potential, it concludes, is a conception of the general design problem it addresses.

Part II of the paper is a proposal for such a conception. …….. 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. This characterisation presupposes classes of general problem corresponding with types of discipline. For example, one class of general problem is that of the general design problem and includes the design of artefacts (of bridges, for example) and the design of ‘states of the world’ (of public administration, for example).

Engineering and craft disciplines address general design problems. Further consideration also suggests that any general problem has the necessary property of a scope, delimiting the province of concern of the associated discipline. Hence may disciplines also be distinguished from each other; for example, the engineering disciplines of Electrical and Mechanical Engineering are distinguished by their respective scopes of electrical and mechanical artefacts. ……..

The scope of the HCI general design problem includes: humans, both as individuals, as groups, and as social organisations; computers, both as programmable machines, stand-alone and networked, and as functionally embedded devices within machines; and work, both with regard to individuals and the organisations in which it occurs (Long, 1989). For example, the general design problem of HCI includes the problems of designing the effective use of navigation systems by aircrew on flight-decks, and the effective use of word-processors by secretaries in offices.

1.3. State of the Human Factors Art ……..

Figure 1 …….. ……..

1.4. Human Factors Engineering Principles

…….. The ‘design’ disciplines are ranged according to the ‘hardness’ or ‘softness’ of their respective general design problems. …….. However, here hard and soft problems will be generally distinguished by their determinism for the purpose, that is, by the need for design solutions to be determinate. 

A Classification Space for ‘Design ‘ Disciplines A discipline’s practices construct solutions to its general design problem. Consideration of disciplines indicates much variation in their use of specification as a practice in constructing solutions. …….. This variation, however, appears not to be dependent on variations in the hardness of the general design problems. Rather, disciplines appear to differ in the completeness with which they specify solutions to their respective general design problems before implementation occurs. …….. ’Specify then Implement’, therefore, and ‘implement and test’, would appear to represent the extremes of a dimension by which disciplines may be distinguished by their practices. It is a dimension of the completeness with which they specify design solutions.

Taken together, the dimension of problem hardness, characterising general design problems, and the dimension of specification completeness, characterising discipline practices, constitute a classification space for design disciplines such as Electrical Engineering and Graphic Design. The space is shown in Figure 2, including for illustrative purposes, the speculative location of SE. 1.5.

The Requirement for an Engineering Conception for Human Factors ……..  

Part 2. 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.1. Conception of the Human Factors General Design Problem.

The conception for the (super-ordinate) engineering discipline of HCI asserts a fundamental distinction between behavioural systems which perform work, and a world in which work originates, is performed and has its consequences. Specifically conceptualised are interactive worksystems consisting of human and computer behaviours together performing work. It is work evidenced in a world of physical and informational objects disclosed as domains of application. The distinction between worksystems and domains of application is represented schematically in Figure 3.  Effectiveness derives from the relationship of an interactive worksystem with its domain of application – it assimilates both the quality of the work performed by the worksystem, and the costs it incurs. Quality and cost are the primary constituents of the concept of performance through which effectiveness is expressed. The concern of an engineering HCI discipline would be the design of interactive worksystems for performance.

More precisely, its concern would be the design of behaviours constituting a worksystem {S} whose actual performance (PA) conformed with some desired performance (PD). And to design {S} would require the design of human behaviours {U} interacting with computer behaviours {C}. Hence, conception of the general design problem of an engineering discipline of HCI is expressed as: Specify then implement {U} and {C}, such that {U} interacting with {C} = {S}as PAPD where PD = fn. { QD ,KD } QD expresses the desired quality of the products of work within the given domain of application, KD expresses acceptable (i.e., desired) costs incurred by the worksystem, i.e., by both human and computer.

The problem, when expressed as one of to ‘specify then implement’ designs of interactive worksystems, is equivalent to the general design problems characteristic of other engineering disciplines (see Section 1.4.). The interactive worksystem can be distinguished as two separate, but interacting sub-systems, that is, a system of human behaviours interacting with a system of computer behaviours. The human behaviours may be treated as a behavioural system in their own right, but one interacting with the system of computer behaviours to perform work. It follows that the general design problem of HCI may be decomposed with regard to its scope (with respect to the human and computer behavioural sub-systems) giving two related problems. Decomposition with regard to the human behaviours gives the general design problem of the HF discipline as: Specify then implement {U} such that {U} interacting with {C} = {S}PaPd. The general design problem of HF then, is one of producing implementable specifications of human behaviours {U} which, interacting with computer behaviours {C}, are constituted within a worksystem {S} whose performance conforms with a desired performance (Pd).

The following sections elaborate the conceptualisation of human behaviours (the user, or users) with regard to the work they perform, the interactive worksystem in which they are constituted, and performance.

2.2 . Conception of Work and the User

The conception for HF identifies a world in which work originates, is performed and has its consequences. This section presents the concepts by which work and its relations with the user are expressed.

2.2.1 Objects and their attributes

Work occurs in a world consisting of objects and arises in the intersection of organisations and (computer) technology. Objects may be both abstract as well as physical, and are characterised by their attributes. Abstract attributes of objects are attributes of information and knowledge. Physical attributes are attributes of energy and matter. Letters (i.e., correspondence) are objects; their abstract attributes support the communication of messages etc; their physical attributes support the visual/verbal representation of information via language.

2.2.2 Attributes and levels of complexity

The different attributes of an object may emerge at different levels within a hierarchy of levels of complexity (see Checkland, 1981). For example, characters and their configuration on a page are physical attributes of the object ‘a letter’ which emerge at one level of complexity; the message of the letter is an abstract attribute which emerges at a higher level of complexity. Objects are described at different levels of description commensurate with their levels of complexity. However, at a high level of description, separate objects may no longer be differentiated. For example, the object ‘income tax return’ and the object ‘personal letter’ are both ‘correspondence’ objects at a higher level of description. Lower levels of description distinguish their respective attributes of content, intended correspondent etc. In this way, attributes of an object described at one level of description completely re-represent those described at a lower level.

2.2.3 Relations between attributes  

Attributes of objects are related, and in two ways. First, attributes at different levels of complexity are related. As indicated earlier, those at one level are completely subsumed in those at a higher level. In particular, abstract attributes will occur at higher levels of complexity than physical attributes and will subsume those lower level physical attributes. For example, the abstract attributes of an object ‘message’ concerning the representation of its content by language subsume the lower level physical attributes, such as the font of the characters expressing the language. As an alternative example, an  industrial process, such as a steel rolling process in a foundry, is an object whose abstract attributes will include the process’s efficiency. Efficiency subsumes physical attributes of the process, – its power consumption, rate of output, dimensions of the output (the rolled steel), etc – emerging at a lower level of complexity. Second, attributes of objects are related within levels of complexity. There is a dependency between the attributes of an object emerging within the same level of complexity. For example, the attributes of the industrial process of power consumption and rate of output emerge at the same level and are inter-dependent.

2.2.4 Attribute states and affordance

At any point or event in the history of an object, each of its attributes is conceptualised as having a state. Further, those states may change. For example, the content and characters (attributes) of a letter (object) may change state: the content with respect to meaning and grammar etc; its characters with respect to size and font etc. Objects exhibit an affordance for transformation, engendered by their attributes’ potential for state change (see Gibson, 1977). Affordance is generally pluralistic in the sense that there may be many, or even, infinite transformations of objects, according to the potential changes of state of their attributes. Attributes’ relations are such that state changes of one attribute may also manifest state changes in related attributes, whether within the same level of complexity, or across different levels of complexity. For example, changing the rate of output of an industrial process (lower level attribute) will change both its power consumption (same level attribute) and its efficiency (higher level attribute).

2.2.5 Organisations,domains (of application) and the requirement for attribute state changes A domain of application may be conceptualised as: ‘a class of affordance of a class of objects’. Accordingly, an object may be associated with a number of domains of application (‘domains’). The object ‘book’ may be associated with the domain of typesetting (state changes of its layout attributes) and with the domain of authorship (state changes of its textual content). In principle, a domain may have any level of generality, for example, the writing of letters and the writing of a particular sort of letter. Organisations are conceptualised as having domains as their operational province and of requiring the realisation of the affordance of objects. It is a requirement satisfied through work. Work is evidenced in the state changes of attributes by which an object is intentionally transformed: it produces transforms, that is, objects whose attributes have an intended state. For example, ‘completing a tax return’ and ‘writing to an acquaintance’, each have a ‘letter’ as their transform, where those letters are objects whose attributes (their content, format and status, for example) have an intended state. Further editing of those letters would produce additional state changes, and therein, new transforms.

2.2.6 Goals Organisations express their requirement for the transformation of objects through specifying goals. A product goal specifies a required transform – a required realisation of the affordance of an object. In expressing the required transformation of an object, a product goal will generally suppose necessary state changes of many attributes. The requirement of each attribute state change can be expressed as a task goal, deriving from the product goal. So for example, the product goal demanding transformation of a letter making its message more courteous, would be expressed by task goals possibly requiring state changes of semantic attributes of the propositional structure of the text, and of syntactic attributes of the grammatical structure.

Hence, a product goal can be re-expressed as a task goal structure, a hierarchical structure expressing the relations between task goals, for example, their sequences. In the case of the computer-controlled steel rolling process, the process is an object whose transformation is required by a foundry organisation and expressed by a product goal. For example, the product goal may specify the elimination of deviations of the process from a desired efficiency. As indicated earlier, efficiency will at least subsume the process’s attributes of power consumption, rate of output, dimensions of the output (the rolled steel), etc. As also indicated earlier, those attributes will be inter-dependent such that state changes of one will produce state changes in the others – for example, changes in rate of output will also change the power consumption and the efficiency of the process.

In this way, the product goal (of correcting deviations from the desired efficiency) supposes the related task goals (of setting power consumption, rate of output, dimensions of the output etc). Hence, the product goal can be expressed as a task goal structure and task goals within it will be assigned to the operator monitoring the process. 2.2.7 Quality The transformation of an object demanded by a product goal will generally be of a multiplicity of attribute state changes – both within and across levels of complexity. Consequently, there may be alternative transforms which would satisfy a product goal – letters with different styles, for example – where those different transforms exhibit differing compromises between attribute state changes of the object. By the same measure, there may also be transforms which will be at variance with the product goal. The concept of quality (Q) describes the variance of an actual transform with that specified by a product goal. It enables all possible outcomes of work to be equated and evaluated.

2.2.8 Work and the user

Conception of the domain then, is of objects, characterised by their attributes, and exhibiting an affordance arising from the potential changes of state of those attributes. By specifying product goals, organisations express their requirement for transforms – objects with specific attribute states. Transforms are produced through work, which occurs only in the conjunction of objects affording transformation and systems capable of producing a transformation. From product goals derive a structure of related task goals which can be assigned either to the human or to the computer (or both) within an associated worksystem. The task goals assigned to the human are those which motivate the human’s behaviours. The actual state changes (and therein transforms) which those behaviours produce may or may not be those specified by task and product goals, a difference expressed by the concept of quality.

Taken together, the concepts presented in this section support the HF conception’s expression of work as relating to the user. The following section presents the concepts expressing the interactive worksystem as relating to the user.

2.3. Conception of the Interactive Worksystem and the User.

The conception for HF identifies interactive worksystems consisting of human and computer behaviours together performing work. This section presents the concepts by which interactive worksystems and the user are expressed.

2.3.1 Interactive worksystems

Humans are able to conceptualise goals and their corresponding behaviours are said to be intentional (or purposeful). Computers, and machines more generally, are designed to achieve goals, and their corresponding behaviours are said to be intended (or purposive1). Human behaviour is teleological, machine behaviour is teleonomic (Checkland, 1981). An interactive worksystem (‘worksystem’) is a behavioural system distinguished by a boundary enclosing all human and computer behaviours whose purpose is to achieve and satisfy a common goal. For example, the behaviours of a secretary and wordprocessor whose purpose is to produce letters constitute a worksystem.

Critically, it is only by identifying that common goal that the boundary of the worksystem can be established: entities, and more so – humans, may exhibit a range of contiguous behaviours, and only by specifying the goals of concern, might the boundary of the worksystem enclosing all relevant behaviours be correctly identified. Worksystems transform objects by producing state changes in the abstract and physical attributes of those objects (see Section 2.2). The secretary and wordprocessor may transform the object ‘correspondence’ by changing both the attributes of its meaning and the attributes of its layout.

More generally, a worksystem may transform an object through state changes produced in related attributes. An operator monitoring a computer-controlled industrial process may change the efficiency of the process through changing its rate of output. The behaviours of the human and computer are conceptualised as behavioural sub-systems of the worksystem – sub-systems which interact1. The human behavioural sub-system is here more appropriately termed the user. Behaviour may be loosely understood as ‘what the human does’, in contrast with ‘what is done’ (i.e. attribute state changes in a domain). More precisely the user is conceptualised as: a system of distinct and related human behaviours, identifiable as the sequence of states of a person2 interacting with a computer to perform work, and corresponding with a purposeful (intentional) transformation of objects in a domain (see also Ashby, 1956). Although possible at many levels, the user must at least be expressed at a level commensurate with the level of description of the transformation of objects in the domain. For example, a secretary interacting with an electronic mailing facility is a user whose behaviours include receiving and replying to messages. An operator interacting with a computer-controlled milling machine is a user whose behaviours include planning the tool path to produce a component of specified geometry and tolerance.

2.3.2 The user as a system of mental and physical behaviours   The behaviours constituting a worksystem are both physical as well as abstract. Abstract behaviours are generally the acquisition, storage, and transformation of information. They represent and process information at least concerning: domain objects and their attributes, attribute relations and attribute states, and the transformations required by goals. Physical behaviours are related to, and express, abstract behaviours. Accordingly, the user is conceptualised as a system of both mental (abstract) and overt (physical) behaviours which extend a mutual influence – they are related. In particular, they are related within an assumed hierarchy of behaviour types (and their control) wherein mental behaviours generally determine, and are expressed by, overt behaviours. Mental behaviours may transform (abstract) domain objects represented in cognition, or express through overt behaviour plans for transforming domain objects.     So for example, the operator working in the control room of the foundry has the product goal required to maintain a desired condition of the computer-controlled steel rolling process. The operator attends to the computer (whose behaviours include the transmission of information about the process). Hence, the operator acquires a representation of the current condition of the process by collating the information displayed by the computer and assessing it by comparison with the condition specified by the product goal. The operator`s acquisition, collation and assessment are each distinct mental behaviours, conceptualised as representing and processing information. The operator reasons about the attribute state changes necessary to eliminate any discrepancy between current and desired conditions of the process, that is, the set of related changes which will produce the required transformation of the process. That decision is expressed in the set of instructions issued to the computer through overt behaviour – making keystrokes, for example.

The user is conceptualised as having cognitive, conative and affective aspects. The cognitive aspects of the user are those of their knowing, reasoning and remembering, etc; the conative aspects are those of their acting, trying and persevering, etc; and the affective aspects are those of their being patient, caring, and assured, etc. Both mental and overt human behaviours are conceptualised as having these three aspects.

2.3.3 Human-computer Interaction

Although the human and computer behaviours may be treated as separable sub-systems of the worksystem, those sub-systems extend a “mutual influence”, or interaction whose configuration principally determines the worksystem (Ashby, 1956). Interaction is conceptualised as: the mutual influence of the user (i.e., the human behaviours) and the computer behaviours associated within an interactive worksystem. Hence, the user {U} and computer behaviours {C} constituting a worksystem {S}, were expressed in the general design problem of HF (Section 2.1) as: {U} interacting with {C} = {S} Interaction of the human and computer behaviours is the fundamental determinant of the worksystem, rather than their individual behaviours per se. For example, the behaviours of an operator interact with the behaviours of a computer-controlled milling machine. The operator’s behaviours influence the behaviours of the machine, perhaps in the tool path program – the behaviours of the machine, perhaps the run-out of its tool path, influences the selection behaviour of the operator. The configuration of their interaction – the inspection that the machine allows the operator, the tool path control that the operator allows the machine – determines the worksystem that the operator and machine behaviours constitute in their planning and execution of the machining work.

The assignment of task goals then, to either the human or the computer delimits the user and therein configures the interaction. For example, replacement of a mis-spelled word required in a document is a product goal which can be expressed as a task goal structure of necessary and related attribute state changes. In particular, the text field for the correctly spelled word demands an attribute state change in the text spacing of the document. Specifying that state change may be a task goal assigned to the user, as in interaction with the behaviours of early text editor designs, or it may be a task goal assigned to the computer, as in interaction with the ‘wrap-round’ behaviours of contemporary wordprocessor designs. The assignment of the task goal of specification configures the interaction of the human and computer behaviours in each case; it delimits the user.

2.3.4 On-line and off-line behaviours

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; offline behaviours are associated with non-computer representations of the domain, or the domain itself. As an illustration of the distinction, consider the example of an interactive worksystem consisting of behaviours of a secretary and a wordprocessor and required to produce a paper-based copy of a dictated letter stored on audio tape. The product goal of the worksystem here requires the transformation of the physical representation of the letter from one medium to another, that is, from tape to paper. From the product goal derives the task goals relating to required attribute state changes of the letter. Certain of those task goals will be assigned to the secretary. The secretary’s off-line behaviours include listening to, and assimilating the dictated letter, so acquiring a representation of the domain directly. By contrast, the secretary’s on-line behaviours include specifying the represention by the computer of the transposed content of the letter in a desired visual/verbal format of stored physical symbols. On-line and off-line human behaviours are a particular case of the ‘internal’ interactions between a human’s behaviours as, for example, when the secretary’s typing interacts with memorisations of successive segments of the dictated letter.

2.3.5 Human structures and behaviour

Conceptualisation of the user as a system of human behaviours needs to be extended to the structures supporting behaviour. Whereas human behaviours may be loosely understood as ‘what the human does’, the structures supporting them can be understood as ‘how they are able to do what they do’ (see Marr, 1982; Wilden, 1980). There is a one to many mapping between a human`s structures and the behaviours they might support: the structures may support many different behaviours. In co-extensively enabling behaviours at each level, structures must exist at commensurate levels. The human structural architecture is both physical and mental, providing the capability for a human’s overt and mental behaviours. It provides a represention of domain information as symbols (physical and abstract) and concepts, and the processes available for the transformation of those representations. It provides an abstract structure for expressing information as mental behaviour. It provides a physical structure for expressing information as physical behaviour. Physical human structure is neural, bio-mechanical and physiological. Mental structure consists of representational schemes and processes. Corresponding with the behaviours it supports and enables, human structure has cognitive, conative and affective aspects. The cognitive aspects of human structures include information and knowledge – that is, symbolic and conceptual representations – of the domain, of the computer and of the person themselves, and it includes the ability to reason. The conative aspects of human structures motivate the implementation of behaviour and its perseverence in pursuing task goals. The affective aspects of human structures include the personality and temperament which respond to and supports behaviour.

To illustrate the conceptualisation of mental structure, consider the example of structure supporting an operator’s behaviours in the foundry control room. Physical structure supports perception of the steel rolling process and executing corrective control actions to the process through the computer input devices. Mental structures support the acquisition, memorisation and transformation of information about the steel rolling process. The knowledge which the operator has of the process and of the computer supports the collation, assessment and reasoning about corrective control actions to be executed. The limits of human structure determine the limits of the behaviours they might support. Such structural limits include those of: intellectual ability; knowledge of the domain and the computer; memory and attentional capacities; patience; perseverence; dexterity; and visual acuity etc. The structural limits on behaviour may become particularly apparent when one part of the structure ( channel capacity, perhaps) is required to support concurrent behaviours, perhaps simultaneous visual attending and reasoning behaviours. The user then, is ‘resource’ limited by the co-extensive human structure. The behavioural limits of the human determined by structure are not only difficult to define with any kind of completeness, they will also be variable because that structure can change, and in a number of respects. A person may have self-determined changes in response to the domain – as expressed in learning phenomena, acquiring new knowledge of the domain, of the computer, and indeed of themselves, to better support behaviour.

Also, human structure degrades with the expenditure of resources in behaviour, as evidenced in the phenomena of mental and physical fatigue. It may also change in response to motivating or de-motivating influences of the organisation which maintains the worksystem. It must be emphasised that the structure supporting the user is independent of the structure supporting the computer behaviours. Neither structure can make any incursion into the other, and neither can directly support the behaviours of the other. (Indeed this separability of structures is a pre-condition for expressing the worksystem as two interacting behavioural sub-systems.) Although the structures may change in response to each other, they are not, unlike the behaviours they support, interactive; they are not included within the worksystem. The combination of structures of both human and computer supporting their interacting behaviours is conceptualised as the user interface .

2.3.6 Resource costs of the user Work performed by interactive worksystems always incurs resource costs. Given the separability of the human and the computer behaviours, certain resource costs are associated directly with the user and distinguished as structural human costs and behavioural human costs. Structural human costs are the costs of the human structures co-extensive with the user. Such costs are incurred in developing and maintaining human skills and knowledge. More specifically, structural human costs are incurred in training and educating people, so developing in them the structures which will enable their behaviours necessary for effective working. Training and educating may augment or modify existing structures, provide the person with entirely novel structures, or perhaps even reduce existing structures. Structural human costs will be incurred in each case and will frequently be borne by the organisation. An example of structural human costs might be the costs of training a secretary in the particular style of layout required for an organisation’s correspondence with its clients, and in the operation of the computer by which that layout style can be created.

Structural human costs may be differentiated as cognitive, conative and affective structural costs of the user. Cognitive structural costs express the costs of developing the knowledge and reasoning abilities of people and their ability for formulating and expressing novel plans in their overt behaviour – as necessary for effective working. Conative structural costs express the costs of developing the activity, stamina and persistence of people as necessary for effective working. Affective structural costs express the costs of developing in people their patience, care and assurance as necessary as necessary for effective working. Behavioural human costs are the resource costs incurred by the user (i.e by human behaviours) in recruiting human structures to perform work. They are both physical and mental resource costs. Physical behavioural costs are the costs of physical behaviours, for example, the costs of making keystrokes on a keyboard and of attending to a screen display; they may be expressed without differentiation as physical workload. Mental behavioural costs are the costs of mental behaviours, for example, the costs of knowing, reasoning, and deciding; they may be expressed without differentiation as mental workload. Mental behavioural costs are ultimately manifest as physical behavioural costs.

When differentiated, mental and physical behavioural costs are conceptualised as the cognitive, conative and affective behavioural costs of the user. Cognitive behavioural costs relate to both the mental representing and processing of information, and the demands made on the individual`s extant knowledge, as well as the physical expression thereof in the formulation and expression of a novel plan. Conative behavioural costs relate to the repeated mental and physical actions and effort required by the formulation and expression of the novel plan. Affective behavioural costs relate to the emotional aspects of the mental and physical behaviours required in the formulation and expression of the novel plan. Behavioural human costs are evidenced in human fatigue, stress and frustration; they are costs borne directly by the individual.

2.4. Conception of Performance of the Interactive Worksystem and the User. In asserting the general design problem of HF (Section 2.1.), it was reasoned that: “Effectiveness derives from the relationship of an interactive worksystemwith its domain of application – it assimilates both the quality of the work performed by the worksystem, and the costs incurred by it. Quality and cost are the primary constituents of the concept of performance through which effectiveness is expressed. ” This statement followed from the distinction between interactive worksystems performing work, and the work they perform. Subsequent elaboration upon this distinction enables reconsideration of the concept of performance, and examination of its central importance within the conception for HF. Because the factors which constitute this engineering concept of performance (i.e the quality and costs of work) are determined by behaviour, a concordance is assumed between the behaviours of worksystems and their performance: behaviour determines performance (see Ashby, 1956; Rouse, 1980).

The quality of work performed by interactive worksystems is conceptualised as the actual transformation of objects with regard to their transformation demanded by product goals. The costs of work are conceptualised as the resource costs incurred by the worksystem, and are separately attributed to the human and computer. Specifically, the resource costs incurred by the human are differentiated as: structural human costs – the costs of establishing and maintaining the structure supporting behaviour; and behavioural human costs – the costs of the behaviour recruiting structure to its own support. Structural and behavioural human costs were further differentiated as cognitive, conative and affective costs. A desired performance of an interactive worksystem may be conceptualised. Such a desired performance might either be absolute, or relative as in a comparative performance to be matched or improved upon. Accordingly, criteria expressing desired performance, may either specify categorical gross resource costs and quality, or they may specify critical instances of those factors to be matched or improved upon. Discriminating the user’s performance within the performance of the interactive worksystem would require the separate assimilation of human resource costs and their achievement of desired attribute state changes demanded by their assigned task goals.

Further assertions concerning the user arise from the conceptualisation of worksystem performance.

First, the conception of performance is able to distinguish the quality of the transform from the effectiveness of the worksystems which produce them. This distinction is essential as two worksystems might be capable of producing the same transform, yet if one were to incur a greater resource cost than the other, its effectiveness would be the lesser of the two systems.

Second, given the concordance of behaviour with performance, optimal human (and equally, computer) behaviours may be conceived as those which incur a minimum of resource costs in producing a given transform. Optimal human behaviour would minimise the resource costs incurred in producing a transform of given quality (Q). However, that optimality may only be categorically determined with regard to worksystem performance, and the best performance of a worksystem may still be at variance with the performance desired of it (Pd). To be more specific, it is not sufficient for human behaviours simply to be error-free. Although the elimination of errorful human behaviours may contribute to the best performance possible of a given worksystem, that performance may still be less than desired performance.- See Section 1.4. Where the possibility for expressing, by an absolute value, the desired performance of a system or artifact is associated with the hardness of the design problem. Conversely, although human behaviours may be errorful, a worksystem may still support a desired performance.

Third, the common measures of human ‘performance’ – errors and time, are related in this conceptualisation of performance. Errors are behaviours which increase resource costs incurred in producing a given transform, or which reduce the quality of transform, or both. The duration of human behaviours may (very generally) be associated with increases in behavioural user costs.

Fourth, structural and behavioural human costs may be traded-off in performance. More sophisticated human structures supporting the user, that is, the knowledge and skills of experienced and trained people, will incur high (structural) costs to develop, but enable more efficient behaviours – and therein, reduced behavioural costs.

Fifth, resource costs incurred by the human and the computer may be traded-off in performance. A user can sustain a level of performance of the worksystem by optimising behaviours to compensate for the poor behaviours of the computer (and vice versa), i.e., behavioural costs of the user and computer are traded-off. This is of particular concern for HF as the ability of humans to adapt their behaviours to compensate for poor computer-based systems often obscures the low effectiveness of worksystems.

This completes the conception for HF. From the initial assertion of the general design problem of HF, the concepts that were invoked in its formal expression have subsequently been defined and elaborated, and their coherence established.

2.5. Conclusions and the Prospect for Human Factors Engineering Principles

A conception for HF is a pre-requisite for the formulation of HF engineering principles. It is the concepts and their relations which express the HF general design problem and which would be embodied in HF engineering principles. The form of a conception for HF was proposed in Part II. Originating in a conception for an engineering discipline of HCI (Dowell and Long, 1988a), the conception for HF is postulated as appropriate for supporting the formulation of HF engineering principles. The conception for HF is a broad view of the HF general design problem. Instances of the general design problem may include the development of a worksystem, or the utilisation of a worksystem within an organisation. Developing worksystems which are effective, and maintaining the effectiveness of worksystems within a changing organisational environment, are both expressed within the problem.

References  

See complete version of the paper in 2.5.

1.6.1 Discipline

The general concept of a discipline (F1) comprises: discipline knowledge (C3); practices (C4); and a general problem (C5), having a particular scope.(F2) (C1) (C2) The knowledge supports practices, seeking solutions to the general discipline problem, expressed in terms of its particular scope. (C6) (C7)

1.6.2 Engineering

The general concept of a discipline of Engineering (F1) comprises: engineering knowledge, as principles (F2) (C2); their application to practices, seeking the diagnosis of, and the solution to, the general engineering problem of the design of particular systems or artefacts. (C1) This concept holds for any engineering approach to a discipline of HCI.

1.6.3 Human-Computer Interaction

The general concept of a discipline of HCI (C2) comprises: HCI knowledge; its application to practices, seeking solution to the general HCI problem (C4) of design, having the particular scope of people using (F1) computers to do something (F2) as wanted. (F3) (C1) (C3)

The HCI/E is grounded in a Conception of the HCI Engineering Discipline (Long and Dowell (1989) – see Section 1) and of the HCI Engineering Design Problem (Dowell and Long (1989) – see Section 2) – both products of the research. Unlike these two conceptions, however, the HCI/E Conception of Engineering Design Practice has no single paper dedicated to its exposure. Rather, it appears throughout the Discipline and Design Problem conception papers. For this reason, 4.5 cites both papers in full, which together present the complete HCI/E Conception of Engineering Design Practice.

To make the Conception more accessible to a wide range of researchers: a complete expression appears in short versions of the Discipline and Design Problem papers (4.4); a summary version in 4.3; a generalised Engineering version in 4.2; and finally, a generalised HCI version in 4.1. Finally, the concepts carried forward by the Conception appear in 4.6 and the EU/UCL research illustrations of HCI Engineering in 4.7.

The (C) numbers in brackets refer to the citations from the original Dowell and Long and Long and Dowell (1989) papers, associated with the claim, which precedes the number – see also EU/UCL Citations 3.3. This referencing allows the reader to check the summary’s derivation from the original papers. The (F) numbers refer to footnotes.

4.1 General Conception of HCI Design Practice

The General Conception of HCI Design Practice is generalised from the General Conception of HCI Engineering Design Practice

General Conception of HCI Design Practice

4.2 General Conception of HCI Engineering Design Practice

The General Conception of HCI Engineering Design Practice is generalised from the HCI/E Conception of HCI Design Practice

General Conception of HCI Engineering Design Practice

4.3. HCI/E Conception of Engineering Design Practice: a Summary

The HCI/E Conception of HCI Engineering Design Practice is a summary of the full version – see 4.4 and 4.5.

HCI/E Conception of HCI Engineering Design Practice: a Summary

4.4 Short Versions of Long and Dowell (1989) and Dowell and Long (1989)

These two papers together expose the Conceptions of HCI Design Practice. Short versions of the papers, relevant only to the topic of HCI Design Practice are presented here. Full papers can be accessed via 4.5.

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

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

4.5 Full Versions of Long and Dowell (1989) and Dowell and Long (1989)

Here, the two papers are presented in their entirety, including a complete version of the HCI/E Conception of HCI Engineering Design Practice.

Long and Dowell (1989)

Dowell and Long (1989)

4.6 Concepts Carried Forward

The concepts carried forward in this section are: Design; Practice; and Design Practice.

Design; Practice; and Design Practice

4.7 Illustrations of HCI Engineering Design Practice from EU/UCL Research

4.7.1 Timmer and Long (2002) Expressing the Effectiveness of Planning Horizons

This paper uses the HCI/E Conception of Design Practice to describe a method that enables the expression of: a) the plans of a process operator, and how far into the future those plans extend; and b) an assessment of how adequate those plans are, for ensuring that work goals are attained. The illustration occurs throughout the paper.

Timmer and Long (2002) Expressing the Effectiveness of Planning Horizons

4.7.2 Stork, Middlemass and Long (1995) Applying a Structured Method for Usability Engineering to Domestic Energy Management User Requirements: a Successful Case-Study

Stork et al use the HCI/E Conception of Design Practice to report a case-study application of (the) MUSE (Design Method) to a set of domestic energy management user requirements to produce an artefact – see especially Section 4 The Application of MUSE to the User Requirements.

Stork, Middlemass and Long (1995) Applying a Structured Method for Usability Engineering to Domestic Energy Management User Requirements: a Successful Case-Study

4.7.3 Denley and Long (2010) Dialectic Approach to Multidisciplinary Practice in Requirements Engineering

Denley and Long use the HCI/E Conception of Design Practice to develop an approach that supports multidisciplinary practice in requirements engineering – see especially Section 3 Dialectic Approach to Supporting Multidisciplinary Practice by Practitioner.

Denley and Long (2010) Dialectic Approach to Multidisciplinary Practice in Requirements Engineering

Short Version

Conceptions of the Discipline of HCI: Craft, Applied Science, and Engineering 

John Long and John Dowell 

Ergonomics Unit, University College London,  26 Bedford Way, London. WC1H 0AP.  L.

Published in: People and Computers V. Sutcliffe A. and Macaulay (ed.s). Cambridge University Press, Cambridge. Proceedings of the Fifth Conference of the BCS HCI SIG, Nottingham 5-8 September 1989.

……..First, consideration of disciplines in general suggests their complete definition can be summarised as: ‘knowledge, practices and a general problem having a particular scope, where knowledge supports practices seeking solutions to the general problem’……….

Contents  1. Introduction 2. A Framework for Conceptions of the HCI Discipline 3. Three Conceptions of the Discipline of HCI 4. Summary and Conclusions

1. Introduction 

The main theme of HCI ’89 is ‘the theory and practice of HCI’. …….. For example, what is HCI? What is HCI practice? What theory supports HCI practice? How well does HCI theory support HCI practice? 1.1. Alternative Interpretations of the Theme …….. Some would claim HCI theory as explanatory laws, others as design principles. Some would claim HCI theory as directly supporting HCI practice, others as indirectly providing support. Some would claim HCI theory as effectively supporting HCI practice, whilst others may claim such support as non-existent. …….. Answers to different questions may also be mutually exclusive; for example, HCI as engineering would likely exclude HCI theory as explanatory laws, and HCI practice as ‘trial and error’. And moreover, answers to some questions may constrain the answers to other questions; for example, types of HCI theory, perhaps design principles, may constrain the type of practice, perhaps as ‘specify and implement’.

1.2. Alternative Conceptions of HCI: the Requirement for a Framework

1.3. Aims .

2. A Framework for Conceptions of the HCI Discipline 

2.1. On the Nature of Disciplines Most definitions assume three primary characteristics of disciplines: knowledge; practice; and a general problem. All definitions of disciplines make reference to discipline knowledge as the product of research or more generally of a field of study. Knowledge can be public (ultimately formal) or private (ultimately experiential). It may assume a number of forms; for example, it may be tacit, formal, experiential, codified – as in theories, laws and principles etc. It may also be maintained in a number of ways; for example, it may be expressed in journals, or learning systems, or it may only be embodied in procedures and tools. All disciplines would appear to have knowledge as a component (for example, scientific discipline knowledge, engineering discipline knowledge, medical discipline knowledge, etc). Knowledge, therefore, is a necessary characteristic of a discipline. …….. suggest the definition of a discipline as: ‘the use of knowledge to support practices seeking solutions to a general problem having a particular scope’.

2.2. Of Humans Interacting with Computers

2.3. The Framework for Conceptions of the HCI Discipline Hence, we may express a framework for conceptions of the discipline of HCI as: ‘the use of HCI knowledge to support practices seeking solutions to the general problem of HCI of designing humans and computers interacting to perform work effectively’.

3. Three Conceptions of the Discipline of HCI 

3.1. Conception of HCI as a Craft Discipline Craft disciplines solve the general problems they address by practices of implementation and evaluation. Their practices are supported by knowledge typically in the form of heuristics; heuristics are implicit (as in the procedures of good practice) and informal (as in the advice provided by one craftsperson to another). Craft knowledge is acquired by practice and example, and so is experiential; it is neither explicit nor formal.     ……..HCI craft knowledge, supporting practice, is maintained by practice itself.   ……..

The first explanation of this – and one that may at first appear paradoxical – is that the (public) knowledge possessed by HCI as a craft discipline is not operational. That is to say, because it is either implicit or informal, it cannot be directly applied by those who are not associated with the generation of the heuristics or exposed to their use. If the heuristics are implicit in practice, they can be applied by others only by means of example practice. If the heuristics are informal, they can be applied only with the help of guidance from a successful practitioner (or by additional, but unvalidated, reasoning by the user).   ……..If craft knowledge is not operational, then it is unlikely to be testable –……..there is no guarantee that practice applying HCI craft knowledge will have the consequences intended (guarantees cannot be provided if testing is precluded). There is no guarantee that its application to designing humans and computers interacting will result in their performing work effectively……….

Thus, with respect to the guarantee that knowledge applied by practice will solve the general HCI problem, the HCI craft discipline fails to be effective. If craft knowledge is not testable, then neither is it likely to be generalisable ……To be clear, if being operational demands that (public) discipline knowledge can be directly applied by others than those who generated the knowledge, then being general demands that the knowledge be guaranteed to be appropriate in instances other than those in which it was generated. Yet, the knowledge possessed by HCI as a craft discipline applies only to those problems already addressed by its practice, that is, in the instances in which it was generated. ……..

Thus, with respect to the generality of its knowledge, the HCI craft discipline fails to be effective. It (Craft) is ineffective because its knowledge is neither operational (except in practice itself), nor generalisable, nor guaranteed to achieve its intended effect – except as the continued success of its practice and its continued use by successful craftspeople.

3.2. Conception of HCI as an Applied Science Discipline The discipline of science uses scientific knowledge (in the form of theories, models, laws, truth propositions, hypotheses, etc.) to support the scientific practice ……..Scientific knowledge is explicit and formal, operational, testable and generalisable. It is therefore refutable (if not proveable; Popper [1959]). An applied science discipline is one which recruits scientific knowledge to the practice of solving its general problem – a design problem. HCI as an applied science discipline uses scientific knowledge  as an aid to addressing the general problem of designing humans and computers interacting to perform work effectively. …….

First, its science knowledge cannot be applied directly, not – as in the case of craft knowledge – because it is implicit or informal, but because the knowledge is not prescriptive; it is only explanatory and predictive. Its scope is not that of the general problem of design. Second, the guidelines based on the science knowledge, which are not predictive but prescriptive, are not defined, operationalised, tested or generalised with respect to desired effective performance. Their selection and application in any system would be a matter of heuristics (and so paradoxically of good practice). Third, the application of guidelines based on science knowledge does not guarantee the consequences intended, that is effective performance…….

HCI as an applied science discipline, however, differs in two important respects from HCI as a craft discipline. Science knowledge is explicit and formal, and so supports reasoning about the derivation of guidelines, their solution and application (although one might have to be a discipline specialist so to do). Second, science knowledge (of encoding specificity, for example) would be expected to be more correct, coherent and complete than ……..It (Applied Science) fails to be effective principally because its knowledge is not directly applicable and because the guidelines based on its knowledge are neither generalisable, nor guaranteed to achieve their intended effect.

3.3. Conception of HCI as an Engineering Discipline The discipline of engineering may characteristically solve its general problem (of design) by the specification of designs before their implementation. It is able to do so because of the prescriptive nature of its discipline knowledge supporting those practices – knowledge formulated as engineering principles. Further, its practices are characterised by their aim of ‘design for performance’.

Engineering principles may enable designs to be prescriptively specified for artefacts, or systems which when implemented, demonstrate a prescribed and assured performance. ……. The conception of HCI engineering principles assumes the possibility of a codified, general and testable formulation of HCI discipline knowledge which might be prescriptively applied to designing humans and computers interacting to perform work effectively. Such principles would be unequivocally formal and operational. Indeed their operational capability would derive directly from their formality, including the formality of their concepts –…….

…….. The abstracted form of those principles is visible. An HF engineering principle would take as input a performance requirement of the interactive worksystem, and a specified behaviour of the computer, and prescribe the necessary interacting  behaviours ……..

First, HCI engineering principles would be a generaliseable knowledge. Hence, application of principles to solving each new design problem could be direct and efficient with regard to costs incurred. The discipline would be effective. Second, engineering HCI principles would be operational, and so their application would be specifiable…….. Because they would be operational, they would be testable and their reliability and generality could be specified.

4. Summary and Conclusions  This paper has developed the Conference theme of ‘the theory and practice of HCI’. ……..

Although all conceptions of HCI as a discipline necessarily include the notion of practice (albeit of different types), the concept of theory is more readily associated with HCI as an applied science discipline, because scientific knowledge in its most correct, coherent and complete form is typically expressed as theories.

Craft knowledge is more typically expressed as heuristics. Engineering knowledge is more typically expressed as principles. ……. Although all three conceptions address the general problem of HCI, they differ concerning the knowledge recruited to solve the problem. Craft recruits heuristics; applied science recruits theories expressed as guidelines; and engineering recruits principles. …….

The different types of knowledge and the different types of practice have important consequences for the effectiveness of any discipline of HCI. Heuristics are easy to generate, but offer no guarantee that the design solution will exhibit the properties of performance desired. Scientific theories are difficult and costly to generate, and the guidelines derived from them (like heuristics) offer no final guarantee concerning performance. Engineering principles would offer guarantees, but are predicted to be difficult…….

…….suggest that the initial creation of discipline knowledge, whether heuristics, guidelines or principles, in all cases requires a reflexive cognitive act involving intuition and reason. Thus, contrary to common assumption, the craft, applied science, and engineering conceptions of the discipline of HCI are similarly reflexive with regard to the general design problem. The initial generation of albeit different discipline knowledges requires in each case the reflexive cognitive act of reason and intuition. ……..

However, there is a case for mutual support of conceptions and it is presented here as a final conclusion. The case is based on the claim made earlier that the creation of discipline knowledge of each conception of HCI requires a reflexive cognitive act of reason and intuition. If the claim is accepted, the reflexive cognitive act of one conception might be usefully but indirectly informed by the discipline knowledge of another.

References 

See full version of the paper, referenced in 3.5.

 The General Conception of the HCI design problem is expressed as: ‘to design people’s use of computers to do something as wanted.’ (C1) (C2) The General Conception of the HCI 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 Conception belongs to the class of general design problem. (C4)

The General Conception has the necessary property of a scope, delimiting the province of concern of the associated discipline of HCI. (C5) The scope includes: people, 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: the use of computers as wanted, both as concerns individuals and the organisations in which it occurs. (C6) (F1)

The Conception categorises HCI design problems as ‘easy’ or ‘difficult’. Easy and difficult problems are distinguished by the need for design solutions (as specified by HCI design practices) to be determinate. The design practices vary in the completeness of their specification before implementation. (C7) ‘Specify then implement’ design practices implicate more complete specification. ‘Implement and test’ design practices implicate less complete specification. (F2) Taken together, the dimension of problem difficulty, characterising HCI general design problems and the dimension of specification completeness, characterising HCI practices, constitute a classification space for all approaches to HCI.

The General Conception of the HCI design problem asserts a basic distinction between people-computer systems, which do things as wanted and a world in which these things originate, are done and have their consequences. (C10) ‘As wanted’ relates to the relationship of an interactive system with its use, assimilating both whether things are done, as wanted and the effort required for that doing. (F3)  The concern of the associated HCI discipline is to design the interactive system to do things, as wanted. The interactive system consists of people using computers and computers being used. According to the Conception, the general problem of HCI is to produce designs of people, which, interacting with computers, do something, as wanted. (C9)

The interactions take place in a world in which computers are used to do things, which change that world in some way. (C10) Computer use by people arises at the intersection of organisations and computer technology. Conceptualisation thereof may be both abstract and physical.  The abstract conceptualisation includes information and knowledge. The physical conceptualisation includes things. Computer use produces changes in the world over time. Following the General Conception, organisations have domains as their operational scope and require the changes brought about by computer use. It is a requirement satisfied by people using computers as wanted. (C11) An HCI design problem exists, when actual computer use is not as wanted.

The General Conception identifies interactive systems, consisting of people and computers doing something as wanted. (C14) People formulate goals which are intentional (or purposeful). Computers are designed to achieve goals and are said to be intended (or purposive).  Computer use is distinguished by a boundary, enclosing all people and computers, whose purpose is to achieve a common goal. (C13) Interactive systems achieve goals by doing something as wanted, that is, by producing change.

People and computers are conceptualised as sub-systems, which interact. (C14) Interaction may be loosely understood as ‘what the person and computer do’ in contrast with ‘what is done’, that is, the changes effected in the domain of application. In the General Conception, interactions are both physical and abstract. (C15) The latter process information. (C17) In the General Conception of the HCI design problem, doing things as wanted derives from the relationship of an interactive system with its domain of application. ‘As wanted’ assimilates both how well things are done by the system and the efforts required by the doing. (F4) These are the primary constituents of the concept of performance. ‘As wanted’ performance of an interactive system is conceptualised such that as wanted might be either absolute or relative, as in a comparative performance to be matched or improved upon. (C18) (F5)

Key concepts appear in bold on their first reference only.

The Conception of the HCI Engineering (F1) general design problem is expressed informally as: ‘to design human interactions with computers to perform tasks effectively.’ (C1) The Engineering 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 (note: engineering knowledge would be expressed in terms of these concepts). (C2) (F2)

The Engineering Conception of the HCI design problem presupposes an associated HCI Engineering Discipline having three primary characteristics: a general problem; practices providing solutions to that problem; and knowledge supporting those practices. (C3) The Engineering Conception 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 Engineering 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: tasks, both as concerns individuals and the organisations in which it occurs. (C6) (F3)

The Engineering 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) 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 Engineering approaches to HCI. (C9)

The Engineering Conception of the HCI design problem asserts a fundamental distinction between behavioural systems, which perform tasks and a world in which tasks originate, are performed and have their consequences. (C13) Effectiveness derives from the relationship of an interactive system with its domain of application, assimilating both how well the tasks are performed by the system and the resources they consume. (C14) (F4) The concern of the associated HCI Engineering discipline is to design the interactive system for performance. (C15). The interactive system 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 Engineering Conception, the general design problem of HCI is to produce implementable designs of human behaviours, which, interacting with computer behaviours, are constituted within a system, whose performance conforms with some desired performance. (C17) The interactions take place in a world in which tasks originate and have their consequences. (C18) These tasks arise at the intersection of organisations and computer technology and require representation for the purposes of design. The tasks may be both abstract and physical.  The abstract representation of tasks includes information and knowledge. The physical representation includes energy and matter.  Different representations of tasks emerge at different levels of description. Representations may be related in two ways – at different levels of description and within those levels.  Tasks involve changes over time. Thus, representations of tasks exhibit an affordance for transformation, expressed by the ‘potential’ for change effected by tasks. A domain of application is conceptualised as: ‘a class of affordance of a class of representations of tasks’.

Following the Engineering Conception, organisations are conceived as having domains as their operational scope and requiring the realisation of the affordance of representations of tasks. It is a requirement satisfied by the performance of tasks. (C19) Organisations express their requirement for the performance of tasks by formulating goals. A product goal specifies a required change, realised by means of the performance of tasks.  A variance exists, if the required change differs from that specified by a product goal. An HCI Engineering design problem exists, when actual task performance is not equal to desired performance. (F5) The Engineering Conception identifies interactive systems, consisting of human and computer behaviours together performing tasks. (C20) Humans formulate goals and their corresponding behaviours 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 system is a behavioural system distinguished by a boundary, enclosing all human and computer behaviours, whose purpose is to achieve a common goal. (C29) Interactive systems achieve goals by the performance of tasks, that is, by producing change. (C21)

The behaviors of the human and computer are conceptualised as behavioral sub-systems of the worksystem – sub-systems, which interact. (C22) Behavior may be loosely understood as ‘what the user does’ in contrast with ‘what is done’, that is, changes effected by tasks in the domain. More precisely, the user is conceptualised as a system of distinct, but related, human behaviours identifiable as the sequence of actions of a person interacting with a computer to perform tasks and corresponding with an intentional change in the domain. Although possible at many levels, the user must be at least conceptualised at a level commensurate with the level of description of the changes effected by tasks in the domain.

In the Engineering Conception, interactive system behaviours are both physical and abstract. (C23) The latter process information, concerning task changes in the domain, required by goals. Physical behaviours are related to abstract behaviors.  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. (C25)

Tasks performed by interactive systems consume its resources. Certain resources are associated both with the user and others with the computer. Such resources may be both mental and physical. (F6) In the Engineering Conception of the HCI design problem, effectiveness derives from the relationship of an interactive system with its domain. Effectiveness assimilates both how well the tasks are performed by the system and the resources consumed by it in so doing. These are the primary constituents of the concept of performance through which effectiveness is expressed. A desired performance of an interactive system is conceptualised such that desired performance might be either absolute or relative, as in a comparative performance to be matched or improved upon. (C27)

This concludes the expression of the Engineering Conception of the HCI 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.

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