HCI/E(U) Approach

Planning for Multiple Task Work – an Analysis of a Medical Reception Worksystem 150 150 John

Planning for Multiple Task Work – an Analysis of a Medical Reception Worksystem

Becky Hill, John Long, Walter Smith and Andy Whitefield

Ergonomics and HCI Unit, University College London,
26 Bedford Way, London WCIH OAP

 

ABSTRACT

.

This paper presents an investigation of interactive worksystem planning in the multiple task work domain of medical reception. In an observational study of a medical reception worksystem, three different types of plan were identified: the task plan, the procedure plan and the activity plan, These three types of plan were required for effective working in the domain of medical reception, because of the many similar concurrent tasks, the frequency of behaviour switching between tasks and the need for consistency within the worksystem. It is proposed, therefore, that to design effective interactive human-computer worksystems for the domain of medical reception (and possibly for other work domains of a similar nature), the designer must specify the three different types of plan and the relationships between them. The three types of plan in medical reception are discussed in the context of design issues such as the allocation of planning structures.

KEYWORDS

medical reception; planning and control; multiple tasks.

1 INTRODUCTION

This paper presents an observational study of the plans and planning behaviour of a medical reception worksystem. The study was carried out to develop further an existing design-oriented framework of the planning and control of multiple task work (PCMT) (Smith, Hill, Long and Whitefield, 1993 [5]). Section 1 provides some background information about medical reception (MR), and identifies it as a ‘PCMT design problem’. Section 2 describes the particular medical reception worksystem studied and how the observational data were collected and analysed. Section 3 contains the resulting model of PCMT in medical reception, while Section 4 presents more detailed accounts of the three dtifercnt types of plan used by the medical reception worksystem. The model is intended to have appropriate content to aid in reasoning about design, but is not yet in a suitable form for use within an existing design methodology. Section 5 identifies design issues addressed by the model.

 

1.1 Medical Reception (in the UK)

Informally, we can identify medical reception worksystems as those interactive systems, comprising combinations of people and office devices, which support the effective interaction between medical practitioners and their patients in medical general practices.

Jeffreys and Sachs (1983) [1] have described the emergence of medcal reception worksystems in the UK. In 1966, there was a boost to the employment of receptionists and secretaries, because the Family Doctors Charter was implemented, which gave provision for GPs to reclaim 70% of the salaries paid to their staff, Closely related to the increasing employment of receptionists was the growth in the use of appointment systems in general practice, as an appointment system could not be implemented without the employment of receptionist staff. General practices have begun in the last few years to be computerised, however the number has been small. The British government has more recently introduced a scheme of partial reimbursement of computer costs to increase computerisation.

Medical reception, therefore, presents an example of what might be described as an emerging Human Computer Interaction (HCI) design problem. Following the approach of Dowell and Long (1989) [2], the medical reception HCI design problem might be stated as: to specify the structures and behaviors of a human-computer interactive medical reception worksystem which will carry out work in the domain of medicalreception to a desired level of performance.

1.2 Medical Reception as an Instance of the Planning and Control of Multiple Task Work

There are many different issues to be addressed in the design of medical reception worksystems. The ‘set of issues addressed in this paper are those concerning PCMT. The general aim of the present research is to construct an appropriate model to aid designers reasoning about alternative solutions to this medical reception- PCMT design problem. The aim of the observational study reported here was to investigate the types of planning and plans used by medical reception worksystems to carry out work effectively.

The computerisation of worksystems typically increases the speed with which simple routine activities can be accomplished, e.g. searching for data, compiling revised/updated tables of information and their communication. The changing nature of routine activities has consequences for the management and supervision of work. Some of the most challenging human factors design issues for computerised systems, therefore, concern these higher-level behaviors which are here referred to as planning and control. The design of planning and control behaviors is particularly important where the worksystem carries out several ongoing tasks concurrently.

1.3 A Design-Oriented Framework of PCMT-MR

The notions of multiple task work and planning and control used in this paper are based on a previously constructed PCMT framework (Smith, Hill, Long and Whitefield, 1992a [3]; 1993 [5]). This section briefly outlines a PCMT-MR framework, the application of the PCMT framework to medical reception, in sufficient detail to understand the resulting model presented in Section 3.

The ‘PCMT-MR framework is based on Dowell and Long’s (1989) conception for an engineering discipline of HCI which expresses the HCI general design problem. The conception makes a fundamental distinction between an interactive worksystem, comprising one or more users and computers, and its domain of application, comprising the transformations carried out by the worksystem which constitute its work. The effectiveness with which work is carried out is expressed by the concept of performance which can be defined as a function of two factors: the quality of the product (i.e. how well the desired state of the domain is achieved compared with the state specified in the goal); and the incurred resource costs (i.e. the resources required by the worksystem in accomplishing the work).

The interactive worksystem, its domain of application and performance.

In medical reception, the worksystem is the receptionist plus devices such as an appointment book, telephone and prescription filing system, a wider notion of worksystem used in order to analyse to-be-computerised systems. The medical reception domain is conceptualised as the provision of support for medical cases, i.e. patients consulting with medical practitioners. Medical reception performance concerns the effectiveness with which support is provided for the medical cases.

Multiple task work.

The medical reception domain is an instance of multiple task work since support is given concurrently for multiple ongoing and temporally overlapping medical cases. A single medical reception task is the transformation of a single medical case object comprising a patient object, medical practitioner object(s), diagnosis object(s) and treatment object(s). This task might require a diverse range of behaviors spread over a long period of time, for example arranging a suitable appointment for patient P, notifying patient P of test results.

Planning and cotttrol behaviour.

It has been argued elsewhere (Smith et al, 1992b, [4]) that for an adequate

characterisation of the planning and control structures of worksystems which carry out work in complex and dynamic domains, it is necessary to make explicit the relationship between planning, control, perception and execution behaviors. Planning, in medical reception, entails specifying how medical case objects are to be supported by specifying either required transformations of medical case objects andlor required behaviors. Control entails deciding which behaviour to carry out next, such as arranging an appointment for patient P1 or preparing notes for P2. Perception and execution behaviors are, respectively, those whereby the medical reception worksystem acquires information about the medical case objects and those whereby it provides the required support.

Cognitive structures and allocation of function.

The PCMT-MR framework expresses the worksystem at two levels of description. Firstly, the framework describes the cognitive structures of the worksystem, expressed as four processes – perceiving, planning, controlling and executing – and two representations – knowledge-of-thetasks

and plans. This relationship is illustrated in more detail in the description of the PCMT-MR model (Section 3). Secondly, the framework describes the distribution of these cognitive structures across the physically separate user and devices of particular worksystems. The framework therefore allows the construction of alternative models of the distribution of cognitive structures across the user and devices, and thus, it supports reasoning about allocation of function.

2 AN OBSERVATIONAL STUDY OF MEDICAL RECEPTION

This Section describes an observational study of a medical reception worksystem. The aim of the observational study was to investigate the types of planning and plans used by medical reception worksystems to carry outwork effectively.

2.1 The Medical Reception Worksystem

The medical reception worksystem chosen for the study supported the provision of medical care in a general practice with four doctors and two nurses. This worksystem was physically divided into two different workstations, with two receptionists working from a ‘front desk’ and a ‘back desk’. The front desk workstation comprised a receptionist and devices, such as a telephone, and an appointments book. The back desk workstation comprised a second receptionist and devices, such as a prescription book, telephone and a computerised database. The front desk was positioned in front of a hatch through which the receptionist interacted with patients arriving at the surgery Under guidance of the receptionist patients passed from the hatch to a waiting room before seeing a medical practitioner.

2.2 The Nature of the Medical Reception Domain

As described in Section 1.3, the medical reception domain involves multiple task work. These tasks are characterised by:

(i) welldefined, routine sub-tasks;

(ii) variable durations, of between one day and several weeks

(iii) a high frequency of autonomous events; that is, task-relevant events which occur independently of any worksystem behaviour, for example: the arrival of a patient at the hatch or an incoming telephone-call.

 

Figure 1 The Model of PCMT-MR

worksystem structures:                                              domain of application:

representations and processes                                 multiple task work

 

2.3 Data Collection

Video-recordings were taken of the two workstations. Two video cameras were used simultaneously, one camera focused on the appointment-booking system of the front desk, while the other camera recorded the interactions within the whole reception area including both desks. Video-recordings were taken, both during and outside surgery hours, for one morning and afternoon in which time one pair of receptionists was relieved by another. At a later date, after initial analysis, an interview was carried out with one receptionist, to obtain clarification of selected details concerning the work. Only the analysis of video-recordings is reported here, although this analysis was assisted by the interview.

2.4 Data Analysis

Only the two videos recorded in the morning were analysed, because sufficient data were gathered from these two videos. The following analysis was carried out on both videos. From the 240 minutes of video-recording a sequence of between 30-90 minutes was selected for analysis. This selection was based mainly on the criteria that (i) the observed behaviors were interpretable, and (ii) the analysed period appeared to be busy in support of medical cases (and so was presumed to include behaviors of interest).

The first stage of the analysis was the documentation of behaviors and task-related events to a level of description considered to be at, or below, that necessary for the identitlcation of planning and control behaviors. This first description allowed the identification ofi (i) a low-level description of the physical domain objects (e.g., prescription) ; (ii) a low-level description of the physical worksystem devices (e.g. ‘phone 1; prescription box). Behaviours and events were documented in chronological sequence in a manner illustrated, as follows:

telephone 1                BUZZ

receptionist 1             PICK UP pencil

receptionist 1             PICK UP receiver ‘phone 1

receptionist 1              SELECT-LINE ‘phone 1

receptionist 1

(over telephone):                     Hello can I help?

event:         P PUT prescription in prescription box

receptionist 1

(over telephone)                        Dr S?

 

From this first analysis, it was possible to identify sequences of behaviors which were generic to particular activities carried out by the receptionist worksystem, for example appointment-booking.

3 A MODEL OF PCMT-MR

Section 1.3 described the conceptual framework of PCMT-MR constructed prior to carrying out the observational study outlined in Section 2. Sections 3 and 4 now describe the model of PCMT-MR constructed by using the observations of medical reception tasks and behaviors to instantiate the concepts of the framework.

The modelling of the observations of medical reception can be divided into two parts. Frost, a description of the medical reception worksystem and domain was generated, which is presented in this section. Second, a detailed description of the observed plans was constructed, presented in Section 4. Figure 1 provides a selective overview of the model of PCMT-MR which is now described.

 

al case

3.1 The Medical Reception Worksystem

The expression of the medical reception worksystem in Figure 1 shows cognitive structures taken from the PCMT-MR framework (described in Section 1.3). These cognitive structures are expressed at a generic level; that is, they depict the cognition of the medical reception works ystem prior to any allocation of function between the receptionist and devices. The relationships between the cognitive structures in Figure 1 embody the definitions of the planning and control behaviors described in Section 1.3. (For more detail see Smith et al, 1992b [4]). The plan representation structure in Figure 1 has been ‘opened-up’ to show the dtiferent types of plan identified in the study which are described in detail in Section 4.

3.2 The Medical Reception Domain

Following tbe PCMT-MR framework, the medical reception domain is expressed as those objects whose transformation constitutes the work of medical reception. Thus, the domain contains multiple medical case objects, each medical case object comprising a patient object, medical practitioner object(s), diagnosis object(s) and treatment object(s). Each task constitutes the transformation of a single medical case object with respect to the values of a number of attributes. In order to transform the medical case object attributes, the attributes of the medkxd case sub-objects (which are in a part-whole relationship with the medical case object), must be transformed. Tables 1-3 describe the transformation of the objects associated with the sub-task of appointment-booking. One of the attributes of a medical case object which must be transformed is appointment suitability for the patient. To transform the value of this attribute, the values of some of the attributes of the patient sub-object must be transformed.

The study revealed that the required transformation of each medical case object could be divided into a number of sub-transformations concerning particular sets of attributes. The division of the tasks into sub-transformations was consistent across all the tasks, and therefore the sub-transformations could be labelled generic sub-tasks. The generic sub-tasks identified in this study of medical reception were: appointment-booking, preparation of repeat prescriptions, registration of new patients, preparation (and updating) of medical notes for medical practitioners, and notification of patients test results.

Associated with the set of identified generic sub-tasks there were a corresponding set of activities. An activity is that set of behaviors which carry out a generic subtask.

The activities identified in medical reception were: booking of appointments, preparing repeat prescriptions, registering new patients, preparing (and updating) medical notes for medical practitioners, and notifying patients of test results. Due to limitation of space, only appointment-booking will be described in detail.

Figure 1 shows only those attributes which apply to the generic sub-task of appointment-booking. Attributes may be affordant or dispositional. Affordant attributes are transformed by tie worksystem; their transformation constitutes the work done. Dispositional attributes are relevant to the work but their transformation does not itself constitute work (often d@ositional attributes do not change their values). The attributes marked with an asterisk (*) in Figure 1 and Tables 1-3 are dispositional, for appointment-booking.

4 PLANS AND PLANNING IN THE MEDICAL

RECEPTION WORKSYSTEM

Following the PCMT-MR framework, plans are representations of how tasks are to be accomplished, specified to some level of completeness, some level of detail and in some format. In the study of medical reception, it was possible to identify three different plans employed by the worksystem. This section describes these three plans in turn and shows how they were interpreted as instances of three general types of plan: a task plan, an activity plan and a procedure plan.

4.1 The Task Plan

The receptionists used two appointment books (one for doctors and one for nurses) to represent and record details of patient appointments with the medical practitioners. Figure 2 schematically depicts the information represented in the appointment book for doctors: names of patients occupying particular appointment slots; whether or not the patient had entered the waiting room; slots which were still available; slots which the medical practitioners wanted to be left open; slots which could be used in emergencies. The receptionists also used what can be called ‘mental markers’; that is, they made mental notes of temporarily significant appoinixnent slots, such as the next available appointment of a particular medical practitioner or a slot which was in the process of being offered to a patient but not yet accepted.

~

From other perspectives, the appointment books might be regarded as plans for the whole practice. In the present analysis, the appointment books plus the associated mental markers were regarded as plans of the medical reception worksystem because they guided its behaviour, for example, they represented the patients whose medical notes needed to be prepared for the doctor, and the patients who should be let into the waiting-room. In terms of the PCMT-MR framework, the appointment books were plans which represented information about domain object attribute values. Specifically, they represented information about the patient object attributes of appointment-time and appointment-practitioner, and medical practitioner object attributes of availability (see Figure 1).

The information represented in the appointment books was specific to particulru objects, i.e. patients and medical practitioners, in the medical reception domain and was therefore specific to particular tasks, i.e. transformations of medical cases. The appointment books, with associated mental markers, were therefore identified as instances of a generic type of plan – the task plan. In general, task plans are specifications of either behaviors or domain object transformations relating to specific task instances. The appointment books were therefore paftial task plans.

4.2 The Activity Plan

As described in Section 3.2, the medical reception worksystem carried out a number of different activities, e.g. appointment-booking, preparing medical notes. From the video-recording and interview, it was possible to identify that the receptionists had a shared daily schedule of activities, mentally represented, to be carried out by the front and back desk receptionists. Figure 3 shows the activity schedule of the observed medical reception worksystem on the day of recording. This schedule was not rigidly adhered to as many activities, such as notifying of test results, were carried out in direct response to autonomous events such as patients telephoning the surgery.

 

The information represented in the activity schedule was specific to the carrying out of particular activities, as opposed to particular tasks. The activity schedule was therefore identified as an instance of a generic type of plan – the activity plan. In general, activity plans are specifications of sequences of activities to be carried out where each activity is a set of behaviors relating to a particular generic sub-task of the domain (see Section 3.2).

4.3 The Procedure Plan

Through analysis of the video-recordings, supported by interviews, it was possible to identify that the receptionist went through well-established sequences of behaviors when carrying out a particular activity. Thus the receptionists had mental routines, with in-built conditionals, for carrying out each activity, such as preparing medical notes, booking of appointments, preparing repeat prescriptions, etc. These mentrd routines, which represented information about behaviors and their contingencies for particular activities, were identified as instances of a generic type of plan – the procedure plan. In general, a procedure plan specifies an effective sequence of behaviors, and their contingencies, for carrying out a particular activity which relates to a generic sub-task of the domain (see Section 3.2).

As an illustration, the procedure plan for booking of appointments is now deseribed in detail. Figure 4 shows a flow diagram of behaviors, with associated conditionals, carried out in the activity of booking of appointments. The conditionals imply other behaviors; for example, the fmt conditional in Figure 4 implies that the controlling process must initiate the behaviour of reading the contents of Knowledge of tasks and, if  necessary, to perceive the patient’s requirement for appointment time (see Figure 1). Thus this procedure plan for booking of appointments describes the

 

behaviors of the worksystem in terms of both the

planning, control, perception and execution behaviors

and the transformation of the medical case objects that

constitute the generic sub-task of appointment-booking

(see Section 4.4).

4.4 The Relationship between the Different Plans

The following scenario of an appointment being booked

illustrates the relationship between the three plans shown

in Figure 1, and shows how they operated in combination

to guide the worksystem’s behaviour.

At the beginning of the day, the controlling process reads the activity plan – which specifies that receptionist R should carry out booking of appoinlxnents from the frontdesk during the morning (Figure 3) – and sets the parameters of the perceiving, executing and planning processes appropriately.

Later, an autonomous event occurs associated with thedomain: patient P telephones the surgery requiring an appointment. The controlling process then reads from the procedure plan for booking of appointments (Figure 4) which guides control decisions to activate the following sequence of behaviors:

– Perception:  perceiving the values of patient P’s attributes and updating knowledge-of-tasks: with the following attribute values:

appointment-requirements-who: own Dr (Dr X)

appointment-requirements-when: today

problem type: not emergency

– Planning: selecting and (mentally) marking a possible appointment slot in the task plan (i.e. the appointment book): Dr X, time t

– Execution: offering the selected appointment to patient P, i.e., attempt to transform Ps attribute values to: appointment-practitioner Dr X; appointment-time: time t

Perception: updating knowledge-of-tasks to register the acceptance of the appointment and patient Ps name.

– Planning: adding a representation of the agreed appointment to the task plan

– Perception: confirming the appointment details with patient P.

5 THE ROLE OF THE MODEL IN SUPPORTING THE DESIGN OF MEDICAL RECEPTION WORKSYSTEMS

The study of medical reception showed how the worksystem used three types of plan to carry out its work effectively. The relationship between the use of these different plan types and performance, i.e. the effectiveness with which the multiple task work was carried out will now be described along with their implications for the design of interactive worksystems.

– The Task Plan:  observed in the form of patient appointment books, supported the effective carrying out of the many ongoing tasks by:

1) giving guidance for the carrying out of behaviors relating to specific tasks, e.g. whether to admit patient PI to the waiting room, preparing medical notes for P2;

2) co-ordinating different tasks e.g. ensuring that appointments were unique for each task.

l The Activitv Plan: observed in the form of a (mentally represented) daily schedule of activities, supported the effective carrying out of tasks by:

1) supporting large-scale sharing of effort across separate tasks; e.g., when carrying out the activity of preparing repeat prescriptions, all of the medical notes for the patients requiring repeat prescriptions would be collected together at one time, thus reducing the behavioral costs to the worksystem;

2) co-ordinating the activities with the task-relevant changes in the domain; e.g., the activity of preparing repeat prescriptions was carried out during surgery hours, so that the prescriptions were ready for the doctors to verify and sign when the surgeries finished.

– Procedure Plan:  observed in the form of mental routines, supported the effective carrying out of repetitive sub-tasks which were generic across tasks (such as booking of appointments) by:

1) providing quick responses in a domain where there was a very high frequency of autonomous events (patients arriving, incoming telephone calls);

2) maintaining consistency which supported the rotation of the four receptionists around the two medical reception workstations;

3) supporting shared user behaviour, such that if one workstation was left unattended because a receptionist was busy the other receptionist on that shift could take over at the unattended workstation.

In computerizing, and therefore redesigning, the medical reception worksystem described in this paper, a designer should specify how the identified plans will be supported in the new design. For example it may be advisable to reallocate some of the mental plans to computerised devices, by:

i) having a partial procedure plan for booking of appointments device-based

ii) incorporating the currently used mental markers into a device-based appointment book. These two examples would enhance the effectiveness of the worksystem by aiding in the training of new receptionists and reducing their mental workload.

Therefore, in general, designs for medical reception

should Specify

(i) instances of all 3 plan types

(ii) the relationship between the different plans

(iii) the allocation of the plans across the receptionist and

the physically separate devices of the worksystem.

The generality of the plan types identified in the study reported here is uncertain at present. However, it might be suggested that the same issues will arise in the design of worksystems which carry out work in multiple task domains which are similar in nature to that of medical reception.

ACKNOWLEDGEMENT

The work reported herein was supported by the Joint Councils Initiative in Cognitive Science/IICI, grant no: SPG 8825634.

REFERENCES

[1] Jefferys, M. and Sachs, H. Rethinking General Practice: Dilemmas in Primary Health Care. London Tavistock 1983.

[2] Dowell J. and Long, J. Towards a conception for an engineering discipline of human factors. Ergonomics,32, (1989), 1513-1536.

[3] Smith, M.W., Hill, B., Long, J.B. and Whitefield, A.D. The Planning and Control of Multiple Task Work a Study of Secretarial Office Administration. In Proceedings of the Second Interdisciplinary Workshop on Mental Models, Cambridge, (1992a), 74- 83, in press.

[4] Smith, M.W., Hill, B., Long, J.B. and Whitefield, A.D. Modelling the Relationship Between Planning, Control, Perception and Execution Behaviors in Interactive Worksystems. In D.Diaper, M.Harrison and A.Monk (Eds) People and Computers VII; Proceedings of HCI ’92. Cambridge University Press, 1992b.

[51Smith, M.W., Hill, B., Long, J.B. and Whitefield, A.D. A Design-Oriented Framework of the Planning and Control of Multiple Task Work. Submitted for publication, 1993.

 

 

1.2 General Conception of HCI Engineering Discipline 150 150 John

1.2 General Conception of HCI Engineering Discipline

The General Conception of the HCI Engineering Discipline is generalised from the HCI/E Conception . The General Conception comprises 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.  The knowledge supports Practices, seeking to solve design problems.  Design here includes specification, followed by implementation and evaluation of users interacting with computers (the interactive system), to perform tasks as desired in some domain of application.

Key Concepts, Footnotes and Citations

The General Conception of the HCI Engineering Discipline is generalised from the HCI/E Conception (1.3). The General Conception comprises HCI Engineering Knowledge, which distinguishes the interactive system of user and computer, the tasks (F1) it performs as desired and the goodness of that performance in terms of specific criteria. (F2) (C1)  The knowledge supports HCI Engineering Practices, seeking to solve design problems. (C2) Design here includes specification, followed by implementation, of users interacting with computers ( the interactive system), to perform tasks as desired in some domain of application. (C3)

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

Footnotes

(F1) Task here is to be interpreted widely, as anything a user can do with a computer, either desired or undesired, well or badly.

(F2 ) Criteria, here, may include: time; errors; completeness etc.

Citations

Long and Dowell (1989)

(C1) ‘It (the Conception) dichotomises ‘interactive worksystems’ which perform work, and ‘domains of application’ in which work originates, is performed, and has its consequences’. (Page 24, Lines 39 and 40)

(C2) ‘The discipline of engineering includes the engineering practice addressing the general (engineering) problem of design.’  (Page 12, Lines 3-5)

(C3) ‘The discipline of engineering may characteristically solve its general problem (of design) by the specification of designs before their implementation.’ (Page 24, Lines 11-12).

 

3. HCI Engineering design Knowledge 150 150 John

3. HCI Engineering design Knowledge

The HCI/E(U) approach 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(U) Conception of Engineering Design Knowledge has no single paper dedicated to its exposure. Rather, it appears throughout the Discipline and Design Problem conception papers. For this reason, 3.5 presents both papers in full and other sections include citations from both papers, where appropriate. Together the two papers present the complete HCI/E(U) Conception of Engineering Design Knowledge.

To make the HCI/E(U) Conception of Engineering Design Knowledge more accessible to a wide range of researchers: a complete expression appears in short versions of the Discipline and Design Problem papers (3.4); a summary version in 3.3; a generalized Engineering version in 3.2; and finally, a generalised HCI version in 3.1. The latter also serves as an introduction to the Conception. Finally, the concepts carried forward by the Conception appear in 3.6 and the EU research illustrations of HCI Engineering in 3.7.

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

3.1 General Conception of HCI Design Knowledge

The General Conception of HCI Design Knowledge is generalised from the General Conception of HCI Engineering Design Knowledge (3.2).

General Conception of HCI Design Knowledge

3.2 General Conception of HCI Engineering Design Knowledge

The General Conception of HCI Engineering Design Knowledge is generalised from the HCI/E(U) Conception of HCI Design Knowledge (3.3)

General Conception of HCI Engineering Design Knowledge

3.3 HCI/E(U) Conception of HCI Engineering Design Knowledge: a Summary

The HCI/E(U) Conception of HCI Engineering Design is a summary of the the complete version – see 3.4 and 3.5.

HCI/E(U) Conception of HCI Engineering Design Knowledge

3.4 Short versions of Long and Dowell (1989) and Dowell and Long (1989)

These two papers together expose the Conception of HCI/E(U) Design Knowledge. Short versions of the papers, relevant only to the topic of HCI Design Knowledge, are presented here. Full papers can be found in:

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

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

3.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(U) Conception of HCI Engineering Design Knowledge.

Long and Dowell (1989)
Dowell and Long (1989)
3.6 Concepts Carried Forward

The concepts carried forward in this section are: Design; Knowledge; and Design KnowledgeDesign; Knowledge; and Design Knowledge

3.7 Illustrations of HCI Engineering Design Knowledge from EU Research

3.7.1 Cummaford (2000) Validating Effective Design Knowledge for Re-Use: HCI Engineering Design Principles

Cummaford here applies the HCI/E(U) Conception of Design Knowledge to develop a conception of (HCI) Engineering Design Principles, as a framework within which systematically to relate design knowledge to performance.Design knowledge is illustrated throughout the paper.Cummaford (2000) Validating Effective Design Knowledge for Re-Use: HCI Engineering Design Principles

3.7.2 Hill, Long, Smith and Whitefield (1993) Planning for Multiple Task Work – an Analysis of a Medical Reception Worksystem

Hill et al. here apply the HCI/E(U) Conception of Design Knowledge to model different types of plan observed in the work of medical reception – see especially Section 4 Plans and Planning in the Medical Reception Worksystem.Hill,Long, Smith and Whitefield (1995) Planning for Multiple Task Work – an Analysis of a Medical Reception Worksystem

3.7.3 Hill and Long (1996) A Preliminary Model of the Planning and Control of the Combined Response to Disaster

Hill and Long apply the HCI/E(U) Conception of Design Knowledge to develop a model of the combined response to disaster – see especially PCMT EMCR ModelHill and Long (1996) A Preliminary Model of the Planning and Control of the Combined Response to Disaster

[/expand]
1.4 Long and Dowell (1989) – HCI Engineering Discipline – Short Version 150 150 John

1.4 Long and Dowell (1989) – HCI Engineering Discipline – 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.

Pre-print: In: Sutcliffe, A. andMacaulay, L., (eds.) People and Computers V: Proceedings of the Fifth Conference of the British Computer Society.(pp. pp. 9-32). Cambridge University Press: Cambridge, UK.  http://discovery.ucl.ac.uk/15292/  .

….. 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’. Second, the scope of the general problem of HCI is defined by reference to humans, computers, and the work they perform. Third, by intersecting these two definitions, a framework is proposed ……

The framework expresses the essential characteristics of the HCI discipline, and can be summarised as: ‘the use of HCI knowledge to support practices seeking solutions to the general problem of HCI’……

Contents 1. Introduction 1.1. Alternative Interpretations of the Theme 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 2.2. Of Humans Interacting with Computers 2.3. The Framework for Conceptions of the HCI Discipline 3. Three Conceptions of the Discipline of HCI 3.1. Conception of HCI as a Craft Discipline 3.2. Conception of HCI as an Applied Science Discipline 3.3. Conception of HCI as an Engineering Discipline 4. Summary and Conclusions

1. Introduction 

1.1. Alternative Interpretations of the Theme……..

1.2. Alternative Conceptions of HCI: the Requirement for a Framework …….. A conception of the HCI discipline offers a unitary view; its value lies in the coherence and completeness with which it enables understanding of the discipline, how the discipline operates, and its effectiveness……..  A suitable structure for this purpose would be a framework identifying the essential characteristics of the HCI discipline……..

1.3. Aims …..  the aims of this paper are as follows: (i) to propose a framework for conceptions of the HCI discipline

2. A Framework for Conceptions of the HCI Discipline

Two prerequisites of a framework for conceptions of the HCI discipline are assumed. The first is a definition of disciplines appropriate for the expression of HCI. The second is a definition of the province of concern of the HCI discipline, which, whilst broad enough to include all disparate aspects, enables the discipline’s boundaries to be identified. Each of these prerequisites will be addressed in turn (Sections 2.1. and 2.2.). From them is derived a framework for conceptions of the HCI discipline (Section 2.3.). Source material for the framework is to be found in (Dowell & Long [1988]; Dowell & Long [manuscript submitted for publication]; and Long [1989]).

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…….. 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. Consideration of different disciplines suggests that practice is also a necessary characteristic of a discipline. Further, a discipline’s knowledge is used by its practices to solve a general (discipline) problem. …….. The discipline of engineering includes the engineering practice addressing the general (engineering) problem of design. …….. Practice, therefore, and the general (discipline) problem which it uses knowledge to solve, are also necessary characteristics of a discipline. Clearly, disciplines are here being distinguished by the general (discipline) problem they address. …….. Yet consideration also suggests those general (discipline) problems each have the necessary property of a scope. Decomposition of a general (discipline) problem with regard to its scope exposes (subsumed) general problems of particular scopes……. 

Two basic properties of disciplines are therefore concluded. One is the property of the scope of a general discipline problem. The other is the possibility of division of a discipline into sub-disciplines by decomposition of its general discipline problem. Taken together, the three necessary characteristics of a discipline (and the two basic properties additionally concluded), suggest the definition of a discipline as: ‘the use of knowledge to support practices seeking solutions to a general problem having a particular scope’. It is represented schematically in Figure 1. This definition will be used subsequently to express HCI.

2.2. Of Humans Interacting with Computers

The second prerequisite of a framework for conceptions of the HCI discipline is a definition of the scope of the general problem addressed by the discipline. In delimiting the province of concern of the HCI discipline, such a definition might assure the completeness of any one conception (see Section 1.2.). HCI concerns humans and computers interacting to perform work. ……. Further, since both organisations and individuals have requirements for the effectiveness with which work is performed, also implicated is the optimisation of all aspects of the interactions supporting effectiveness. Taken together, these implications suggest a definition of the scope of the general (discipline) problem of HCI. It is expressed, in summary, as ‘humans and computers interacting to perform work effectively’; it is represented schematically in Figure 2. This definition, in conjunction with the general definition of disciplines, will now enable expression of a framework for conceptions of the HCI discipline.  2.3. The Framework for Conceptions of the HCI Discipline ….. Given the definition of its scope (above), and the preceding definition of disciplines, the general problem addressed by the discipline of HCI is asserted as: ‘the design of humans and computers interacting to perform work effectively’. It is a general (discipline) problem of design : its ultimate product is designs. The practices of the HCI discipline seek solutions to this general problem, for example: in the construction of computer hardware and software; in the selection and training of humans to use computers; in aspects of the management of work, etc. HCI discipline knowledge supports the practices that provide such solutions. ….. 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…… Importantly, the framework supposes the nature of effectiveness of the HCI discipline itself. There are two apparent components of this effectiveness. The first is the success with which its practices solve the general problem of designing humans and computers interacting to perform work effectively. It may be understood to be synonymous with ‘product quality’. The second component of effectiveness of the discipline is the resource costs incurred in solving the general problem to a given degree of success – costs incurred by both the acquisition and application of knowledge. It may be understood to be synonymous with ‘production costs’. Figure 3. Framework for Conceptions of the Discipline of HCI ……

3. Three Conceptions of the Discipline of HCI A review of the literature was undertaken to identify alternative conceptions of HCI, that is, conceptions of the use of knowledge to support practices solving the general problem of the design of humans and computers interacting to perform work effectively. The review identified three such conceptions. They are HCI as a craft discipline; as an applied scientific discipline; and as an engineering discipline……..

3.1. Conception of HCI as a Craft Discipline …….. Figure 4 Conception of HCI as a Craft Discipline ……..

3.2. Conception of HCI as an Applied Science Discipline …….. Figure 5 Conception of HCI as an Applied Science Discipline ……..

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. And further, engineering disciplines may solve their general problem by exploiting a decompositional approach to design. Designs specified at a general level of description may be systematically decomposed until their specification is possible at a level of description of their complete implementation. Engineering principles may assure each level of specification as a representation of the previous level. This Section summarises the conception (schematically represented in Figure 6) and attempts to indicate the effectiveness of such a discipline. 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. …….. 

……..The concepts described enable the expression of the general problem addressed by an engineering discipline of HCI as: specify then implement user behaviour {U} and computer behaviour {C}, such that {U} interacting with {C} 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 behaviour of the user.

4. Summary and Conclusions

…….. The proposal made here is that the general problem of HCI is the design of humans and computers interacting to perform work effectively. The qualification of the general problem as ‘design’, and the addition to the scope of that problem of ‘…. to perform work effectively’, has important consequences for the different conceptions of HCI….. ….. The different types of knowledge and the different types of practice have important consequences for the effectiveness of any discipline of HCI……

References

For References – see the full version of the paper 1.5.

 

1.3 HCI/E Conception of HCI Engineering Discipline: a Summary 150 150 John

1.3 HCI/E Conception of HCI Engineering Discipline: a Summary

The HCI/E Conception of HCI as an Engineering discipline is a summary of the complete version (1.4 and 1.5).

The Conception comprises: HCI Engineering Knowledge as Principles, which distinguish the interactive worksystem, of user and computer, the work it performs and the effectiveness of that performance in terms of task quality and system resource costs. These Principles support HCI Engineering Practices seeking to diagnose design problems and to prescribe design solutions to those problems. Design here is characterised as ‘specify then implement’ designs of users interacting with computers (the interactive worksystem) to perform effective work in some domain of application.

Key concepts, Footnotes and Citations

The HCI/E Conception of the HCI Engineering Discipline comprises (C2): HCI Knowledge as Principles (F1), which distinguish the interactive worksystem, of user and computer, the work it performs and the effectiveness of that performance in terms of task quality and system resource costs. (C3) These Principles support HCI Practices seeking to diagnose design problems and to prescribe design solutions to those problems. (F2) (C1) Design here is characterised as ‘specify then implement’ designs of users interacting with computers (the interactive worksystem) to perform effective work in some domain of application. (F3) (C4)

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

 Footnotes

 (F1) No such Principles exist in the current research and practice of HCI. The HCI/E Conception and frameworks are intended to form the basis, on which such Principles might be constructed in the longer term. A start, however, has been made (Stork (1999) and Cummaford (2007). In the meantime, HCI/E research and practice recruits whatever HCI knowledge is available at present to solve design problems.

(F2) According to the HCI/E Conception, design problems have to be diagnosed (and specified) before they can be solved (and implemented).

(F3) The current absence of HCI Engineering Design Principles, requiring the use of different types of HCI knowledge – see (F1) above –   also requires, in the meantime,  they support different types of practice, for example, ‘trial-and- error; ‘specify and implement’; ‘prototype and test’ etc.

Citations

 Long and Dowell (1989)

(C1) ‘The  (discipline) framework expresses the essential characteristics of the HCI discipline, and can be summarised as: ‘the use of HCI knowledge to support practices seeking solutions to the general problem of HCI’.’ (Page 9, Lines 16-19).

(C2) ‘Two prerequisites of a framework for conceptions of the HCI discipline are assumed. The first is a definition of disciplines appropriate for the expression of HCI. The second is a definition of the province of concern of the HCI discipline which, whilst broad enough to include all disparate aspects, enables the discipline’s boundaries to be identified.’ (Page 11, Lines 18-21).

(C4) ‘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.’ (Page 24, Lines 11-14)

Dowell and Long (1989)

(C3) ‘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……..’ (Page 1518, Lines 20-22)

 

3. HCI Engineering Design Knowledge 150 150 John

3. HCI Engineering Design Knowledge

The HCI/E approach 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 Knowledge has no single paper dedicated to its exposure. Rather, it appears throughout the Discipline and Design Problem conception papers. For this reason, 3.5 presents both papers in full and other sections include citations from both papers, where appropriate. Together the two papers present the complete HCI/E Conception of HCI Engineering Design Knowledge.

To make the HCI/E Conception of Engineering Design Knowledge more accessible to a wide range of researchers: a complete expression appears in short versions of the Discipline and Design Problem papers (3.4); a summary version in 3.3; a generalised Engineering version in 3.2; and finally, a generalised HCI version in 3.1. The latter also serves as an introduction to the Conception. Finally, the concepts carried forward by the Conception appear in 3.6 and the EU/UCL research illustrations of HCI Engineering in 3.7.

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

3.1 General Conception of HCI Design Knowledge

The General Conception of HCI Design Knowledge is generalised from the General Conception of HCI Engineering Design Knowledge (3.2)

General Conception of HCI Design Knowledge

3.2 General Conception of HCI Engineering Design Knowledge

The General Conception of HCI Engineering Design Knowledge is generalised from the HCI/E Conception of HCI Design Knowledge (3.3)

General Conception of HCI Engineering Design Knowledge

3.3 HCI/E Conception of HCI Engineering Design Knowledge: a Summary

The HCI/E Conception of HCI Engineering Design is a summary of the complete version – see 3.4 and 3.5.

HCI/E Conception of HCI Engineering Design Knowledge

3.4 Short versions of Long and Dowell (1989) and Dowell and Long (1989)

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

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

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

3.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 Knowledge.

Long and Dowell (1989)

Dowell and Long (1989) 

3.6 Concepts Carried Forward

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

Design; Knowledge; and Design Knowledge

3.7 Illustrations of HCI Engineering Design Knowledge from EU/UCL Research

3.7.1 Cummaford (2000) Validating Effective Design Knowledge for Re-Use: HCI Engineering Design Principles

Cummaford here applies the HCI/E Conception of Design Knowledge to develop a conception of HCI Engineering Design Principles, as a framework within which systematically to relate design knowledge to performance.Design knowledge is illustrated throughout the paper.

Validating Effective Design Knowledge for Re-Use: HCI Engineering Design Principles

3.7.2 Hill, Long, Smith and Whitefield (1995) Planning for Multiple Task Work – an Analysis of a Medical Reception Worksystem

Hill et al. here apply the HCI/E Conception of Design Knowledge to model different types of plan observed in the work of medical reception – see especially Section 4 Plans and Planning in the Medical Reception Worksystem.

Hill, Long, Smith and Whitefield (1995) Planning for Multiple Task Work – an Analysis of a Medical Reception Worksystem

3.7.3 Hill and Long (1996) A Preliminary Model of the Planning and Control of the Combined Response to Disaster

Hill and Long apply the HCI/E Conception of Design Knowledge to develop a model of the combined response to disaster – see especially PCMT EMCR Model

Hill and Long (1996) A Preliminary Model of the Planning and Control of the Combined Response to Disaster

2.4 Dowell and Long (1989) – HCI Engineering Design Problem – Short Version 150 150 John

2.4 Dowell and Long (1989) – HCI Engineering Design Problem – Short Version

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 Discipline; Engineering; and Human-Computer Interaction 150 150 John

1.6 Discipline; Engineering; and Human-Computer Interaction

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)

Footnotes and Citations

Footnotes

(F1) A discipline here is to be distinguished from the community, which practises it.

(F2) The scope of a problem is the domain or range over which it operates.

Citations

Long and Dowell (1989)

(C1) ‘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’.’ (Page 9, Lines 9-14)

(C2) ‘Most definitions assume three primary characteristics of disciplines: knowledge; practice; and a general problem.’ (Page 11, Lines 27 and 28)

(C3) ‘All definitions of disciplines make reference to discipline knowledge as the product of research or more generally of a field of study……. Knowledge, therefore, is a necessary characteristic of a discipline.’ (Page 11, Lines 29 and 30)

(C4) ‘Consideration of different disciplines suggests that practice is also a necessary characteristic of a discipline.’ (Page 11, Line 38 and Page 12, Line 1)

(C5) ‘Further, a discipline’s knowledge is used by its practices to solve a general (discipline) problem……’ (Page 12, Lines 1 and 2)

(C6) ‘Clearly, disciplines are here being distinguished by the general (discipline) problem they address.’ (Page 12, Lines 8 and 9)

(C7) ‘Taken together, the three necessary characteristics of a discipline (and the two basic properties additionally concluded), suggest the definition of a discipline as: ‘the use of knowledge to support practices seeking solutions to a general problem having a particular scope’.’  (Page 12, Lines 26-32)

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.

Footnotes and Citations

Footnotes

(F1) Engineering here is to be contrasted, for example, with Science.

(F2) Although Principles are critical to engineering knowledge, in contrast to other disciplines, it comprises a wide range of different types of knowledge – models; methods; etc.

Citations

Long and Dowell (1989)

(C1)’The discipline of engineering includes the engineering practice addressing the general (engineering) problem of design.’  (Page 12, Lines 3-5)

(C2) ‘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.’ (Page 24, Lines 11-14)

 

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)

Footnotes and Citations

Footnotes

(F1) ‘Using’ here contrasts with simply ‘interacting.

(F2) ‘Something’ here is intentionally very general. The contrast is, again, with simply ‘interacting’ – see (F1).

(F3) ‘As wanted’ by, for example, the user; the client; the users’ organisation; or indeed all of them (and more).

Citations

Long and Dowell (1989)

(C1) ‘The  (discipline) framework expresses the essential characteristics of the HCI discipline, and can be summarised as: ‘the use of HCI knowledge to support practices seeking solutions to the general problem of HCI’.’ (Page 9, Lines 16-19).

(C2) ‘HCI concerns humans and computers interacting to perform work.’ (Page 13, Line 1)

(C3) ‘Taken together, these implications suggest a definition of the scope of the general (discipline) problem of HCI. It is expressed, in summary, as ‘humans and computers interacting to perform work effectively’.’ ( Page 13, Lines 10-12). (C4) … the general problem addressed by the discipline of HCI is asserted as: ‘the design of humans and computers interacting to perform work effectively’.  (Page 13, lines 19-21).

 

4. HCI Engineering Design Practice 150 150 John

4. HCI Engineering Design Practice

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

 

 

3.4 Long and Dowell (1989) – HCI Engineering Knowledge – Short Version 150 150 John

3.4 Long and Dowell (1989) – HCI Engineering Knowledge – Short Version

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.