HCI/E(U) Approach

1. HCI Engineering Discipline 150 150 John

1. HCI Engineering Discipline

The HCI/E approach is grounded in a Conception of an HCI Engineering discipline, itself a product of the research. The Conception was originally published in Long and Dowell (1989) and a full version is presented in 1.5. To make the Conception more accessible to a wide range of researchers: a complete expression appears in a shortened version of Long and Dowell in 1.4; a summary version in 1.3; a generalised HCI/E version in 1.2; and finally, a generalised HCI version in 1.1. The latter also serves as an introduction to the Conception. Finally, the concepts carried forward by the Conception appear in 1.6 and the EU/UCL research illustrations of HCI/E in 1.7.

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

1.1 General Conception of HCI Discipline

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

General Conception of HCI Discipline

1.2 General Conception of HCI Engineering Discipline

The General Conception of the HCI Engineering Discipline is generalised from the Conception of HCI/E Engineering Discipline (1.3)

General Conception of HCI Engineering Discipline

1.3 Conception for HCI Engineering Discipline: a Summary

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

Conception for HCI Engineering Discipline: a Summary

1.4 Short version of Long and Dowell (1989)

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

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

1.5 Full Version of Long and Dowell (1989)

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

Long and Dowell (1989) – Full Version

1.6 Concepts Carried Forward

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

Discipline; Engineering; and Human-Computer Interaction

1.7 Illustrations for an HCI Engineering Discipline from EU/UCL Research

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

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

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

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

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

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

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

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

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

 

4.3 EU Conception of HCI Engineering Design Practice: a Summary 150 150 John

4.3 EU Conception of HCI Engineering Design Practice: a Summary

The EU Conception of HCI Engineering Design Practice presupposes an associated HCI Engineering Discipline, comprising: HCI engineering knowledge (C2), which distinguishes the interactive system of user and computer, the work it performs and the effectiveness of that performance, in terms of task quality and system resource costs (C1). This HCI design practice is supported by HCI knowledge seeking to diagnose design problems and to prescribe design solutions to those problems. (C5) (15) The EU Conception of the HCI Engineering design problem is informally expressed as: to design human interactions with computers for effective working. (C16) (C24) (C25) The EU Conception, then, is unequivocally one of design practice. HCI Engineering practice, following the EU Conception, is supported by research. (3) (17) Such practice is public and ultimately formal. It may assume a number of forms, for example, codified, proceduralised, formal etc, as in methods, guidelines etc. (C28) (30) It may be maintained in a number of ways, for example, it may be expressed in journals, learning systems, procedures, tools etc. (C4) HCI Engineering practice is, therefore, a necessary characteristic of the EU HCI Engineering Discipline. (C15) The discipline of HCI Engineering, aims, following the EU Conception, (in the longer term (F1)) to solve its general problem of design by the specification of designs before their implementation – as in ‘specify then implement’ design practices. (C26) (C27) The latter is made possible by the prescriptive nature of the knowledge supporting such practices – knowledge formulated as HCI Engineering principles, both methodological and substantive. (C29) However, a pre-requisite for the formulation of any HCI Engineering principles is a Conception. (C2) (C7) The EU Conception is a unitary view of the HCI Engineering design problem; its power lies in the coherence and completeness of its definition of the concepts, which can express that problem. (C1) Engineering methodological (and substantive) principles are articulated in terms of those self-same concepts. The latter include: user; computer; interaction; work; work domain; worksystem; effectiveness; performance; task quality; system resource costs etc (see 2.5 for a complete presentation of the EU design problem concepts, which would be recruited to the formulation of EU-conceived engineering methodological (and substantive) principles. (C1) (F2) Thus, the EU Conception of HCI Engineering methodological (and substantive) principles assumes the possibility of a codified, general, and testable formulation of HCI Engineering discipline. (C4) (C28) The latter might be prescriptively applied to designing humans and computers interacting to perform work effectively. (1) Such principles would be unequivocally formal and operational. Indeed, their operational capability would derive directly from the formality of their concepts. (C6) EU HCI Engineering methodological (and substantive) concepts would be generalisable over classes of design problem solutions. Since the methodological (and substantive) principles are operational, their application (expressed as design solutions) would necessarily be specifiable. (C6) (C26) They would also be testable and so their reliability and generality could also be specified. (C28) (29) In this way would the methodological (and substantive) principles, expressed in terms of the EU Conception of Engineering design practice, be validated. Such validated Engineering design principles would offer a better guarantee (that is, more assurance) of solving the HCI general design problem. Better, for example, than the experiential trial-and-error knowledge of craft HCI (C6) (C13) (C14) (C19) (20) (C21) (C22) or the guidelines/heuristics and methods of Applied Science HCI (C3) (F3) HCI Engineering principles, following the EU Conception of Engineering design knowledge, can be substantive or methodological. Methodological principles prescribe the methods for solving the general HCI design problem. (1) Methodological principles would assure complete specification of all necessary levels of design solution representation. (C6) Substantive principles prescribe the features and properties of HCI systems that constitute solutions to the EU HCI Engineering design problem. (C6) The extent, to which HCI engineering methodological (and substantive) principles might be realisable in practice, in the longer term, remains to be seen and demonstrated. (C6) In the meantime, craft knowledge in whatever form – models, methods, heuristics, guidelines, experience, procedures etc cannot be other than recruited to solve HCI design problems both by researchers and practitioners (C18) (C19) (C20) (C21) (C22) (C23) (F4)

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

Footnotes and Citations

Footnotes

(F1) In the shorter term, to solve HCI design problems, either for research design practice or for design practice itself, any type of knowledge, for example, methods, guidelines etc might be used.

(F2) Or indeed to other types of Engineering knowledge, for example, models and frameworks, intended to support the diagnosis of design problems and the prescription of their design solutions.

(F3) Craft HCI would also include craft engineering HCI – see also (F1) and (F2).

(F4) See also (F1), (F2) and (F3).

Citations

Long and Dowell (1989)

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

(C2) ‘ 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.’ (Page 10, Lines 12-17)

(C3) ‘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.’ (Page 11, Lines 30-38)

(C4) ‘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.’ (Page 16, Lines 4-8)

(C5) ‘…….. 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).’ (Page 18, Lines 28-33)

(C6) ‘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.’ (Page 19, Lines 11 and 15-20)

(C7) ‘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])’. (Page 20, Lines 2-3 and 7-9)

(C8) ‘An applied science discipline is one which recruits scientific knowledge to the practice of solving its general problem – a design problem.’ (Page 20, Lines 16 and 17)

(C9) ‘ 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.’ (Page 23, Lines 20-23)

(C10) ‘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).’ (Page 23, Lines 25-28)

(C11) ‘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).’ (Page 23, Lines 36-38)

(C12) ‘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)

(C13) ‘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.’ (Page 24, Lines 28-31)

(C14) ‘First, HCI engineering principles would be a generaliseable knowledge. …….. 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.’ (Page 27, Lines 20-22 and 36-28)

(C15) ‘ 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.’ (Page 28, Lines 22-24)

Dowell and Long (1989)

(C16) ‘The paper ….. examines the potential for Human Factors to formulate engineering principles. ……… A conception would provide the set of related concepts which both expressed the general design problem more formally, and which might be embodied in engineering principles.’ (Page 1513, Lines 9 and 10)

(C17) ‘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.’ (Page 1514, Lines 23-27)

(C18) ‘Most definitions of disciplines assume three primary characteristics: a general problem; practices, providing solutions to that problem; and knowledge, supporting those practices.’ (Page 1514, Lines 43-45)

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

(C20) ‘Engineering principles can be substantive or methodological. Methodological Principles prescribe the methods for solving a general design problem optimally. ….. Methodological principles would assure each lower level of specification as being a complete representation of an immediately higher level. Substantive Principles prescribe the features and properties of artefacts, or systems that will constitute an optimal solution to a general design problem. (Page 1520, Lines 6-15)

(C21) ‘Such a conception ….. enables the formulation of engineering principles which embody and instantiate those concepts. ( Page 1520, Line 46 and Page 1521, Line 1)

(C22) ‘The extent to which HF engineering principles might be realiseable in practice remains to be seen. It is not supposed that the development of effective systems will never require craft skills in some form, and engineering principles are not seen to be incompatible with craft knowledge, particularly with respect to their instantiation. At a minimum, engineering principles might be expected to augment the craft knowledge of HF professionals. Yet the great potential of HF engineering principles for the effectiveness of the discipline demands serious consideration.’ (Page 1533, Lines 24-29)

2. HCI Engineering Design Problem 150 150 John

2. HCI Engineering Design Problem

The HCI/E approach is grounded in a Conception of an HCI Engineering design problem (and Solution), itself a product of the research. The Conception was originally published in Dowell and Long (1989) and a full version is presented in 2.5. To make the Conception more accessible to a wide range of researchers: a complete expression appears in a shortened version of Dowell and Long in 2.4; a summary version in 2.3; a generalised HCI/E version in 2.2; and finally, a generalised HCI version in 2.1. The latter also serves as an introduction to the Conception. Finally, the concepts carried forward by the Conception appear in 2.6 and the EU/UCL research illustrations of HCI/E in 2.7.

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

2.1 General Conception of HCI Design Problem

The General Conception of the HCI Design Problem is generalised from the General Engineering Conception of the HCI Design Problem (2.2)

General Conception of HCI Design Problem

2.2 General Conception of HCI Engineering Design problem

The General Conception of the HCI Engineering Design Problem is generalised from the HCI/E Conception of the Engineering Design Problem (2.3)

General Conception of HCI Engineering Design Problem

2.3 HCI/E(U) Conception of HCI Engineering Design Problem: a Summary

The HCI/E Conception of the HCI Engineering Design Problem is a summary of the complete version (see 2.4 and 2.5).

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

2.4 Short version of Dowell and Long (1989)

Dowell and Long examine the potential for Human Factors (HCI) to formulate engineering principles and propose a Conception of the HCI Engineering Design problem. For ease of access, only the HCI/E Conception is presented here. The full paper appears in 2.5.

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

2.5 Full Version of Dowell and Long (1989)

Here, the paper of Dowell and Long is presented in its entirety, including a complete version of the HCI/E Conception of the HCI Engineering Design Problem.

Dowell and Long (1989)

2.6 Concepts Carried Forward

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

Problem; Design; and Design Problem

2.7 Illustrations of HCI Engineering Design Problem from EU/UCL Research

2.7.1 Dowell (1998) Formulating the Cognitive Design Problem of Air Traffic Management

Dowell uses the HCI/E Conception of the HCI Engineering design problem to formulate a Cognitive Design Problem for a simulated Air Traffic Management task and to illustrate its use in seeking a design solution to that problem. The HCI design peoblem is illustrated throughout the paper.

Dowell (1998) Formulating the Cognitive Design Problem of Air Traffic Management

2.7.2 Stork and Long (1994) A Specific Planning and Design Problem in the Home: Rationale and a Case-study

Stork and Long use the HCI/E Conception of the HCI Engineering design problem to operationalse a specific design problem in the home. The HCI design problem is illustraed throughout the paper.

Stork and Long (1994) A Specific Planning and Design Problem in the Home: Rationale and a Case-study

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

Hill uses the HCI/E Conception of the HCI Engineering Design problem to develop models and methods to diagnose co-ordination design problems of the Emergency Management Response to Disasters System – see especially Section 3 HCI Planning and Control for Multiple Task Work Framework

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

2.7.4 Cummaford and Long (2010) Engineering Design Principles: Validating Successful HCI Design Knowledge to Support its Re-use

Cummaford and Long use the HCI/E Conceptions (Discipline and Design Problem) to acquire initial Engineering Design Principles, related to electronic shopping.

Cummaford and Long (2010) Engineering Design Principles: Validating Successful HCI Design Knowledge to Support its Re-use

 

3.1 General Conception of HCI Design Knowledge 150 150 John

3.1 General Conception of HCI Design Knowledge

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

HCI design knowledge is the product of research and practice, both of which solve HCI design problems. (F2) (C2) Such knowledge may be private or public, formal or informal. It may assume a number of forms, for example, codified; experienced; proceeduralised; demonstrated; exemplified as in skills; theories; guidelines; heuristics; rules-of-thumb; principles; hints-and-tips etc.  (C3)(C4) HCI design knowledge may be maintained in a number of ways: for example, it may be expressed in journals; example solutions to design problems; learning systems; communities; good practice; procedures; word-of-mouth; tools etc.  HCI knowledge is, therefore, a necessary characteristic of the HCI discipline, its practices and its design problem. (F3)

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

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

Footnotes and Citations

Footnotes

(F1) This definition encapsulates the basic characteristics of HCI: 1. that people not only use computers; but use them to do something (whatever that something may be); 2. That people not only use computers to do something; but to do something what and how they want.

(F2) HCI research solves design problems to acquire and to validate HCI design knowledge. HCI practice solves design problems to satisfy user and client requirements.

(F3) Some semblance of order can be brought to this plethora of types of design knowledge by supposing different approaches to establishing a discipline of HCI, for example: Craft; Applied Science; and Engineering (Long and Dowell, 1989).

(F4) Some semblance of order can be brought to this plethora of types of design practice by supposing different approaches to establishing a discipline of HCI, for example: Craft; Applied Science; and Engineering (Long and Dowell, 1989). See also F3 above.

Citations

Long and Dowell (1989)

(C1) ‘Second, the scope of the general problem of HCI is defined by reference to humans, computers, and the work they perform.’ (Page 9, Abstract, Lines 7-9) (

C2) ‘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’. (Page 9, Lines 16-19)

(C3) ‘…….. 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.’ (Page 10, Lines 12-17)

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

Dowell and Long (1989)

(C5) ‘Most definitions of disciplines assume three primary characteristics: a general problem; practices, providing solutions to that problem; and knowledge, supporting those practices.’ (Page 1514, Lines 43-45)

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

(C7) ‘The contemporary HF discipline does not possess either methodological or substantive engineering principles. The heuristics it possesses are either ‘rules of thumb’ derived from experience or guidelines derived from psychological theories and findings. Neither guidelines nor rules of thumb offer assurance of their efficacy in any given instance, and particularly with regard to the effectiveness of a design. The methods and models of HF (as opposed to methodological and substantive principles) are similarly without such an assurance. (Page 1520, Lines 21-28)

1.5 Long and Dowell (1989) – Full Version 150 150 John

1.5 Long and Dowell (1989) – Full Version

 

The full version of the HCI/E(U) Conception includes: Application; Interactive System; and Performance.

1  Application

1.1 Objects

Engineering applications (the ‘tasks’ the interactive system ‘performs effectively’) can be described as objects. Such applications occur in the need of organisations for interactive systems. Objects may be both abstract and physical and are characterised by their attributes. Abstract attributes are those of information and knowledge. Physical attributes are those of energy and matter.

For example, a website application (such as for an academic organisation) can be described for design research purposes in terms of objects; their abstract attributes, supporting the creation of websites; their physical attributes supporting the visual/verbal representation of displayed information on the website pages by means of text and images. Application objects are specified as part of engineering design and can be researched as such.

1.2 Attributes and Levels

The attributes of an engineering application object emerge at different levels of description. For example, characters and their configuration on a webpage are physical attributes of the object ‘webpage’, which emerge at one level. The message on the page is an abstract attribute, which emerges at a higher level of description.

1.3 Relations between Attributes

Attributes of engineering application objects are related in two ways. First, attributes are related at different levels of complexity. Second, attributes are related within levels of description.

1.4 Attribute States and Affordance

The attributes of engineering application objects can be described as having states. Further, those states may change. For example, the content and characters (attributes) of a website page (object) may change state: the content with respect to meaning and grammar; its characters with respect to size and font. Objects exhibit an affordance for transformation, associated with their attributes’ potential for state change.

1.5 Applications and the Requirement for Attribute State Changes

An engineering application may be described in terms of affordances. Accordingly, an object may be associated with a number of applications. The object ‘website’ may be associated within the application as that of site structure (state changes of its organisational attributes) and the authorship (state changes of its textual and image content). In principle, an application may have any level of generality, for example, the writing of personal pages and the writing of academic pages.

Organisations have applications and require the realisation of the affordance of their associated objects. For example, ‘completing a survey’ and ‘writing for a special group of users’, may each have a website page as their transform, where the pages are objects, whose attributes (their content, format and status, for example) have an intended state. Further editing of those pages would produce additional state changes, and therein, new transforms. Requiring new affordances might constitute an additional (unsatisfied) User Requirement and result in a new Interactive System.

1.6 Application Goals

Organisations express the requirement for the transformation of engineering application objects in terms of goals. A product goal specifies a required transform – the realisation of the affordance of an object. A product goal generally supposes necessary state changes of many attributes. The requirement of each attribute state change can be expressed as an application task goal, derived from the product goal.

So, for example, the product goal demanding transformation of a website page, making its messages less complex and so more clear, would be expressed by task goals, possibly requiring state changes of semantic attributes of the propositional structure of the text and images and of associated syntactic attributes of the grammatical structure. Hence, a product goal can be re-expressed as an application task goal structure, a hierarchical structure expressing the relations between task goals, for example, their sequences. The latter might constitute part of an engineering design, calling upon engineering knowledge as: design guidelines/models and methods/specific design principles/general design principles.

The transformation of an object, associated with a product goal, involves many attribute state changes – both within and across levels of complexity. Consequently, there may be alternative transforms, which satisfy the same product goal – e-mails with different styles, for example, where different transforms exhibit different compromises between attribute state changes of the application object. There may also be transforms, which fail to meet the product goal. The concept of ‘performing tasks effectively as desired’ describes the variance of an actual transform with that specified by a product goal. It enables all possible outcomes of an application to be equated and evaluated. Such transforms may become the object of engineering design and so research.

1.7 Engineering Application as: performing tasks effectively, as desired.

The transformation of an object, associated with a product goal, involves many attribute state changes – both within and across levels of complexity. Consequently, there may be alternative transforms, which satisfy a product goal – website pages with different styles. The concept of ‘performing tasks effectively, as desired’ describes the variance of an actual transform with that specified by a product goal.

.

1.8 Engineering Application and the User

Description of the engineering application 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 by ‘performing tasks effectively, as desired’, which occurs only by means of objects, affording transformation and interactive systems, capable of producing a transformation. Such production may be (part of) a engineering design.

From product goals is derived a structure of related task goals, which can be assigned either to the user or to the interactive computer (or both) within the design of an associated interactive system. The task goals assigned to the user are those, which motivate the user’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 ‘as desired’, characterised in terms of: wanted/needed/experienced/felt/valued.

2. Interactive Computers and the Human

2.1 Interactive Systems

An interactive system can be described as a behavioural system, distinguished by a boundary enclosing all human and interactive computer behaviours, whose purpose is to achieve and satisfy a common goal. For example, the behaviours of a webmaster, using a website application, whose purpose is to construct websites, constitute an interactive system. Critically, it is only by identifying the common goal, that the boundary of the interactive system can be established and so designed and researched.

Users are able to conceptualise goals and their corresponding behaviours are said to be intentional (or purposeful). Interactive computers are designed to achieve goals and their corresponding behaviours are said to be intended (or purposive). An interactive system can be described as a behavioural system, distinguished by a boundary enclosing all user and interactive computer behaviours, whose purpose is to achieve and satisfy a common goal. For example, the behaviours of a website secretary and a web application, whose purpose is to manage the site, constitute an interactive system. Critically, it is only by identifying the common goal, that the boundary of an interactive system can be established and so designed and researched.

Interactive systems transform objects by producing state changes in the abstract and physical attributes of those objects (see 1.1). The webmaster and the website application may transform the object ‘page’ by changing both the attributes of its meaning and the attributes of its layout, both text and images.

The behaviours of the user and the interactive computer are described as behavioural sub-systems of the interactive system – sub-systems, which interact. The human behavioural sub-system is more specifically termed the user. Behaviour may be loosely understood as ‘what the user does’, in contrast with ‘what is done’ (that is, attribute state changes of application objects). More precisely the user is described as:

a system of distinct and related user behaviours, identifiable as the sequence of states of a user interacting with a computer to perform tasks effectively, as desired and corresponding with a purposeful (intentional) transformation of application objects.

Although expressible at many levels of description, the user must at least be described at a level, commensurate with the level of description of the transformation of application objects. For example, a webmaster interacting with a website application is a user, whose behaviours include receiving and replying to messages, sent to the website.

2.2 Humans as a System of Mental and Physical Behaviours

The behaviours, constituting an interactive system, are both physical and abstract. Abstract behaviours are generally the acquisition, storage, and transformation of information. They represent and process information, at least concerning: application 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 described 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) application objects, represented in cognition or express, through overt behaviour, plans for transforming application objects.

For example, a webmaster has the product goal, required to maintain the circulation of a website newsletter to a target audience. The webmaster interacts with the computer by means of the user interface (whose behaviours include the transmission of information in the newsletter). Hence, the webmaster acquires a representation of the current circulation by collating the information displayed by the computer screen and assessing it by comparison with the conditions, specified by the product goal. The webmaster 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 and circulate the newsletter, ‘as desired’. That decision is expressed in the set of instructions issued to the interactive computer through overt behaviour – selecting menu options, for example.

The user is described as having cognitive, conative and affective aspects. The cognitive aspects are those of knowing, reasoning and remembering; the conative aspects are those of acting, trying and persevering; and the affective aspects are those of being patient, caring and assuring. Both mental and overt user behaviours are described as having these three aspects, all of which may contribute to ‘performing tasks effectively, as desired as wanted/needed/experienced/felt/valued.

2.3 Human-Computer Interaction

Although user and interactive computer behaviours may be described as separable sub-systems of the interactive system, these sub-systems exert a ‘mutual influence’, that is to say they interact. Their configuration principally determines the interactive system and so its design and the associated research into that and other possible engineering designs.

Interaction of the user and the interactive computer behaviours is the fundamental determinant of the interactive system, rather than their individual behaviours per se. Interaction is described as: the mutual influence of the user (i.e. behaviours) and the interactive computer (i.e behaviours), associated within an interactive system. For example, the behaviours of a webmaster interact with the behaviours of a website application. The webmaster’s behaviours influence the behaviours of the interactive computer (access the image function), while the behaviours of the interactive computer influence the selection behaviour of the webmaster (among possible image types). The design of their interaction – the webmaster’s selection of the image function, the computer’s presentation of possible image types – determines the interactive system, comprising the webmaster and interactive computer behaviours in their planning and control of webpage creation. The interaction may be the object of engineering design and so design research.

The assignment of task goals by design then, to either the user or the interactive computer, delimits the former and therein specifies the design of the interaction. For example, replacement of an inappropriate image, required on a page is a product goal, which can be expressed as a task goal structure of necessary and related attribute state changes. In particular, the field for the appropriate image as an attribute state change in the spacing of the page. Specifying that state change may be a task goal assigned to the user, as in interaction with the behaviours of early image editor designs or it may be a task goal assigned to the interactive computer, as in interaction with the GUI ‘fill-in’ behaviours. Engineering design research would be expected to have contributed to the latter . The assignment of the task goal of specification constitutes the design of the interaction of the user and interactive computer behaviours in each case, which in turn may become the object of research.

2.4 Human On-line and Off-line Behaviours

User behaviours may comprise both on-line and off-line behaviours: on-line behaviours are associated with the interactive computer’s representation of the application; off-line behaviours are associated with non-computer representations of the application.

As an illustration of the distinction, consider the example of an interactive system, consisting of the behaviours of a website secretary and an e-mail application. They are required to produce a paper-based copy of a dictated letter, stored on audio tape. The product goal of the interactive system 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 application object. By contrast, the secretary’s on-line behaviours include specifying the represention by the interactive computer of the transposed content of the letter in a desired visual/verbal format of stored physical symbols.

On-line and off-line user behaviours are a particular case of the ‘internal’ interactions between a user’s behaviours as, for example, when the web secretary’s keying interacts with memorisations of successive segments of the dictated letter.

2.5 Structures and the Human

Description of the user as a system of behaviours needs to be extended, for the purposes of design and design research, to the structures supporting that behaviour.

Whereas user behaviours may be loosely understood as ‘what the human does’, the structures supporting them can be understood as ‘the support for the human to be able to do what they do’. There is a one-to-many mapping between a user’s structures and the behaviours they might support: thus, the same structures may support many different behaviours.

In co-extensively enabling behaviours at each level of description, structures must exist at commensurate levels. The user structural architecture is both physical and mental, providing the capability for a user’s overt and mental behaviours. It provides a represention of application 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 user structure is neural, bio-mechanical and physiological. Mental structure consists of representational schemes and processes. Corresponding with the behaviours it supports and enables, user structure has cognitive, conative and affective aspects. The cognitive aspects of user structures include information and knowledge – that is, symbolic and conceptual representations – of the application, of the interactive computer and of the user themselves, and it includes the ability to reason. The conative aspects of user structures motivate the implementation of behaviour and its perseverence in pursuing task goals. The affective aspects of user structures include the personality and temperament, which respond to and support behaviour. All three aspects may contribute to ‘ performing tasks effectively, as desired as wanted/needed/experienced/felt/valued’.

To illustrate this description of mental structure, consider the example of the structures supporting a web user’s behaviours. Physical structure supports perception of the web page display and executing actions to the web application. Mental structures support the acquisition, memorisation and transformation of information about how the web application is conducted. The knowledge, which the web user has of the application and of the interactive computer, supports the collation, assessment and reasoning about the actions required.

The limits of user structures determine the limits of the behaviours they might support. Such structural limits include those of: intellectual ability; knowledge of the application and the interactive 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 (a 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 user structures.

The behavioural limits of the user, determined by structure, are not only difficult to define with any kind of completeness, they may also be variable, because that structure may change, and in a number of ways. A user may have self-determined changes in response to the application – as expressed in learning phenomena, acquiring new knowledge of the application, of the interactive computer, and indeed of themselves, to better support behaviour. Also, user structures degrade with the expenditure of resources by behaviour, as demonstrated by the phenomena of mental and physical fatigue. User structures may also change in response to motivating or de-motivating influences of the organisation, which maintains the interactive system.

It must be emphasised that the structure supporting the user is independent of the structure supporting the interactive 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 interactive system 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 interactive system. The combination of structures of both user and interactive computer, supporting their interacting behaviours is described as the user interface .

2.6 Human Resource Costs

‘Performing tasks effectively as desired’ by means of an interactive system always incurs resource costs. Given the separability of the user and the interactive computer behaviours, certain resource costs are associated directly with the user and distinguished as structural user costs and behavioural user costs.

Structural user costs are the costs of the user structures. Such costs are incurred in developing and maintaining user skills and knowledge. More specifically, structural user costs are incurred in training and educating users, so developing in them the structures, which will enable the behaviours necessary for an application . Training and educating may augment or modify existing structures, provide the user with entirely novel structures, or perhaps even reduce existing structures. Structural user costs will be incurred in each case and will frequently be borne by the organisation. An example of structural user costs might be the costs of training a secretary to use a GUI web interface in the particular style of layout, required for an organisation’s correspondence with its clients and in the operation of the interactive computer by which that layout style can be created.

Structural user costs may be differentiated as cognitive, conative and affective structural costs. Cognitive structural costs express the costs of developing the knowledge and reasoning abilities of users and their ability for formulating and expressing novel plans in their overt behaviour – as necessary for ‘performing tasks effectively, as desired’. Conative structural costs express the costs of developing the activity, stamina and persistence of users as necessary for an application. Affective structural costs express the costs of developing in users their patience, care and assurance as necessary for an application.

Behavioural user costs are the resource costs, incurred by the user (i.e by the implementation of their of behaviours) in recruiting user structures to effect an application. 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 web 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. Costs are an important aspect of the engineering design of an interactive computer system.

When differentiated, mental and physical behavioural costs are described 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 user’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 user costs are evidenced in user fatigue, stress and frustration; they are costs borne directly by the user and so need to be taken into account in the engineering design process.

3. Performance of the Interactive Computer System and the User.

‘To perform tasks effectively, as desired’ derives from the relationship of an interactive system with its application. It assimilates both how well the application is performed by the interactive system and the costs incurred by it. These are the primary constituents of ‘performing tasks effectively, as desired’, that is performance. They can be further differentiated, for example, as wanted/needed/experienced/felt/valued.

A concordance is assumed between the behaviours of an interactive system and its performance: behaviours determine performance. How well an application is performed by an interactive system is described as the actual transformation of application objects with regard to the transformation, demanded by product goals. The costs of carrying out an application are described as the resource costs, incurred by the interactive system and are separately attributed to the user and the interactive computer. Specifically, the resource costs incurred by the user are differentiated as: structural user costs – the costs of establishing and maintaining the structures supporting behaviour; and behavioural user costs – the costs of the behaviour, recruiting structure to its own support. Structural and behavioural user costs are further differentiated as cognitive, conative and affective costs. Design requires attention to all types of resource costs – both those of the user and of the interactive computer.

‘Performing tasks effectively, as desired’ by means of an interactive system may be described as absolute or as relative, as in a comparison to be matched or improved upon. Accordingly, criteria expressing ‘as desired’ may either specify categorical gross resource costs and how well an application is performed or they may specify critical instances of those factors to be matched or improved upon. They are the object of engineering design and so of design research.

Discriminating the user’s performance within the performance of the interactive system would require the separate assimilation of user resource costs and their achievement of desired attribute state changes, demanded by their assigned task goals. Further assertions concerning the user arise from the description of interactive system performance. First, the description of performance is able to distinguish the goodness of the transforms from the resource costs of the interactive system, which produce them. This distinction is essential for engineering design, as two interactive systems might be capable of producing the same transform, yet if one were to incur a greater resource cost than the other, it would be the lesser (in terms of performance) of the two systems.

Second, given the concordance of behaviour with ‘performing tasks effectively, as desired’, optimal user (and equally, interactive computer) behaviours may be described as those, which incur a (desired) minimum of resource costs in producing a given transform. engineering design of optimal user behaviour would minimise the resource costs, incurred in producing a transform of a given goodness. However, that optimality may only be categorically determined with regard to interactive system performance and the best performance of an interactive system may still be at variance with what is desired of it. To be more specific, it is not sufficient for user behaviours simply to be error-free. Although the elimination of errorful user behaviours may contribute to the best application possible of a given interactive system, that performance may still be less than ‘as desired’. Conversely, although user behaviours may be errorful, an interactive system may still support ‘performing tasks effectively, as desired’.

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 goodness of the transform or both. The duration of user behaviours may (very generally) be associated with increases in behavioural user costs.

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

Fifth, resource costs, incurred by the user and the interactive computer may be traded-off in the design of the performance of an application. A user can sustain a level of performance of the interactive system by optimising behaviours to compensate for the poorly designed behaviours of the interactive computer (and vice versa), that is, behavioural costs of the user and interactive computer are traded-off in the design process. This is of particular importance as the ability of users to adapt their behaviours to compensate for the poor design of interactive computer-based systems often obscures the fact that the systems are poorly designed.

 

3.2 General Conception of HCI Engineering Design Knowledge 150 150 John

3.2 General Conception of HCI Engineering Design Knowledge

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

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

The discipline of HCI Engineering, aims (in the longer term) to solve its general problem of design by the specification of designs before their implementation – as in ‘specify then implement’ design practices. (C6) (C7) (C9) The latter is made possible by the prescriptive nature of the knowledge supporting such practices – knowledge formulated as HCI Engineering principles. (C4) However, a pre-requisite for the formulation of any HCI Engineering principles is a Conception. The EU Conception, from which the HCI Engineering Conception is generalised, is a unitary view of the HCI Engineering design problem; its power lies in the coherence and completeness of its definition of the concepts, which can express that problem. (F4) (C8) (C12)

Engineering principles are articulated in terms of those self-same concepts. The latter include: user; computer; interaction; task; domain of application; system; and performance (for a full listing – see 2.2). Thus, the Conception of HCI Engineering principles assumes the possibility of a codified, general, and testable formulation of HCI Engineering discipline knowledge. The latter might be prescriptively applied to designing humans and computers interacting to perform tasks as desired. Such principles would be unequivocally formal and operational. Indeed, their operational capability would derive directly from the formality of their concepts. (C4) HCI Engineering concepts would be generalisable over classes of design problem solutions. Since the principles are operational, their application (expressed as design solutions) would necessarily be specifiable. They would also be testable and so their reliability and generality could also be specified. (C5)

In this way would the principles, expressed in terms of the Conception of Engineering design knowledge, be validated. Such validated Engineering design principles would offer a better guarantee (that is, more assurance – see 3.6.1)) of solving the HCI general design problem. Better, for example, than the experiential trial-and-error knowledge of craft HCI or the guidelines/heuristics of Applied Science HCI. (C11) HCI Engineering principles, following the Conception of Engineering design knowledge, can be substantive or methodological. Methodological principles prescribe the methods for solving the general HCI design problem. Methodological principles would assure complete specification of all necessary levels of design solution representation. Substantive principles prescribe the features and properties of HCI systems that constitute solutions to the HCI Engineering design problem. (C10)

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

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

Footnotes and Citations

Footnotes

(F1) The contrast here with Engineering is Science, which has its own discipline problem, knowledge and practices.

(F2) See (F1)

(F3) For the present purposes, Engineering, in its early craft stages, is not addressed.

(F4) Other HCI Engineering conceptions, other than that of the EU, might, of course, also be postulated.

(F5) See (F3)

Citations

Long and Dowell (1989)

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

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

(C3) ‘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)

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

(C5) ‘First, HCI engineering principles would be a generaliseable knowledge. …….. 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.’ (Page 27, Lines 20-22 and 36-28)

Dowell and Long (1989)

(C6) ‘The paper .….. examines the potential for Human Factors to formulate engineering principles. ……… A conception would provide the set of related concepts which both expressed the general design problem more formally, and which might be embodied in engineering principles.’ (Page 1513, Lines 9 and 10)

(C7) By comparing the HF general design problem with other, better-understood, general design problems, and by identifying the formal knowledge possessed by the corresponding disciplines, the potential for HF engineering principles is suggested.’ (Page 1514, Lines 15-18).

(C8) ‘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.’ (Page 1514, Lines 23-27)

(C9) ‘Generally, the established engineering disciplines possess formal knowledge: a corpus of operationalised, tested, and generalised principles. Those principles are prescriptive, enabling the complete specification of design solutions before those designs are implemented (see Dowell and Long, 1988b).’ (Page 1520, Lines 1-5)

(C10) ‘Engineering principles can be substantive or methodological. Methodological Principles prescribe the methods for solving a general design problem optimally. ……Methodological principles would assure each lower level of specification as being a complete representation of an immediately higher level. Substantive Principles prescribe the features and properties of artefacts, or systems that will constitute an optimal solution to a general design problem. (Page 1520, Lines 6-15)

(C11) ‘The contemporary HF discipline does not possess either methodological or substantive engineering principles. The heuristics it possesses are either ‘rules of thumb’ derived from experience or guidelines derived from psychological theories and findings. Neither guidelines nor rules of thumb offer assurance of their efficacy in any given instance, and particularly with regard to the effectiveness of a design. The methods and models of HF (as opposed to methodological and substantive principles) are similarly without such an assurance. (Page 1520, Lines 21-28)

(C12) ‘Such a conception ….. enables the formulation of engineering principles which embody and instantiate those concepts.( Page 1520, Line 1)

(C13) ‘The extent to which HF engineering principles might be realiseable in practice remains to be seen. It is not supposed that the development of effective systems will never require craft skills in some form, and engineering principles are not seen to be incompatible with craft knowledge, particularly with respect to their instantiation. At a minimum, engineering principles might be expected to augment the craft knowledge of HF professionals. Yet the great potential of HF engineering principles for the effectiveness of the discipline demands serious consideration.’ (Page 1533, Lines 24-29)

Long and Dowell (1989) 150 150 John

Long and Dowell (1989)

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.

The theme of HCI ’89 is ‘the theory and practice of HCI’. In providing a general introduction to the Conference, this paper develops the theme within a characterisation of alternative conceptions of the discipline of Human-Computer Interaction (HCI). 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 within which different conceptions of the HCI discipline may be established, ordered, and related. 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’. Fourth, three alternative conceptions of the discipline of HCI are identified. They are HCI as a craft discipline, as an applied scientific discipline, and as an engineering discipline. Each conception is considered in terms of its view of the general problem, the practices seeking solutions to the problem, and the knowledge supporting those practices; examples are provided. Finally, the alternative conceptions are reviewed, and the effectiveness of the discipline which each offers is comparatively assessed. The relationships between the conceptions in establishing a more effective discipline are indicated.

Published in: People and Computers V. Sutcliffe A. and Macaulay L. (ed.s). Cambridge University Press, Cambridge. Proceedings of the Fifth Conference of the BCS HCI SIG, Nottingham 5-8 September 1989. 1
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

HCI ’89 is the fifth conference in the ‘People and Computers’ series organised by the British Computer Society’s HCI Specialist Group. The main theme of HCI ’89 is ‘the theory and practice of HCI’. The significance of the theme derives from the questions it prompts and from the Conference aims arising from it. For example, what is HCI? What is HCI practice? What theory supports HCI practice? How well does HCI theory support HCI practice? Addressing such questions develops the Conference theme and so advances the Conference goals.

1.1. Alternative Interpretations of the Theme

Any attempt to address these questions, however, admits no singular answer. For example, some would claim HCI as a science, others as engineering. Some would claim HCI practice as ‘trial and error’, others as ‘specify and implement’. 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. Clearly then, there will be many possible interpretations of the theme ‘the theory and practice of HCI’. Answers to some of the questions prompted by the theme will be related. Different answers to the same question may be mutually exclusive; for example, types of practice as ‘trial and error’ or ‘specify and implement’ will likely be mutually exclusive. 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

It follows that we must admit the possibility of alternative, and equally legitimate, conceptions of the HCI discipline – and therein, of its theory and practice. 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. So for example, a conception of HCI might be either of a scientific or of an engineering discipline; its view of the theory and practice of the discipline would be different in the two cases. Its view of how the discipline might operate, and its expectations for the effectiveness of the discipline, would also be different in the two cases. This paper identifies alternative conceptions of HCI, and attempts a comparative assessment of the (potential) effectiveness of the discipline which each views. The requirement for identifying the different conceptions is both prompted and required by the development of the Conference theme.

To advance alternative conceptions of HCI, however, it is necessary first to formulate some form of analytic structure to ensure that conceptions supposed as alternatives are both complete and of the same subject, rather than being conceptions of complementary, or simply different, subjects. A suitable structure for this purpose would be a framework identifying the essential characteristics of the HCI discipline. By such a framework, instances of conceptions of the HCI discipline – claimed to be substantively different, but equivalent – might be established, ordered, and related. And hence, so might their views of its theories and practices. The aims of this paper follow from the need to identify alternative conceptions of HCI as a discipline.

The aims are described in the next section.

1.3. Aims

To address and develop the Conference theme of ‘the theory and practice of HCI’ – and so to advance the goals of HCI ’89 – the aims of this paper are as follows:

(i) to propose a framework for conceptions of the HCI discipline

(ii) to identify and exemplify alternative conceptions of the HCI discipline in terms of the framework

(iii) to evaluate the effectiveness of the discipline as viewed by each of the conceptions, and to indicate the possible relationships between the conceptions in establishing a more effective 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. 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.

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. For example, the discipline of science includes the scientific practice addressing the general (scientific) problem of explanation and prediction. The discipline of engineering includes the engineering practice addressing the general (engineering) problem of design. The discipline of medicine includes the medical practice addressing the general (medical) problem of supporting health. 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. The scientific discipline addresses the general (scientific) problem of explanation and prediction, the engineering discipline addresses the general (engineering) problem of design, and so on. 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 scopes1. This decomposition allows the further division of disciplines into sub-disciplines.

For example, the scientific discipline includes the disciplines of physics, biology, psychology, etc., each distinguished by the particular scope of the general problem it addresses. The discipline of psychology addresses a general (scientific) problem whose particular scope is the mental and physical behaviours of humans and animals. It attempts to explain and predict those behaviours. It is distinguished from the discipline of biology which addresses a general problem whose particular scope includes anatomy, physiology, etc. Similarly, the discipline of engineering includes the disciplines of civil, mechanical, electrical engineering, etc. Electrical engineering is distinguished by the particular scope of the general (engineering) problem it addresses, i.e., the scope of electrical artefacts. And similarly, the discipline of medicine includes the disciplines of dermatology, neurology etc., each distinguished by the particular scope of the general problem it addresses. 1Notwithstanding the so-called ‘hierarchy theory ‘ which assumes a phenomenon to occur at a particular level of complexity and to subsume others at a lower level (eg, Pattee, 1973).

 

Figure 1. Definition of a Discipline

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. It implicates: humans, both individually and in organisations; computers, both as programmable machines and functionally embedded devices within machines (stand alone or networked); and work performed by humans and computers within organisational contexts. It implicates both behaviours and structures of humans and computers. It implicates the interactions between humans and computers in performing both physical work (ie, transforming energy) and abstract work (ie, transforming information). 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.
Figure 2. Definition of the Scope of the General Problem addressed by the discipline of HCI. (Humans and computers interacting to perform work. effectively).

2.3. The Framework for Conceptions of the HCI Discipline

The possibility of alternative, and equally legitimate, conceptions of the discipline of HCI was earlier postulated. This section proposes a framework within which different conceptions may be established, ordered, and related.

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.

The general problem of HCI can be decomposed (with regard to its scope) into two general problems, each having a particular scope. Whilst subsumed within the general problem of HCI, these two general problems are expressed as: ‘the design of humans interacting with computers’; and ‘the design of computers interacting with humans’. Each problem can be associated with a different sub- discipline of HCI. Human Factors (HF), or Ergonomics, addresses the problem of designing the human as they interact with a computer. Software Engineering (SE) addresses the problem of designing the computer as it interacts with a human. With different – though complementary – aims, both sub-disciplines address the problem of designing humans and computers which interact to perform work effectively. However, the HF discipline concerns the physical and mental aspects of the human and is supported by HF discipline knowledge. The SE discipline concerns the physical and software aspects of the computer and is supported by SE discipline knowledge.

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. HCI knowledge is
constituted of HF knowledge and SE knowledge, respectively supporting HF practices and SE practices. Those practices respectively address the HF general problem of the design of humans interacting with computers, and the SE general problem of the design of computers interacting with humans’. The framework is represented schematically in Figure 3.

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’.

The framework will be used in Section 3 to establish, order, and relate alternative conceptions of HCI. It supports comparative assessment of the effectiveness of the discipline as supposed by each conception.
Figure 3 . Framework for Conceptions of the Disicpline 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. Each conception will be described and exemplified in terms of the framework. 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. Conception of HCI as a craft discipline is represented schematically in Figure 4. HCI as a craft discipline addresses the general problem of designing humans and computers interacting to perform work effectively. For example, Prestel uses Videotex technology to provide a public information service which also includes remote electronic shopping and banking facilities (Gilligan & Long [1984]). The practice of HCI to solve the general problem of Prestel interaction design is by implementation, evaluation and iteration (Buckley [1989]). For example, Videotex screen designers try out new solutions – for assigning colours to displays, for selecting formats to express user instructions, etc. Successful forms of interaction are integrated into accepted good practice – for example, clearly distinguishing references to domain ‘objects’ (goods on sale) from references to interface ‘objects’ (forms to order the goods) and so reducing user difficulties and errors. Screen designs successful in supporting interactions are copied by other designers. Unsuccessful interactions are excluded from subsequent implementations – for example, the repetition of large scale logos on all the screens (because the screens are written top-to-bottom and the interaction is slowed unacceptably). HCI craft knowledge, supporting practice, is maintained by practice itself. For example, in the case of Videotex shopping, users often fail to cite on the order form the reference number of the goods they wish to purchase. A useful design heuristic is to try prompting users with the relevant information, for example, by reminding them on the screen displaying the goods that the associated reference number is required for ordering and should be noted. An alternative heuristic is to try re-labelling the reference number of the goods, for example to ‘ordering’ rather than reference number. Heuristics such as these are formulated and tried out on new implementations and are retained if associated with successful interactions. To illustrate HCI as a craft discipline more completely, there follows a detailed example taken from a case history reporting the design of a text editor (Bornat & Thimbleby [1989]). Bornat and Thimbleby are computer scientists who, in the 1970s, designed a novel text display editor called ‘Ded’. The general problem of HCI for them was to design a text editor which would enable the user to enter text, review it, add to it, to reorganise its structure and to print it. In addition, the editor was to be easy to use. They characterise their practice as ‘production’ (implementation as used here) suffused by design activity. Indeed, their view is that Ded was not designed but evolved. There was always a fully working version of the text editor to be discussed, even from the very early days. 9
10 Figure 4. Conception of HCI as a Craft Discipline The evolution, however, was informed by ‘user interface principles’ (which they sometimes call theories and at other times call design ideas) which they invented themselves, tried out on Ded, retained if successful and reformulated if unsuccessful. The status of the principles at the time of their use would be termed here craft discipline knowledge or heuristics. (Subsequent validation of the heuristics as other than craft knowledge would of course be possible, and so change this status.) For example, ‘to indicate to users exactly what they are doing, try providing rapid feedback for every keypress’. Most feedback was embodied in changes to the display (cursor movements, characters added or deleted, etc.) which were visible to the user. However, if the effect of a keypress was not visible, there was no effect, but a bell rang to let the user know. In this way, the craft heuristic supporting the SE craft practice – by informing the design of the computer interacting with the human – can be expressed as: ‘if key depression and no display change, then ring bell’. The heuristic also supported HF craft practice – by informing the design of the human interacting with the computer. It may be expressed as: ‘if key pressed and no display change seen, and bell heard, then understand no effect of keypress (other than bell ring)’. Another example of a craft heuristic used by Bornat and Thimbleby (and one introduced to them by a colleague) is ‘to ensure that information in the computer is what the user thinks it is, try using only HCI Problem HCI HCI work (domain) human computer Pract ice HF imHpFlePmraecntt &ictest + SE implement & test Knowledge HF heuristics + SE heuristics
one mode’. The heuristic supported SE practice, informing the design of the computer interacting with the human – ‘if text displayed, and cursor under a character, and key depression, then insert character before cursor position’. The heuristic also supported HF practice, informing the design of the human interacting with the computer – ‘if text seen, and cursor located under a character, and key has been pressed, then only the insertion of a character before the cursor position can be seen to be effected (but nothing else)’. In summary, the design of Ded by Bornat and Thimbleby illustrates the critical features of HCI as a craft discipline. They addressed the specific form of the general problem (general because their colleague suggested part of the solution – one ‘mode’ – and because their heuristics were made available to others practising the craft discipline). Their practices involved the iterative implementation and evaluation of the computer interacting with the human, and of the human interacting with the computer. They were supported by craft discipline heuristics – for example: ‘simple operations should be simple, and the complex possible’. Such craft knowledge was either implicit or informal; the concepts of ‘simple’ and ‘complex’ remaining undefined, together with their associated operations (the only definitions being those implicit in Ded and in the expertise of Bornat and Thimbleby, or informal in their report). And finally, the heuristics were generated for a purpose, tried out for their adequacy (in the case of Ded) and then retained or discarded (for further application to Ded). This too is characteristic of a craft discipline. Accepting that Ded met its requirements for both functionality (enter text, review text, etc.) and for usability (use straight away, etc) – as claimed by Bornat and Thimbleby – it can be accepted as an example of good HCI craft practice. To conclude this characterisation of HCI as a craft discipline, let us consider its potential for effectiveness. As earlier proposed (Section 2.3), an effective discipline is one whose practices successfully solve its general problem, whilst incurring acceptable costs in acquiring and applying the knowledge supporting those practices (see Dowell & Long [1988]). HCI as a craft discipline will be evaluated in general for its effectiveness in solving the general problem of designing humans and computers interacting, as exemplified by Bornat and Thimbleby’s development of Ded in particular. Consideration of HCI as a craft discipline suggests that it fails to be effective (Dowell & Long [manuscript submitted for publication]). 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). For example, the heuristic ”simple operations should be simple, and the complex possible’ could not be implemented without the help of Bornat and Thimbleby or extensive interpretation by the designer. The heuristic provides insufficient information for its operationalisation. In addition, since craft heuristics cannot be directly applied to practice, practice cannot be easily planned and coordinated. Further, when HF and SE design practice are allocated to different people or groups, practice cannot easily be integrated. (Bornat was responsible for both HF and SE design practice and was also final arbiter of design solutions.) Thus, with respect to the requirement for its knowledge to be operational, the HCI craft discipline fails to be effective. If craft knowledge is not operational, then it is unlikely to be testable – for example, whether the ‘simple’ operations when implemented are indeed ‘simple’, and whether the ‘complex’ operations when implemented are indeed ‘possible’. Hence, the second reason why HCI as a craft discipline fails to be effective is because 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. For example, the heuristic of providing rapid feedback in Ded does not guarantee that users know what they are doing, because they might not understand the contingencies of the feedback. (However, it would be expected to help understanding, at least to 11
some extent, and more often than not). 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 – for example, whether ‘simple’ operations that are simple when implemented in Ded are also ‘simple’ when implemented in a different text editor. Hence, the third explanation of the failure of HCI as a craft discipline to be effective arises from the absence of generality of its knowledge. 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. Bornat and Thimbleby’s heuristics for solving the design problem of Ded may have succeeded in this instance, but the ability of the heuristics to support the solution of other design problems is unknown and, until a solution is attempted, unknowable. The suitability of the heuristics ‘ignore deficiencies of the terminal hardware’ and ‘undo one keystroke at a time’ for a system controlling the processes of a nuclear power plant could only be established by implementation and evaluation in the context of the power plant. In the absence of a well defined general scope for the problems to be addressed by the knowledge supporting HCI craft practice, each problem of designing humans and computers interacting has to be solved anew. Thus, with respect to the generality of its knowledge, the HCI craft discipline fails to be effective. Further consideration of HCI as a craft discipline suggests that the costs incurred in generating, and so in acquiring craft knowledge, are few and acceptable. For example, Bornat and Thimbleby generated their design heuristics as required, that is – as evaluation showed the implementation of one heuristic to fail. Further, heuristics can be easily communicated (if not applied) and applied now (if applicable). Thus, with respect to the costs of acquiring its knowledge, HCI as a craft discipline would seem to be effective. In summary, although the costs of acquiring its knowledge would appear acceptable, and although its knowledge when applied by practice sometimes successfully solves the general problem of designing humans and computers interacting to perform work effectively, the craft discipline of HCI is ineffective because it is generally unable to solve the general problem. It 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 (analytic, empirical, etc.) of solving the general problem of explaining and predicting the phenomena within its scope (structural, behavioural, etc.) (see Section 3.1). Science solves its general problem by hypothesis and test. Hypotheses may be based on deduction from theory or induction from regularities of structure or behaviour associated with the phenomena. Scientific knowledge is explicit and formal, operational, testable and generalisable. It is therefore refutable (if not proveable; Popper [1959]). Scientific disciplines can be associated with both HF – for example, psychology, linguistics, artificial intelligence, etc. and SE – for example, computer science, artificial intelligence, etc. Psychology explains and predicts the phenomena of the mental life and behaviour of humans (for example, the acquisition of cognitive skill (Anderson [1983])); computer science explains, and predicts the phenomena of the computability of computers as Turing-compatible machines (for example, as concerns abstract data types (Scott [1976])). 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 12
13 as an aid to addressing the general problem of designing humans and computers interacting to perform work effectively. HCI as an applied science is represented schematically in Figure 5. Figure 5. Conception of HCI as an Applied Science Discipline An example of psychological science knowledge which might be recruited to support the HF practice concerns the effect of feedback on sequences of behaviour, for example, noise and touch on keyboard operation, and confirmatory feedback on the sending of electronic messages (Hammond [1987]). (Feedback is chosen here because it was also used to exemplify craft discipline knowledge (see Section 3.1) and the contrast is informative.) Psychology provides the following predictive truth proposition concerning feedback: ‘controlled sequences need confirmatory feedback (both required and redundant); automated sequences only need required feedback during the automated sequence’. (The research supporting this predictive (but also explanatory proposition) would be expected to have defined and operationalised the terms – ‘feedback’, ‘controlled’, etc. and to have reported the empirical data on which the proposition is based.) HCI Problem HCI Practice HF i m H p F l e P mr a e c n t t &ictest HCI Knowledge HF g u i d e l i n e s ex science work (domain) human computer ++ SE implement & test SE guidelines ex science
However, as it stands, the proposition cannot contribute to the solution of the HF design problem such as that posed by the development of the text-editor Ded (Bornat & Thimbleby [1989] – see Section 3.1). The proposition only predicts the modifications of behaviour sequences by feedback under a given set of conditions. It does not prescribe the feedback required by Ded to achieve effective performance of work (enter text, review it, etc.; to be usable straight away etc.). Predictive psychological knowledge can be made prescriptive. For example Hammond transforms the predictive truth proposition concerning feedback into the following prescriptive proposition (or ‘guideline’): “When a procedure, task or sequence is not automatic to users (either because they are novice users or because the task is particularly complex or difficult), provide feedback in a number of complementary forms. Feedback should be provided both during the task sequence, to inform the user that things are progressing satisfactorily or otherwise, and at completion, to inform the user that the task sequence has been brought to a close satisfactorily or otherwise”. However, although prescriptive, it is so with respect to the modifiability of sequences of behaviour and not with respect to the effective performance of work. Although application of the guideline might be expected to modify behaviour (for example, decrease errors and increase speed), there is no indication of how the modification (either in absolute terms, or relative to other forms of feedback or its absence) would ensure any particular desired effective performance of work. Nor can there be, since its prescriptive form has not been characterised, operationalised, tested, and generalised with respect to design for effective performance (but only the knowledge on which it is based with respect to behavioural phenomena). As a result, the design of a system involving feedback, configured in the manner prescribed by the guideline, would still necessarily proceed by implementation, evaluation, and iteration. For example, although Bornat and Thimbleby appear not to have provided complementary feedback for the novice users of Ded, but only feedback by keypress (and not in addition on sequence completion – for example, at the end of editing a command), their users appear to have achieved the desired effective performance of work of entering text, using Ded straight away etc. Computer science knowledge might similarly be recruited to support SE practice in solving the problem of designing computers interacting with humans to perform work effectively. For example, explanatory and predictive propositions concerning computability, complexity, etc. might be transformed into prescriptive propositions informing system implementation, perhaps in ways similar to the attempt to achieve ‘effective computability’ (Kapur & Srivs [1988]). Alternatively, predictive computer science propositions might support general prescriptive SE principles, such as modularity, abstraction, hiding, localization, uniformity, completeness, confirmability, etc. (Charette [1986]). These general principles might in turn be used to support specific principles to solve the SE design problem of computers interacting with humans. However, as in the case of psychology, for as long as the general problem of computer science is the explanation and prediction of computability, and not the design of computers interacting with humans to perform work effectively, computer science knowledge cannot be prescriptive with respect to the latter. Whatever computer science knowledge (for example, use of abstract data types) or general SE principles (for example, modularity) informed or could have informed Bornat and Thimbleby’s development of Ded, the design would still have had to proceed by implementation, evaluation and iteration, because neither the computer science knowledge nor the SE principles address the problem of designing for the effective performance of work – entering text, using Ded straight away, etc. To illustrate HCI as an applied science discipline more completely, there follows a detailed example taken from a case history reporting the design of a computer-aided learning system to induct new undergraduates into their field of study – cognitive psychology (Hammond & Allinson [1988]). Hammond and Allinson called upon three areas of psychological knowledge, concerned with understanding and learning, to support the design of their system. These were ‘encoding specificity’ 14
theory (Tulving [1972]), ‘schema’ theory (Mandler [1979]), and ‘depth of processing’ theory (Craik & Lockhart [1972]). Only the first will be used as an example here. ‘Encoding specificity’ and ‘encoding variability’ explain and predict peoples’ memory behaviours. ‘Encoding specificity’ asserts that material can be recalled if it contains distinctive retrieval cues that can be generated at the time of recall. ‘Encoding variability’ asserts that multiple exposure to the same material in different contexts results in easier recall, since the varied contexts will result in a greater number of potential retrieval cues. On the basis of this psychological knowledge, Hammond and Allinson construct the guideline or principle: ‘provide distinctive and multiple forms of representation.’ They followed this prescription in their learning system by using the graphical and dynamic presentation of materials, working demonstrations and varied perspectives of the same information. However, although the guideline might have been expected to modify learning behaviour towards that of the easier recall of materials, the system design would have had to proceed by implementation, evaluation, and iteration. The theory of encoding specificity does not address the problem of the design of effective learning, in this case – new undergraduate induction, and the guideline has not been defined, operationalised, tested or generalised with respect to effective learning. Effective induction learning might follow from application of the guideline, but equally it might not (in spite of materials being recalled). Although Hammond and Allinson do not report whether computer science knowledge was recruited to support the solution of the SE problem of designing the computer interacting with the undergraduates, nor whether general SE principles were recruited, the same conclusion would follow as for the use of psychological knowledge. Effective induction learning performance might follow from the application of notions such as effective computability, or of principles such as modularity, but equally it might not (in spite of the computer’s program being more computably effective and better structured). In summary, the design of the undergraduate induction system by Hammond and Allinson illustrates the critical features of HCI as an applied science discipline. They addressed the specific form of the general problem (general because the knowledge and guidelines employed were intended to support a wide range of designs). Their practice involved the application of guidelines, the iterative implementation of the interacting computer and interacting human, and their evaluation. The implementation was supported by the use of psychological knowledge which formed the basis for the guidelines. The psychological knowledge (encoding specificity) was defined, operationalised, tested and generalised. The guideline ‘provide distinctive and multiple forms of representation’ was neither defined, operationalised, tested nor generalised with respect to effective learning performance. Finally, consider the effectiveness of HCI as an applied science discipline. An evaluation suggests that many of the conclusions concerning HCI as a craft discipline also hold for HCI as an applied science discipline. 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. The theory of encoding specificity is not directly applicable. 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). Even if the guideline of providing distinctive and multiple forms of representation worked in the case of undergraduate induction, it could not be generalised on the basis of this good practice alone. Third, the application of guidelines based on science knowledge does not guarantee the consequences intended, that is effective performance. The provision of distinctive and multiple forms of representation may enhance learning behaviours, but not necessarily such as to achieve the effective undergraduate induction desired. 15
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 common sense knowledge concerning learning and memory behaviours. Further, consideration of HCI as an applied science discipline suggests that the costs incurred in generating, and so in acquiring applied science knowledge, are both high (in acquiring science knowledge) and low (in generating guidelines). Whether the costs are acceptable depends on the extent to which the guidelines are effective. However, as indicated earlier, they are neither generalisable nor offer guarantees of effective performance. In summary, although its knowledge when applied by practice in the form of guidelines sometimes solves the general problem of designing humans and computers interacting to perform work effectively, the applied science discipline is ultimately ineffective because it is generally unsuccessful in solving the general problem and its costs may be unacceptable. It 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. 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. A conception of HCI as an engineering discipline is also apparent (for example: Dix & Harrison [1987]; Dowell & Long [manuscript submitted for publication]). It is a conception of HCI discipline knowledge as (ideally) constituted of (HF and SE) engineering principles, and its practices (HF and SE practices) as (ideally) specifying then implementing designs. 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. Such principles would be unequivocally formal and operational. Indeed their operational capability would derive directly from their formality, including the formality of their concepts – for example, the concepts of ‘simple’ and ‘complex’ would have an explicit and consistent definition (see Section 3.1). The complete and coherent definition of concepts, as necessary for the formulation of HCI engineering principles, would occur within a public and consensus conception of the general problem of HCI. A proposal for the form of such a conception (Dowell & Long [manuscript submitted for publication]), intended to promote the formulation of HCI engineering principles, can be summarised here. It dichotomises ‘interactive worksystems’ which perform work, and ‘domains of application’ in which work originates, is performed, and has its consequences. An interactive worksystem is conceptualised as the interacting behaviours of a human (the ‘user’) and a computer: 16
17 it is a behavioural system. The user and computer constitute behavioural systems in their own right, and therefore sub-systems of the interactive worksystem. Behaviours are the trajectory of states of humans and computers in their execution of work. The behaviours of the interactive worksystem are reflexive with two independent structures, a human structure of the user and a hardware and software structure of the computer. The behaviours of the interactive worksystem are both physical and informational, and so also are its structures. Further, behaviour incurs a resource cost, distinguished as the ‘structural’ resource cost of establishing and maintaining the structure able to support behaviour, and the ‘behavioural’ resource cost of recruiting the structure to express behaviour. Figure 6. Conception of HCI as an Engineering Discipline The behaviours of an interactive worksystem intentionally effect, and so correspond with, transformations of objects. Objects are physical and abstract and exhibit the affordance for transformations arising from the state potential of their attributes. A domain of application is a class of transformation afforded by a class of objects. An organisations` requirements for specific transformations of objects are expressed as product goals; they motivate the behaviours of an interactive worksystem. The effectiveness of an interactive worksystem is expressed in the concept of performance. Performance assimilates concepts expressing the transformation of objects with regard to its HCI Problem HCI Pract ice HCI Knowledge HF engineering principles + SE engineering principles HF specify & HFPra implement human ctice work (domain) + SE specify & computer implement
satisfying a product goal, and concepts expressing the resource costs incurred in realising that transformation. Hence, performance relates an interactive worksystem with a domain of application. A desired performance may be specified for any worksystem attempting to satisfy a particular product goal. 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} constitutes an interactive worksystem exhibiting desired performance (PD). It is implicit in this expression that the specification of behaviour supposes and enables specification of the structure supporting that behaviour. HCI engineering principles are conceptualised as supporting the practices of an engineering HCI discipline in specifying implementable designs for the interacting behaviours of both the user and computer that would achieve PD. This conception of the general problem of an engineering discipline of HCI supposes its further decomposition into two related general problems of different particular scopes. One problem engenders the discipline of HF, the other the discipline of SE; both disciplines being incorporated in HCI. The problem engendering the discipline of SE is expressed as: specify then implement {C}, such that {C} interacting with {U} constitutes an interactive worksystem exhibiting PD. The problem engendering the discipline of HF is expressed as: specify then implement {U}, such that {U} interacting with {C} constitutes an interactive worksystem exhibiting PD. The disciplines of SE and HF might each possess their own principles. 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 behaviour of the user. An SE engineering principle would take as input the performance requirement of the interactive worksystem, and a specified behaviour of the user, and prescribe the necessary interacting behaviour of the computer. Given the independence of their principles, the engineering disciplines of SE and HF might each pursue their own practices, having commensurate and integrated roles in the development of interactive worksystems. Whilst SE specified and implemented the interacting behaviours of computers, HF would specify and implement the interacting behaviours of users. Together, the practices of SE and HF would aim to produce interactive worksystems which achieved PD. It is the case, however, that the contemporary discipline of HF does not possess engineering principles of this idealised form. Dowell & Long [manuscript submitted for publication) have postulated the form of potential HF engineering principles for application to the training of designers interacting with particular visualisation techniques of CAD systems. A visualisation technique is a graphical representational form within which images of artefacts are displayed; for example, the 21/2 D wireframe representational form of the Necker cube. The supposed principle would prescribe the visual search strategy {u} of the designer interacting with a specified display behaviour {c} of the computer (supported by a specified visualisation technique) to achieve a desired performance in the ‘benchmark’ evaluation of a design. Neither does the contemporary discipline of SE possess engineering principles of the idealised form discussed. However, formal models of the interaction of display editors proposed by Dix and Harrison [1987] may show potential for development in this respect. For example, Dix and Harrison model the (behavioural) property of a command that is ‘passive’, a command having no effect on the ‘data’ component of the computer’s state. Defining a projection from state into result as r: S R, a passive command c has the property that r(s) = r(c(s)). Although the model has a formal expression, the user behaviour interacting with the (passive) computer behaviour is only implied, and the model makes no reference to desired performance. 18
It is likely the case, however, that some would claim the (idealised) conception of HCI as an engineering discipline to be unrealiseable. They might justify their objection by claiming the general problem of HCI to be ‘too soft’ to allow the development of engineering principles – that human behaviour is too indeterministic (too unspecifiable) to be subject to such principles. Yet human behaviour can be usefully deterministic to some degree – as demonstrated, for example, by the response of driver behaviour to traffic system protocols. There may well be at least a commensurate potential for the development of HCI engineering principles. To conclude this summary description of the conception of an engineering discipline of HCI, we might consider the potential effectiveness of such a discipline. As before, effectiveness is evaluated as the success with which the discipline might solve its general problem, and the costs incurred with regard to both the acquisition and application of knowledge. 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. The further consequence of this would be that the roles of HF and SE in Systems Development could be specified and integrated, providing better planned and executed development programmes. The minimisation of application costs would result in an effective discipline. Third, engineering principles would have a guaranteed efficacy. Because they would be operational, they would be testable and their reliability and generality could be specified. Their consequent assurance of product quality would render effective an engineering discipline of HCI. Finally, consideration of HCI as an engineering discipline suggests that the costs of formulating engineering principles would be severe. A research programme committed to formulating even a basic corpus of HCI engineering principles might only be conceived as a long-term endeavour of extreme scale. In summary, although the costs of their formulation would be severe, the potential of a corpus of engineering principles for improving product quality is large, and so also might be the potential for effectiveness of an engineering discipline of HCI. 4. Summary and Conclusions This paper has developed the Conference theme of ‘the theory and practice of HCI’. Generalisation of the theme, in terms of a framework for conceptions of the HCI discipline, has shown that in addition to theory and practice, the theme needs to explicitly reference the general problem addressed by the discipline of HCI and the scope of the general problem. 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 (see Section 3). For example, since design is not the general problem of science, scientific knowledge (for example, psychology or computer science) cannot be recruited directly to the practice of solving the general problem of design (see Barnard, Grudin & Maclean [1989]). Further, certain attempts to develop complete engineering principles for HCI fail to qualify as such, because they make no reference to ‘…. to perform work effectively’ (Dix & Harrison [1987]; Thimbleby [1984]). Development of the theme indicated there might be no singular conception of the discipline 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 19
knowledge is more typically expressed as principles. If HCI knowledge is limited to theory, and theory is presumed to be that of science, then other conceptions of HCI as a discipline are excluded (for example, Dowell & Long [manuscript submitted for publication]). Finally, generalisation of the Conference theme has identified two conceptions of HCI as a discipline as alternatives to the applied science conception implied by the theme. The other two conceptions are HCI as a craft discipline and HCI as an engineering discipline. 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. They also differ in the practice they espouse to solve the general problem. Craft typically implements, evaluates and iterates (Bornat & Thimbleby [1989]); applied science typically selects guidelines to inform implementation, evaluation and iteration (although guidelines may also be generated on the basis of extant knowledge, e.g. – Hammond & Allinson [1988]); and engineering typically would specify and then implement (Dowell & Long [1988]). 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, costly and slow to develop. The development of the theme and the expression of the conceptions of HCI as a discipline – as craft, applied science and engineering – can usefully be employed to explicate issues raised by, and of concern to, the HCI community. Thus, Landauer’s complaint (Landauer [1987a]) that psychologists have not brought to HCI an impressive tool kit of design methods or principles can be understood as resulting from the disjunction between psychological principles explaining and predicting phenomena, and prescriptive design principles required to guarantee effective performance of work (see Section 3.2). Since research has primarily been directed at establishing the psychological principles, and not at validating the design guidelines, then the absence of an impressive tool kit of design methods or principles is perhaps not so surprising. A further issue which can be explained concerns the relationship between HF and SE during system development. In particular, there is a complaint by SE that the contributions of HF to system development are ‘too little’, too late’ and unemployable (Walsh, Lim, Long, & Carver [1988]). Assuming HCI to be an applied science discipline, HF contributions are too little because psychology does not address the general problem of design and so fails to provide a set of principles for the solution of that problem. HF contributions are too late, because they consist largely of evaluations of designs already implemented, but without the benefit of HF. They are unemployable, because they were never specified, and because implemented designs can be difficult, if not impossible, and costly to modify. Within an HCI engineering discipline, HF contributions would be adequate (because within the scope of the discipline’s problem); on time (because specifiable); and implementable (because specified). Landauer’s plea (Landauer [1987b]) that HF should extend its practice from implementation evaluation to user requirements identification and the creation of designs to satisfy those requirements can be similarly explicated. Lastly, Carroll and Campbell’s claim (Carroll & Campbell [1988]) that HCI research has been more successful at developing methodology than theory can be explicated by the need for guidelines to express psychological knowledge and the need to validate those guidelines formally, and the absence of engineering principles, plus the importation of psychology research methods into HCI and the simulation of good (craft) practice. The methodologies, however, are not methodological principles which guarantee the solution of the design problem (Dowell & Long [manuscript submitted for publication]), but procedures to be tailored anew in the manner of a craft discipline. Thus, relating the conceptions of HCI as a set of possible disciplines provides insight into whether HCI research has been more successful at developing methodologies than theories. 20
In addition to explicating issues already formulated, the development of the Conference theme and the expression of the conceptions of HCI as a discipline raise two novel issues. The first concerns reflexivity both with respect to the general design problem and with respect to the creation of discipline knowledge. It is often assumed that only HCI as an applied scientific discipline (by means of guidelines) and as an engineering discipline (by means of principles) are reflexive with respect to the general design problem. The conception of HCI as a craft discipline, however, has shown that it is similarly reflexive – by means of heuristics. Concerning the creation of discipline knowledge, it is often assumed that only the solution of the general discipline problem requires the reflexive cognitive act – of reason and intuition concerning the objects of activity (Kant [1781]). However, the conceptions of HCI as a craft discipline, as an applied science discipline, and as an engineering discipline suggest that the intial 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 intial generation of albeit different discipline knowledges requires in each case the reflexive cognitive act of reason and intuition. The second novel issue raised by the development of the Conference theme and the conceptions of HCI as a discipline is the relationship between the different conceptions. For example, the different conceptions of HCI and their associated paradigm activities might be considered to be mutually exclusive and uninformative, one with respect to the other. Alternatively, one conception and its associated activities might be considered to be mutually supportive with respect to another. For example, engineering principles might be developed bottom-up on the basis of inductions from good craft practice. Alternatively, engineering principles might be developed top-down on the basis of deductions from scientific theory – both from psychology and from computer science. It would be possible to advance a rationale justifying either mutual exclusion of conceptions or mutual support. The case for mutual exclusion would be based on the fact that the form of their knowledge and practice differs, and so one conception would be unable directly to inform another. For example, craft practice will not develop a theory which can be directly assimilated to science; science will not develop design principles which can be directly recruited to engineering. Thus, the case for mutual exclusion is strong. 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. For example, the design ideas, or heuristics, which formed part of the craft practice of Bornat and Thimbleby in the 1970s (Bornat & Thimbleby [1989]), undoubtedly contributed to Thimbleby’s more systematic formulation (Thimbleby [1984]) and the formal expression by Dix and Harrison (Dix & Harrison [1987]). Although the principles fail to address the effectiveness of work and so fail to qualify as HCI engineering principles, their development towards that end might be encouraged by mutual support from engineering conceptions of HCI. Likewise, scientific concepts such as compatibility (Long [1987]) may indirectly inform the development of principles relating users’ mental structures to the analytic structure of a domain of application (Long [1989]), and even provide an indirect rationalisation for the concepts themselves and their relations with other associated concepts. Mutual support of conceptions, as opposed to mutual exclusion, has two further advantages. First, it maximises the exploitation of what is known and practised in HCI. The current success of HCI is not such that it can afford to ignore potential contributions to its own advancement. Second, it encourages the notion of a community of HCI superordinate to that of any single discipline conception. The novelty and complexity of the enterprise of developing knowledge to support the solution of the general problem of designing humans and computers interacting to perform work effectively requires every encouragement for the establishment and maintenance of such a community. Thus, the mutual support of different conceptions of HCI as a discipline is recommended. 21
References J R Anderson [1983], The Architecture of Cognition, Harvard University, Cambridge MA. P Barnard, J Grudin & A Maclean [1989], “Developing a Science Base for the Naming of Computer Commands”, in Cognitive Ergonomics and Human Computer Interaction, J B Long & A D Whitefield, eds., Cambridge University Press, Cambridge. R Bornat & H Thimbleby [1989], “The Life and Times of Ded, Text Display editor”, in Cognitive Ergonomics and Human Computer Interaction, J B Long & A D Whitefield, eds., Cambridge University Press, Cambridge. P Buckley [1989], “Expressing Research Findings to have a Practical Influence on Design”, in Cognitive Ergonomics and Human Computer Interaction, J B Long & A D Whitefield, eds., Cambridge University Press, Cambridge. J M Carroll & R L Campbell [1988], “Artifacts as Psychological Theories: the Case of Human Computer Interaction”, IBM research report, RC 13454(60225) 1/26/88, T.J. Watson Research Division Center, Yorktown Heights, NY. 10598. R N Charette [1986], Software Engineering Environments, Intertexts Publishers/McGraw Hill, New Y ork. F I M Craik & R S Lockhart [1972], “Levels of Processing: A Framework for Memory Research”, Journal of Verbal Learning and Verbal Behaviour, 11, 671-684. A J Dix & M D Harrison [1987], “Formalising Models of Interaction in the Design of a Display Editor”, in Human-Computer Interaction – INTERACT’87, H J Bullinger & B Shackel, (ed.s), North- Holland, Amsterdam, 409-414. J Dowell & J B Long [1988], “Human-Computer Interaction Engineering”, in Designing End-User Interfaces, N Heaton & M Sinclair, eds., Pergamon Infotech, Oxford. J Dowell & J B Long, “Towards a Conception for an Engineering Discipline of Human Factors”, (manuscript submitted for publication). P Gilligan & J B Long [1984], “Videotext Technology: an Overview with Special Reference to Transaction Processing as an Interactive Service”, Behaviour and Information Technology, 3, 41-47. N Hammond & L Allinson [1988], “Development and Evaluation of a CAL System for Non-Formal Domains: the Hitchhiker`s Guide to Cognition”, Computer Education, 12, 215-220. N Hammond [1987], “Principles from the Psychology of Skill Acquisition”, in Applying Cognitive Psychology to User-Interface Design, M Gardiner & B Christie, eds., John Wiley and Sons, Chichester. I Kant [1781], The Critique of Pure Reason, Second Edition, translated by Max Muller, Macmillan, London. D Kapur & M Srivas [1988], “Computability and Implementability: Issues in Abstract Data Types,” Science of Computer Programming, Vol. 10. T K Landauer [1987a], “Relations Between Cognitive Psychology and Computer System Design”, in Interfacing Thought: Cognitive Aspects of Human-Computer Interaction, J M Carroll, (ed.), MIT Press, Cambridge MA. 22
T K Landauer [1987b], “Psychology as Mother of Invention”, CHI SI. ACM-0-89791-213- 6/84/0004/0333 J B Long [1989], “Cognitive Ergonomics and Human Computer Interaction: an Introduction”, in Cognitive Ergonomics and Human Computer Interaction, J B Long & A D Whitefield, eds., Cambridge University Press, Cambridge. J Long [1987], “Cognitive Ergonomics and Human Computer Interaction”, in Psychology at Work, P Warr, eds., Penguin, England. J M Mandler [1979], “Categorical and Schematic Organisation in Memory”, in Memory Organisation and Structure, C R Puff, ed., Academic Press, New York. H H Pattee [1973], Hierarchy Theory: the Challenge of Complex Systems, Braziller, New York. K R Popper [1959], The Logic of Scientific Discovery, Hutchinson, London. D Scott [1976], “Logic and Programming”, Communications of ACM, 20, 634-641. H Thimbleby [1984], “Generative User Engineering Principles for User Interface Design”, in Proceedings of the First IFIP Conference on Human-Computer Interaction, Human-Computer Interaction – INTERACT’84. Vol.2, B Shackel, ed., Elsevier Science, Amsterdam, 102-107. E Tulving [1972], “Episodic and Semantic Memory”, in Organisation of Memory, E Tulving & N Donaldson, eds., Academic Press, New York. P Walsh, K Y Lim, J B Long & M K Carver [1988], “Integrating Human Factors with System Development”, in Designing End-User Interfaces, N Heaton & M Sinclair, eds., Pergamon Infotech, Oxford. Acknowledgement. This paper has greatly benefited from discussion with others and from their criticisms. In particular, we would like to thank: Andy Whitefield and Andrew Life, colleagues at the Ergonomics Unit, University College London; Charles Brennan of Cambridge University, and Michael Harrison of York University; and also those who attended a seminar presentation of many of these ideas at the MRC Applied Psychology Unit, Cambridge. The views expressed in the paper, however, are those of the authors. 23

 

Applying the Conception of HCI Engineering to the Design of Economic Systems 150 150 admin

Applying the Conception of HCI Engineering to the Design of Economic Systems

Applying the conception of HCI engineering to the design of economic systems

Ian K. Salter

JP Morgan Chase & Co.,1 60 Victoria Embankment, London EC4Y 0JP, United Kingdom

 

 

John Long's Comment 1 on this Paper

I have known Ian Salter, since the early nineties. He came to UCL to study for a PhD with me, following a period as a lecturer in Computer Science with an interest in graphical languages. His thesis was entitled: ‘The Design of Formal Languages’ (not a modest undertaking). It is still unclear to me who supervised whom. Ian subsequently worked as a research fellow and together with John Dowell, we researched task-oriented modeling in the domain of air traffic management (1992). Ian’s analytic strengths are of the highest order and I am delighted that he has carried forward ideas from these earlier days into their application to the design of economic systems, his festschrift contribution. Although I had ample opportunity to provide feedback on earlier versions of the article, as kindly acknowledged by Ian, I have made quite a few comments here with the intention of linking up a range of issues, appearing across the Festschrift, as a whole.

Abstract

The Long and Dowell conception for HCI design (Long and Dowell, 1989) outlined the general design problem for HCI and contrasted between applied science and engineering disciplines of HCI. Salter (1995) sought to clarify the applied science conception through the application of Kuhn’s conception of science. Salter also built upon the work of Long and Dowell to produce a generic conception of engineering design. As part of this work the notion of preference was formalized. Building upon the generic conception a set of criterion for an engineering discipline is established. A general design problem for economics is outlined in order to apply the generic conception to the field of economics. Roth’s (2002) implicit conception of economic engineering is analyzed against the criterion and the formalized notion of preferences and found to be a consistent but not complete example of an engineering discipline. The general problem of economic design, based upon Long and Dowell’s approach, is employed to analyze a regulatory response (Turner, 2009) to the global financial crisis of 2007+ and develop a design-based solution to the problems. It is argued that the current applied science based responses to the economic crisis are insufficient and that a multi disciplinary engineering approach is necessary. This approach includes consideration of how economic participants interact with computers as part of the financial system.

Reprinted by permission of JPMorgan Chase & Co. 2009. JPMorgan Chase & Co. All rights reserved.

Acknowledgement: This paper would not have been possible without the aid of Professor John Long, who spent many hours of his time reading and discussing drafts. The errors contained within are however the author’s alone.

E-mail addresses: ianksalter@gmail.com, ian.salter@jpmorgan.com ((The author is not necessarily representing the views or opinions of JPMorgan Chase & Co.))

 

1. Introduction

In 1989 John Long and John Dowell (Long and Dowell, 1989) outlined different conceptions for HCI disciplines based upon the general problem the discipline seeks to address, and the consequent knowledge and practices that arise. Engineering disciplines have problems of design whereas scientific disciplines have problems of understanding and prediction. They conclude that in order to address the design problems of HCI an engineering discipline of HCI is required. The Long and Dowell conception took the form of a set of concepts that were used to structure work on HCI design.

Comment 2

Long and Dowell (1989) characterized three different possible conceptions for HCI – Craft, Applied Science and Engineering. They concluded that an Engineering Conception of HCI, although demanding considerable resources for its development, would offer more effective solution of design problems, than the other conceptions. Its design knowledge, in the form of Principles, would offer a better guarantee, than either Craft or Applied Science design knowledge. The latter’s address of HCI problems, however, even though less effective then Engineering, was explicitly acknowledged by Long and Dowell.

The economist Alvin Roth, with respect to the field of economics, expresses similar thoughts:

‘Economists have lately been called upon not only to analyze markets, but to design them. Market design involves a responsibility for detail, a need to deal with all of a market’s complications, not just its principle features. Designers therefore cannot work only with the simple conceptual models used for theoretical insights into the general working of markets. Instead, market design calls for an engineering approach’ (Roth, 2002).

Roth outlines an implicit conception of economic engineering through the analysis of the redesign of the entry-level labor market for American doctors.

Salter (1995) developed a generic conception for engineering design, based on the Long and Dowell approach. In what follows this conception is extended through the addition of a number of criteria that a discipline should fulfill to claim it is an engineering discipline in the sense of Long and Dowell. The generic conception is then instantiated for economics through the postulation of a general design problem for economic engineering.

Through consideration of the American doctors labor market redesign, Roth’s implicit conception is analyzed with respect to the postulated general problem and the generic engineering conception. The aims of this analysis are:

  • To validate the postulated general problem of economic design.
  • To assess the consistency and completeness of Roth’s implicit conception with respect to the generic engineering conception.

Roth’s conception for economic design is restricted to the consideration of microeconomics and the design of individual markets. The continuing global financial crisis that began in 2007, and continued into 2008 causing considerable financial upheaval, has pushed the discipline of Economics to the forefront of public debate. It seems clear to many that some form of macro-economic redesign of the global financial system is necessary to ensure both economic revival and that such a crisis cannot happen again.

The UK Financial Services Authority (FSA) proposes a number of changes to the financial system through the Turner review (Turner, 2009). The postulated general design problem for economic engineering is used to analyze the Turner review. A simple redesign of the global financial system is proposed. The aims of this analysis and redesign are:

To consider the value of the use of the postulated general design problem in specific instances of design, even when the knowledge and practice of an engineering discipline are unavailable.

To illustrate that a design focused approach is of value in addressing the current crisis.
By considering these micro and macro instances of economic redesign it is argued that an discipline of economic engineering, of the type envisage by Long and Dowell for HCI, is required in order to provide solutions to economic design problems. It is further argued that economic engineering would draw practitioners from other disciplines and that those with a background in HCI will have a key part to play.

2. The conception of HCI design

Long and Dowell (1989) considers different possible conceptions for the discipline of HCI. Each type of discipline is characterized by three components:

  • Knowledge.
  • Practice.
  • General problem.

Knowledge is used to support practice aimed at solving the general problem of a discipline. For the discipline of HCI the scope of the general problem is identified as:

‘humans and computers interacting to perform work effectively’ (Long and Dowell, 1989).

The scope of the general problem (see Fig. 1) is extended in another paper (Dowell and Long, 1989). The human and computer interacting together are thought of as an interactive worksystem. The concept of effective work is captured by the notion of desired worksystem performance, which is expressed in terms of both the desired quality of work and the costs of the human and computer components of the worksystem that are incurred in doing the work. Interactive worksystems exhibit actual performance, which is a function of the actual quality of work done by the worksystem and the actual costs incurred.

Fig. 1. The general problem for human computer interaction.

 

Comment 3

Salter has well understood Long and Dowell’s (1989) conception of the scope of the general HCI problem as: ‘humans interacting to perform work effectively’ and its development in Dowell and Long (1989). However, in Figure 1 – The General Problem for HCI – ‘effectiveness’ is not explicitly represented. The same, it must be said, of Figure 2 in Long and Dowell (1989) and in Figure 3 in Dowell and Long (1989). The latter, however, is acceptable, as Figure 3 is intended only to show the fundamental distinctions between interactive worksystem and domains (of application). Figure 3 is an adaptation of Figure 2. A complete representation, however, of ‘humans interacting with computers to perform work effectively’ appears in Dowell and Long (1998), Figure 1, entitled ‘Worksystem and Domain’. Here, Performance is expressed as Task Quality (how well the work is performed), emanating from the Domain and User Costs (workload incurred in performing the work that well), emanating from the Worksystem. As Effectiveness is part of the core conception of HCI (and Salter recognizes it as such), it must be assumed implicit in Salter’s Figure 1. The inclusion is important for Salter’s subsequent pull-through of Long and Dowell (1989) and the Dowell and Long (1989; 1998) Conceptions into his application thereof to the engineering of economic design.

The same comment can also be made with respect to Figure 3, The Applied Science Conception of HCI and Figure 5, the Engineering Conception of HCI.

 

The Long and Dowell paper (Long and Dowell, 1989) outlined three different conceptions of the discipline of HCI, distinguished by the nature of their knowledge and practices. These conceptions are:

  • Craft.
  • Applied science.
  • Enginering.

In what follows, the applied science and engineering conceptions from Long and Dowell (1989) are considered and illustrated with figures from Salter (1995). The nature of the knowledge and practices that correspond to each conception are considered in terms of their definition, operationalization, testability, and generalization.

Comment 4

If ‘conception’ is equated with ‘definition’, then Salter’s ‘definition; operationalisation; test; and generalisation’ equates with Long’s expression of validation (1997). The three different possible conceptions of HCI – Craft, Applied Science and Engineering (Long and Dowell, 1989) all require such validation of their knowledge, practices and relations with respect to their acknowledged ‘discipline problem’.

 

The term definition is employed to mean the explicit definitions of the knowledge and practices. Operationalization is the transformation of the definitions of the knowledge and practices into a form that can be used and tested. The testing of the knowledge and practices is aimed at determining how well they support the general problem. Finally, knowledge and practices are general if they can be applied to more than one instance of the general problem. that correspond to each conception.

Comment 5

Long and Dowell (1989) claim that: ‘the ‘public’ knowledge possessed by HCI, as a Craft discipline, is not operational. That is, because it is either implicit or informal…..’ In other words, craft knowledge and practices can be defined; but only informally or implicitly. They are not defined/conceived explicitly. Hence, also not operationalisable, testable or generalisable (see also Comment 4).

2.1. Applied science conception

The conception of an applied science design discipline describes a practice in the form of ‘specify and implement and test’ and knowledge in the form of ‘guidelines’. In the applied science conception of design, artifacts are still designed by a process of construction and evaluation and reconstruction. However, knowledge in the form of guidelines, derived from scientific knowledge, is used to guide the process. The conception of HCI as an applied science discipline is represented in Fig. 2.

Comment 6

See Comment 5.

Screen shot 2014-12-16 at 15.53.36

By considering examples of HCI as an applied science discipline, Long and Dowell conclude that the knowledge and practices of HCI as an applied science are derived from scientific theories that are operationalized, tested and generalized. However, the knowledge and practices themselves are not operationalized, tested and generalized with respect to the general problem of HCI. The limited account given of the relationship between scientific knowledge and applied science design in Long and Dowell (1989) was not well understood at the time. Salter (1995) attempted to clarify what was meant through consideration of Thomas Kuhn’s (1970) conception of science (see Fig. 3).

 

 

Fig. 3. Kuhn and applied science.

In Kuhn’s view, a scientific discipline may be conceived of as a framework that contains the following elements:

  • Paradigm.
  • Disciplinary matrix.
  • Shared exemplars.

For Kuhn, the history of a scientific discipline cycles through two distinct stages.

The shortest phase is the crisis period. During this period the symbolic generalizations, metaphysical assumptions and system of values that form the disciplinary matrix are in question. Rival positions abound until one begins to dominate.

At this point, the discipline moves into a period of normal science. During normal science the scientific community holds a consensus view concerning the disciplinary matrix. Scientists may solve scientific problems within the paradigm of shared exemplars. The shared exemplars, consisting of theory predictions, are developed until such time as it becomes increasingly difficult to develop exemplars whose theory predictions accord with perceived phenomena. At this point a period of crisis ensues.

The relationship between Kuhn’s conception of science and Long and Dowell’s conception of applied science is presented in Fig. 3.

Disciplines of different types attempt to solve different design problems. Scientific disciplines attempt to solve the problems of understanding, whereas engineering disciplines attempt to solve the problem of design. Transforming discipline knowledge and practices that have been operationalized, tested and generalized with respect to the scientific problem of understanding, does not necessarily lead to knowledge that can be operationalized, tested or generalized with respect to the engineering problem of design.

2.2. Engineering conception

The conception of an engineering design discipline describes a practice in the form of ‘specify then implement’ and knowledge in the form of ‘principles’. In the engineering conception of design, artifacts are designed by a process of specification, followed by a process of implementation. The process is supported by knowledge in the form of principles. The application of principles to the design process provides a guarantee that the artifact will satisfy the client’s requirements. The conception of HCI as an engineering discipline is represented in Fig. 4.

Comment 7

See Comments 5 and 6.

 

Fig. 4. The engineering conception of HCI.

The knowledge and practices of an engineering discipline are defined, operationalized, testable and generalizable.

The Long and Dowell (1989) conception assumed that HCI was essentially in a Kuhnian crisis period and the 1989 paper can be viewed as an attempt to establish disciplinary matrix, albeit one based on an Engineering approach. Salter (1995) took this work further by establishing a generic conception of an engineering discipline.

3. A generic conception of engineering design

Salter (1995) built upon the work Dowell and Long as well as Kuhn to build a generic conception of engineering design. In what follows this generic conception has been extended to include a set of criteria to which any specific conception should correspond in order to satisfy the generic conception of design.

3.1. Disciplinary matrix and scope of the general problem

Recall that Kuhn’s notion of a disciplinary matrix consists of symbolic generalizations, metaphysical assumptions and systems of values of the discipline. By introducing notions of desired performance and interactive worksystems exhibiting actual performance, Long and Dowell are explicitly outlining some of the metaphysical assumptions and systems of values of the discipline of HCI. Thus, describing the scope of a discipline problem amounts to providing two of the three components of a disciplinary matrix.

Comment 8

According to Dowell and Long (1989), Kuhn’s first element of the discipline matrix is a ‘shared commitment to models, which enables a discipline to recognize its scope or ontology….’ For Cognitive Engineering (here read HCI) ‘we may interpret this requirement as the need to acquire a conception of the nature and scope of cognitive  (HCI) design problems’ (a Conception to be found in Dowell and Long (1989 and 1998)).

Kuhn asserts that the value of knowledge is in its usefulness in solving problems. According to Salter (1995) design problems have two key components: the requirements component and the artifact component. The requirements component is the ‘what’ of the design problem. In Long and Dowell’s terms the requirements component is the desired performance of the interactive worksystem. The artifact component represents the ‘how’ of the design problem. In Long and Dowell’s terms, the artifact component is the interactive worksystem together with the actual performance it exhibits.

Comment 9

Salter’s proposes to characterize the two key components of design problems as the ‘requirements’ component (equated in Long and Dowell’s (1989) conception with ‘desired performance’) and the ‘artefact’ component (equated to the ‘interactive worksystem, together with the actual performance it exhibits’). In so doing, however, it should be remembered that for Dowell and Long (1989 and 1998), Performance is made up of two elements. The first, related to the Domain (of work) is ‘Task Quality’ – how well the work is performed. The second, related to the Interactive Worksystem, is the (Resource) Costs (both those associated with the User and with the Computer), incurred in performing the work that well. (See also Comment 3). There is a need, then, to identify the Costs element somewhere in the Requirements/Artefact dualism.

 

Any conception of an engineering discipline of design must describe the scope of the general problem. This leads to the first criterion.

Criterion 1: The description of the general problem should describe the requirements component and the artifact component of the problem and the nature of the relationship between them.

3.2. The phenomena of design

The shared exemplars of Kuhn’s framework are grounded in perceived phenomena. ((The use of the word phenomena here is used to refer to an observable occurrence.So Kuhn was stating that shared exemplars must be consistent with observable occurrences. Salter (1995) was claiming that there are a set of observable occurrences associated with client requirements and a set of observable occurrences associated with an artifact.))

Salter (1995) distinguishes two types of phenomena associated with design problems, the phenomena associated with the requirements component and the phenomena associated with artifact component (see Fig. 5).

 

 

Fig. 5. Design phenomena.

The phenomena associated with the requirements component of the design problem are called the client requirements. A client here refers to an individual, or an organization whose requirements may consist of the, possibly conflicting, requirements of sub-organizations and individuals. The phenomena associated with the artifact component of the design are termed the artifact. For any design problem it is necessary that there be practices for determining whether artifacts fulfill or satisfy client requirements. These practices are termed empirical since they apply to phenomena. The term empirical derivation is used to describe a practice for developing an artifact from client requirements and the term empirical validation is used to describe a practice for determining if an artifact satisfies client requirements.

Figs. 1 and 5 can be combined to create a re-expression of the HCI design problem in terms of requirements and artifact ((Some commentators are unhappy with identifying the domain solely as part of client requirements, arguing that the artifact would also need to include the domain as the domain may be redesigned to improve performance. However such a modification of the domain can also be perceived as a modification of the requirements that is outside of the scope of the HCI problem.)) (see Fig. 6).

The success of any engineering discipline depends upon its ability to support the design of artifacts that satisfy client requirements. This leads to criterion 2:

Criterion 2: The conception of any discipline of design must have a set of empirical practices for establishing the relationship between artifact and client requirements.

Comment 10

Salter proposes a generic conception of Engineering Design (Section 3) to support the specification of the General design problem of economic systems, as a special case of engineering design. Because the Generic Conception is of Design and because most HCI researchers associate their work with design (directly or indirectly), the generic Conception can be used to unify and to differentiate approaches to HCI design.

First, according to Salter (Section 3), the scope of the generic Conception has ‘two key components: the Requirements Component and the Artefact Component’ and the relations between them (Criteria 1). Allowing for differences in terminology (for example, ‘need’ for ‘requirements’, ‘computer’ for ‘artefact’ and ‘relationship’ for ‘relations’, all the approaches to HCI design, represented by the contributions to the Festschrift, would appear to agree on this scope for HCI, that is, Requirements and Artefact (see Sutcliffe and Blandford; Carroll; Dix; Wild; Hill; and Long – all 2010).

Second, according to Salter (Section 3.2 and Figure 5). The phenomena of design of the Generic Conception are: Client Requirements (associated with the Requirements component); the Artefact (associated with the Artefact component); and the Empirical Derivation (of the Artefact from the Client Requirements) and the Empirical Validation (of the Client Requirements by the Artefact) (expressing the relations between Client Requirements and the Artefact). Again, allowing for differences in terminology, for example, ‘user requirements’ for client requirements’; ‘technology’ for ‘artefact’ and ‘test’ for ‘validation’, all the approaches to HCI design, represented by the contributions to the Festschrift, would appear to accept these phenomena for HCI, that is, Client Requirements; Artefact; and their Empirical Derivation and Empirical Validation relations (Sutcliffe and Blandford; Carroll; Dix; Wild; Hill and Long – all 2010).

In conclusion, then, all the contributors to the Festschrift, representing various approaches to HCI design (for example, scientific (Sutcliffe and Blandford); Craft and Applied Science (Carroll); design and scientific (Dix); scientific and engineering (Wild); and engineering (Hill) would appear to agree on the basic scope and the phenomena of Salter’s Generic Conception of Engineering Design, as applied to HCI design. To this extent, approaches to HCI design might be considered to be unified with respect to scope and phenomena.

3.3. Design practice exemplars

Lying between the disciplinary matrix and phenomena in Kuhn’s framework is the concept of the paradigm of shared exemplars. For a scientific discipline, the general problem is one of understanding by means of explanation and prediction. Thus Kuhn’s exemplars form understanding as explanations and predictions. Long and Dowell (1989) stated that for an engineering discipline, the general problem is one of design. Salter (1995) concluded from this that one form of shared exemplars are design examples representing abstractions of client requirements and artifacts and the relationships between these abstractions. (see Fig. 7).

Salter (1995) termed the abstraction of client requirements the specific requirements specification, whereas the abstraction of artifact was called the specific artifact specification. The term ‘Specific’ is used since these abstractions are specific to the particular design problem being considered. Salter (1995) stipulated that the relationship between specific requirements specification and specific artifact specification should be formal. This gives rise to criterion 3.

Criterion 3: The conception of any discipline of design must have each of the following:

  • a) A set of empirical practices for establishing the relationship between client requirements and specific requirements specification.
  • b) A set of empirical practices for establishing the relationship between artifact and specific artifact specification.
  • c) A set of formal practices for establishing the relationship between specific requirements specification and specific artifact specification.

Comment 11

Salter’s Generic Conception of Engineering Design includes the concept of Design Practice (termed exemplars, following Kuhn (1970) – see Section 3.3 and Figure 7). Design Practice assumes, and is built on, the scope and phenomena of Engineering Design (see Comment 10). The Specific Requirements Specification is empirically derived from the Client Requirements and empirically validates them. The Specific Artefact Specification is empirically derived from the Artefact and validates it. In addition, however, Design Practice requires the Formal Derivation of the Specific Artefact Specification from the Specific Requirements Specification and the Formal Verification of the latter by the former.

The requirement for formal derivation and verification relations between the Specific Requirements and Artefact Specifications generally excludes the approaches to HCI design of the Festschrift contributors not committed to Engineering Design. The only contribution reporting something approaching a Design Practice Exemplar, consistent with Salter’s conception, is that of Hill. Her models and method are ‘explicit’ and intended ‘to support design directly’.

However, even in her case, there must be some doubts, at this stage of her research. First, according to Hill, the models and method support design problem diagnosis ‘directly’; but design solution prescription only ‘indirectly’. Second, it remains to be seen to what extent in the longer term explicit equates to formal, in the case of Hill’s models and method. Hill herself considers her models and method support less well than ‘validated engineering design principles’, as proposed by Dowell and Long (1989). ‘Less well’ here might be understood as less formally.

Dowell and Long (1989) are in no doubt, that such HCI engineering principles would be formal and support ‘specify then implement’ design practice. In term’s of Salter’s generic conception, the principles would support the formal derivation of the design solution (Specific Artefact Specification) from the design problem (Specific Requirements Specification) and the formal verification of the latter by the former. Subsequent attempts to develop HCI engineering design principles have included the required formality of the relations between design problem and design solution (Stork, 1999; Cummaford, 2007).

 

3.4. Design research exemplars

For a scientific discipline, Long and Dowell (1989) believed that the practice of the discipline is the research that aims to construct and validate knowledge that supports understanding in the form of explanation and prediction. Salter (1995) claimed that for an engineering design discipline, whose knowledge is defined, operationalized, tested and generalized with respect to the problem of design, there is a distinction between practice and research. Engineering practice involves employing engineering knowledge to solve specific design problems, whereas engineering research involves the construction and validation of engineering knowledge.

Thus, for an engineering discipline, Salter (1995) claimed that there is an alternative but equivalent of Kuhn’s shared exemplars, that is, examples of engineering research. Since engineering research constructs and validates knowledge that is defined, operationalized, tested and generalized with respect to the problem of design, engineering research exemplars consist of abstractions of specific requirements specification and specific artifact specification and the relationships between them (see Fig. 8).

Salter (1995) termed the abstraction of the specific requirements specification the general requirements specification, whereas the abstraction of the specific artifact specification was called the general artifact specification. The term ‘General’ was used, since these abstractions are general to particular classes of design problems. The relations between all abstractions are formal. This gives rise to criterion 4.

Criterion 4: The conception of any discipline of design must have each of the following:

  • a) A set of formal practices for establishing the relationship between specific requirements specification and general requirements specification.
  • b) A set of formal practices for establishing the relationship between general requirements specification and general artifact specification.
  • c) A set of formal practices for establishing the relationship between general artifact specification and specific artifact specification.

 

Fig. 6. The re-expression of the HCI design problem.

Comment 12

Figure 6 re-expresses the HCI design problem in terms of Client Requirements and Artefact. However, there is no explicit expression of ‘effectiveness/performance’ (see Comment 3) or Task Quality and Worksystem Costs (see Comment 9). To the extent that Salter is pulling through these concepts into his conception, they are presumably implicit in his Figure 6.

 

 

Fig. 7. Design practice exemplars.

 

 

Fig. 8. Design research exemplars.

 

Salter’s (1995) generic conception of an engineering discipline has now been outlined and extended with a set of criteria that any specific instance of an engineering discipline should meet. In order to instantiate the generic conception for engineering design for a discipline of economic engineering it is necessary to postulate the general design problem for economic systems.

Comment 13

Salter’s Generic Conception of Engineering Design, as well as the concept of Design Practice, includes the Concept of Design Research (also termed exemplars, following Kuhn (1970) – see Section 3.4 and Figure 8). Research practice assumes, and is built on, Design Practice (see Comment 11), which in turn assumes, and is built on, the scope and Phenomena of Engineering Design (see Comment 10). In addition, however, Research Practice requires the formal derivation of the General Requirements Specification from the Specific Requirements Specification and the formal verification of the latter by the former, together with the formal derivation of the General Artefact Specification from the Specific Artefact Specification and the formal verification of the latter by the former. Further, the General Artefact Specification is formally derived from the General Requirements Specification and the formal verification of the latter by the former.

Failure to espouse the Design Practice Exemplar of the Generic Conception of Engineering Design, by approaches to HCI design other than Engineering, necessarily entails the failure to espouse the Design Research Exemplar. Indeed, doubly so, as all derivation and verification relations in the Research Practice Exemplar are formal. Hill would appear to be the only exception among Festschrift contributors. With the reservations, expressed in Comment 11, Hill’s putative Design Practice Exemplar is embedded in her research, as required by the Generic Conception of Engineering Design. Further, formal relations in her Design Practice would support formal relations in Research practice. This would be consistent with Hill’s claim concerning validated engineering design principles, that would support ‘the design of general solutions to general classes of HCI design problems’, as proposed by Dowell and Long (1989). The latter are in no doubt that HCI engineering design principles research would necessarily require formal research relations to support formal ‘specify then implement’ design practice.

Subsequent attempts to develop HCI engineering design principles have embedded design practice in research practice (Stork, 1999; Cummaford, 2007). They have also espoused the actual (Stork, 1999) or desired (Cummaford, 2007) formal relations for both, as required by Salter’s Generic Conception of Engineering Design.

In conclusion, then, all approaches to HCI design would appear to accept the Scope and Phenomena of design, as expressed in Salter’s Generic Conception of Engineering Design (including the Festschrift contributors). Unsurprisingly, only approaches with a commitment to HCI engineering design are (or might be) consistent with the Conception’s expression of Design and Research Practice. However, the Conception still has a unifying potential for HCI design in that given the same Scope and Phenomena, alternative conception components, levels of expression and relations are possible.

4. The general design problem for economic systems

The general design problem for economic systems must have a clearly defined scope with the problem expressed in terms of requirements and artifact. Fig. 9 modifies Fig. 6 for application to the problem of the design of economic systems:

 

 

Fig. 9. The general design problem for economic systems.

Economic agents interacting together within a regime ((Regime here is used to denote a set of regulations. This set may be empty as in thecase of illegal markets such as the black economy or illicit drug dealing. Even foreconomic systems such as these there may however, be implicit regulation – it is notnormally considered good business for drug dealers to kill their clients en mass–eventhe death of one client is likely to attract unwanted attention of the authorities)) of regulation are thought of as an economic system, the artifact. The agents of the economic system are further distinguished into clients, whose requirements the system seeks to serve, and non-client agents. Agents may include human, organizations, software systems, making economic design a cross-disciplinary activity.

The concept of effective work is captured by the notion of desired economic system performance, which is expressed in terms of client preference. Client preferences are expressed with respect to a work transformation. Client preferences may be common across all clients of the economic system or may be specific to a particular client group.

The notion of economic systems doing work is somewhat novel but central to the notion of economic engineering being expounded here. It is illustrated in the macro and micro economic discussions in Sections 5 and 6.

A standard table format is used to describe economic requirements in terms of work transformation and client preferences. This format is given in Table 1.

A standard table format is also used to describe an economic system. This format is given in Table 2.

Domain
Work transformation
Describes the work done by the economic system in terms of some work transformation of objects
Client preferences
Describes preferences of particular groups of clients
Common preferences
Describes preferences common to all clients

Table 1: Standard format for an economic design problem.

Economic system: sample system
Clients
Describes the clients that form part of the economic system. There should be a correspondence between the clients listed here and the client preferencess
Non-client agents
Describes any non-client agents that are part of the system and the roles that they play
Regulation
Describes any regulation that is part of the economic system

Table 2: Standard format for an economic system.

Economic system worksystems exhibit actual performance, which is a function of how the work transformation achieves client preferences.

4.1. Formalizing client preferences

From the generic engineering conception the specific and general requirements specification for economic systems should be presented formally. In order to achieve this the notion of desired performance and hence client preferences must be expressed formally.

Traditionally in economics and game theory (Osbourne and Rubinstein, 1999) the preferences have been stated using a utility function or the slightly weaker notion of a linear ordering. Utility functions assign a real number to the occurrence that forms the actual performance of the worksystem. Liner orderings insist that all actual work system performances can be ranked along the real line, insisting therefore that it is possible to state for each actual performance, which is preferred. Work on bounded rationality (Simon, 1957) indicates that both of these notions are too strong. Clients are unlikely to be able to assign a number to actual worksystem performance and equally as unlikely to be able to rank all such performances.

Salter (Salter (1995)) introduced the notion of preference ordering, based upon mathematical pre-orders to address this issue. Linear orderings and utility functions are special cases of preorderings.

A pre-ordering hS, 6i is a set S together with a relation 6 over S such that for all a, b, and c in S:

  • a 6 a (reflexivity)
  • if a6b and b6c then a6c (transitivity)

A preference ordering hS, 6, Pi is a pre-ordering hS, 6i together with a subset of S, P of preferences, such that for any a and b in S:

  • if aeP and a6b, then beP

Client preferences may be expressed as a preference ordering over the work transformations that are carried out by the economic system.

Work (Salter, 1995, 1993) indicates that Mathematical Category Theory (MacLane, 1998; Lawvere and Schanuel, 1987), of which the Theory of Orderings can be considered a part, may be an appropriate formalism for expressing some class of engineering design problems.

The generic conception of engineering design has been outlined and instantiated through the postulation of the general design problem from economic systems. Given this statement of the general problem and equipped with the tool of preference orderings it is possible to analyze the entry-level market for American doctors and Roth’s implicit conception of economics engineering.

Comment 14

Salter has pulled through into his expression of the General Design Problem for Economic Systems a number of concepts from the Conception of Long and Dowell (1989). Some concepts, like Desired Performance, seem to preserve their original meaning. Other concepts, however, like User Costs seem not to preserve their original meaning. Readers should be aware of these differences.

5. The entry-level labor market for American doctors

Traditionally the role of the majority of economists has been to understand and predict aspects of economic systems, thus playing the role of scientists according to the conception of Long and Dowell. Increasingly however economists are becoming actively involved in the construction of economic systems including the design of markets for electric power (Wilson, 2009), airwave spectrum auctions (Milgrom, 2000) and labor markets for entry-level doctors (Roth, 2002; Roth and Peranson, 1997) Thus economists are increasingly playing the role of designer.

An example of the economic design of the entry-level labor market for American doctors reported by Roth (2002) is considered. The concept of residency programs (then called medical internships) began in the 1900s. Newly graduated doctor’s work as residents in hospitals to complete their training. The work of the economic system is to match doctors to residency programs within hospitals. The matching should take account of doctor’s preferences for residency programs and the residency program’s preference for doctors.

Table 3 uses the standard table format for the domain to describe the economic design problem.

The domain described is, by necessity, a simplification ((The requirements are also simplified to aid exposition. For example medicalschools could have been included as participants in an attempt to capture the effortexpended by them in supporting medical student)) of requirements that have evolved over time. The rationale behind the common preferences aspects of the domain may not appear immediately clear. However a discussion of the history of the problem will provide this rationale.

The initial economic system operated a decentralized model with no major regulations (see Table 4).

This system worked well initially but competition amongst hospitals for medical students led to appointments of doctors to positions up to 2 years prior to taking up the residency position. This was not considered satisfactory, leading to the requirement given by the first common preference that the matching should occur in the doctor’s final undergraduate year. Thus justifying common preference (a). This led to a revised economic system (Table 5) in which additional regulations were imposed upon passing student information and date of appointments.

Domain
Work transformationTo match newly qualified doctors to resident programs. Where resident programs consist of a number of available residency positionsClient preferences

  • Doctor
  • For residency programs
  • Residency programs
  • Preferences for doctor

Common preferences

  • a) The matching between doctors to programs should not happen earlier than the final year of the doctors undergraduate program
  • b) The matching should occur in a reasonable time, say tbeforeResidency,
    before the doctor is due to start the residency
  • c) The matching should be simple for the doctors, not occupying more
    than, say rdoctors, of the doctor’s resources
  • d) The matching should be simple for the residency programs, not occupying more than, say rresidencyProgram, of residency program’s resources
  • e) The matching should occur consistently throughout the year, with not
    more than say m matches occurring in any one month
  • f) The match should be stable in the sense that it should not be possible to produce a different match that better meets both doctor’s and residency program’s preferences

Table 3: The design problem for the entry-level doctors market.

Economic system: decentralized model (1900)
Clients

  • Doctors applying for advertised positions
  • Resident Programs advertising positions and selecting doctors through a waiting list system

Non-client agents

  • No major ones except for advertising outlets, etc. Regulation
  • None

Table 4: The doctor matching system 1900s–1940s.

Economic system: decentralized model (1945)
Clients

  • Doctors applying for advertised positions
  • Resident programs advertising positions and selecting doctors through
    a waiting list system

Non-client agents

  • No major ones except for advertising outlets, etc.

Regulation

  • Dates references and transcripts could be sent restricted
  • Contracts cannot be signed till last year of study

Table 5: The doctor matching system 1945.

The new system led to further problems as doctors receiving an offer from one residency program held off accepting until they had heard from a preferred program. This led to slow movement of waiting lists and lots of last minute matching which was also considered unacceptable. This was not considered satisfactory thus justifying common preferences (b)–(e). This led to the development of a centralized clearing system in 1951 (see Table 6).

The centralized clearing system worked well until the 1970s but actual performance degraded until the 1990s. Many issues were raised, in particular as to whether the matches produced were considered optimal. Thus leading to common preference (f). To address these needs, the National Resident Matching Program (NRMP) was developed using a clearing system algorithm by Roth and Peranson (1997) (see Table 7).

Economic system: centralized clearing (1951)
Clients

  • Doctors submit preferences for positions
  • Resident programs submit preferences for doctor

Non-client agents

  • A centralized clearing process

Regulation

  • None

Table 6: The doctor matching system 1951.

Economic system: US National Resident Matching Program – NRMP (1998)
Clients

  • Doctors submit preferences for positions
  • Resident programs submit preferences for doctors

Non-client agents

  • Engineered centralized clearing process

Regulation

  • None

Table 7: The NRMP doctor matching system.

Roth considers the redesign to be an example of an economic design discipline:

‘These developments suggest the shape of an emerging discipline of design economics, the part of economics intended to further the design and maintenance of markets and other economic institutions’ (Roth, 2002).

Roth considers the role of the economist as one of engineer, and implicitly outlines a conception of economics engineering (Roth, 2002). In what follows, this conception is made explicit and analyzed against the generic engineering conception outlined above.

For the NRMP design the general requirements and artifact specifications are partly described in terms of Mathematical Game Theory. The following is taken from Roth (2002) but presented in the style of preference orderings outlined above. This is done in order to illustrate that Roth’s work is consistent with the notion of preference orderings and to facilitate the analysis of the NRMP general requirements against the generic engineering conception: The NRMP requirements are as follows:

  • There are two disjoint sets of F 1⁄4 ff1;…fng of firms and W 1⁄4 fw1;…wpg of workers where each firm fi seeks up to qi workers and each worker seeks exactly one firm.
  • A match is a functionl : F ! }ðWÞ that maps firms to sets of workers. The set of all such functions is called M.
  • For each worker wieW there is a worker preference ordering hF; wi ; Pwi i representing the worker’s preferences for firms such thatforallfi;fj 2Pwi; fi <fj; fi >fj orfi=fj.In other words all of the preferences are linearly ordered and can thus be represented as a sequence hfi, fj, . . .i.
  • For each firm fi e F there is a firm preference ordering hW; fi ; Pwi i representing the firm’s preferences for workers such that for all wi;wj 2Pfi, wi <wj, wi >wj or wi =wj. In other words, all of the preferences are linearly ordered and can thus be represented as a sequence hwi, wj, . . .i.
  • A match preference ordering hM,6,Pi can be specified on the setof matches M. The set of preferences is defined as P1⁄4fl2MklðfÞjq^ðw2lðfÞ)w2Pf ^f 2Pwg. In other words, for a matching to be a preference, no firm should be matched against more workers than it requires and all workers and firms should be matched against their preferences. The ordering is specified with two conditions. The first condition states that if |l(f)| < q and l0 is identical to l except that l0 (f) = l(f) [ {w}then l < l0 whenever wePf and fePw In other words a matching that adds an additional worker to a firm that is not at capacity is preferred, as long as the worker and firm are in each other’s preferences. The second condition states that if w0 < f w, f0 < w f, wel(f0),w0el(f)andwel0 (f)inlandl0 thatareotherwise identical then l < l0. In other words a mapping is preferred if it provides a better match for any worker and firm pair.
  • Using the terminology of Roth a match l is considered Stable if there is no match l0 such that l < l0. In other words, a stable match cannot be improved upon by better satisfying user’s preferences. This formalizes common preference (f).

The postulated general problem of economic design has been used to describe the client requirements and artifacts for the redesign of the entry-level labor market for American doctors. Further, the mathematical formalization of preference orderings has been shown capable of capturing the formal aspects of the matching problem. Thus the general problem of economic design has been validated against the labor market redesign example.

The consistency and completeness of Roth’s implicit conception is now analyzed against the generic engineering conception. Criterion 4 is considered first.

There is a general requirements specification given in terms of the sets F and W and there are associated preference orderings. A general artifact specification is an algorithm that will always produce a stable match. Such an algorithm is documented by Gale and Shapley (1962) who go further and prove a theorem that given the general requirements there will always be a stable match and that a stable match will be produced by their algorithm. Thus the formal relationship between general requirements specification and general artifact specification has been satisfied. Thus Roth’s conception is consistent and complete with respect to part (a) of Criterion 4.

In the Roth paper the specific requirements specification is given semi-formally as an English language description of the particular matching problem in the case of doctors and residence programs. The sets F and W are matched to residency programs and doctors respectively. Thus the general requirements specification and the specific requirements specification are related, all be it semi-formally. In a more formal approach specific requirements specification might be stated in terms of a design language such as Universal Modeling Language (UML) (Fowler, 2003). For Software Engineers with some knowledge of set theory and orderings, a formal relationship could be constructed between the UML specification and the game theory definitions, the general requirements specification. In the case of the problem discussed above, this would, for example, map a class Doctor to the set W and the class Residency Program to the set F. Thus, Roth’s approach is consistent, but not complete with respect to part (b) of Criterion 4.

Roth outlines no specific artifact specification. From a software engineering perspective a specific artifact specification, in the form of a computer program, may be produced in a software programming language such as Java (Flanagan, 2005). For software engineers the relationship between an algorithm, the general artifact specification, and a software program implementing that algorithm, the specific artifact specification may be considered formal. It is therefore possible to complete Roth’s conception, which is consistent but not complete with respect to part (c) of Criterion 4.

Thus, Roth’s conception appears consistent but not complete with respect to Criterion 4. Criterion 3 is now considered.

Even though Roth’s description of the specific requirements specification, is only semi-formal, he lists involvement with representatives of both student doctors and resident programs at the beginning of the design, ongoing contact with stakeholders throughout the design and final agreement for the design. Thus establishing the empirical relationship between the phenomena of client requirements and the specific requirements specification, even if the latter is semi-formal. Thus Roth’s conception is consistent and complete with respect to part (a) of Criterion 3.

As mentioned above Roth exposes no notion of specific artifact specification. However, from a software engineering perspective, the Java program described above would be instantiated as a running process on some physical computation hardware establishing an empirical relationship between specific artifact specification and artifact. It is therefore possible to complete Roth’s conception, which is consistent but not complete with respect to part (b) of Criterion 3.

The relation between the UML specification and the Java program may be established using tools such as the Rational Unified Process (RUP) (Kroll and Kruchten, 2003; IBM Website, 2009), Java classes can be generated from the UML specification and the UML specification reversed engineered from the Java classes using tools such as Rational Rose Developer for Java (IBML Website (2009)). Thus a formal relationship between specific requirements specific and specific artifact specification can be established. It is therefore possible to complete Roth’s conception, which is consistent but not complete with respect to part (c) of Criterion 3.

Thus, Roth’s conception appears consistent but not complete with respect to Criterion 3. Criterion 2 is now considered.

Although not reported by Roth, it may be presumed that prior to operation user acceptance tests would have be performed to ensure that, artifact, the implemented process, met client requirements. Roth does report that NRMP system has been operating successfully for a number of years. To consider the importance of stability Roth, also considers a number of alternative matching systems in operation in the US, the UK and Canada. From a total of 16 systems, the nine systems that produce a stable match are all still in operation. Of the seven systems that do not produce a stable match, all but two have failed. The analysis of the operating systems was supplemented by laboratory experiments to ensure there were no other reasons for the failures. Thus the empirical relationship between the specific artifact discussed and client requirements is produced. Further to this, the relationship has been established for a number of different specific design cases. Thus Roth’s conception is complete and consistent with respect to Criterion 2. Consider Criterion

Roth does not explicitly describe a general problem of economic design. However, it has been possible to map the design problem considered to the postulated general problem for economic design. Thus Roth’s is implicit conception is consistent but not complete with respect to Criterion 1.

Summarizing across the criteria, it can be seen that, given the postulated problem of economic design, Roth’s conception is consistent with an engineering conception of economic design.

Further to this, the formal relationship outlined between general requirements specification and general artifact acts as a specification of engineering principle. This Match Stability Principle may be stated as follows:

In order to produce stable matches (see common preference f), the Gale and Shapley matching algorithm should be used.

The sources of the incompleteness of Roth’s implicit conception are worth considering.
In order to demonstrate the consistency of Roth’s conception to the generic engineering conception, aspects of the design were artificially completed using tools from the field of software engineering. This indicates that the knowledge and practices from this field may prove useful in building an engineering discipline of economic design.

It should also be noted that the design exemplar has focused on one of the performance criteria, common preference (f). Roth (2002) actually does focus on other issues including concerns about whether preference orderings are worker or firm optimal. The consideration of these has not been possible due to reasons of space. However there still remain issues that have not been addressed by Roth. Common preferences (d) and (e) that are related to resources expended by doctors and resident programs in using the system. It may be argued that the general design problem is an abstraction and these were not seen as being a problem for the design before NRMP. On the other hand, this is a significant cognitive design problem, which may have an impact on overall acceptance of the economic system.

Further cognitive issues arise in relation to assumptions as to how preferences are stated. The game theoretic model assumes preferences can be ordered. This is a standard assumption for game theory. It is a cognitive issue as to whether this is necessarily the case. The consideration of these issues would likely involve the application of knowledge and practices from the emerging discipline of cognitive engineering (Dowell and Long, 1998).

The analysis of the completeness issues of Roth’s conception indicates that knowledge and practices from other disciplines may form an important part of any discipline of economic engineering.

It is important to consider also that the design exemplar given above is a simplification of the actual problem for the market being designed. Married couples have preferences for residency programs in the same locale. Unfortunately game theoretic results state that if such interrelated preferences are added there is not guaranteed to be a stable match within the match preference ordering (Roth, 1984). This issue might seem to significantly reduce the effectiveness of the stability matching principle. However Roth and Peranson (1997) indicate through theoretical computations and analysis of actual matching data from the NRMP system that cases where stable matches are not produced are extremely rare in practice.

The way the emerging discipline of economic design seeks to address this type of issues is key to the type of discipline that emerges. The value Long and Dowell (1989) adds here is the distinction between applied science and engineering disciplines. If the discipline is happy to rest with simple theoretical models that offer guidance to the design of actual systems it will have the knowledge associated with an applied science discipline and the match stability principle will really be a match stability guideline. If, however, as Roth appears to advocate, the formal knowledge is elaborated to provide principles that, for example, establish under what preference correlation and numeric conditions stable matches are guaranteed, the discipline will have the knowledge of an engineering discipline.

Roth’s implicit conception that focuses on microeconomics and the design of individual markets has provided a contrast between applied science and engineering disciplines. In what follows the macro-economic design issues engendered by global financial crisis are considered from the perspective of the general design problem for economic engineering.

6. The late 2000s global financial crisis

A brief description of the global financial economic system pre2009 is provided.(Table 8).

Economic system: global financial system (pre-2009)
Clients

  • Consumers
    – – Investing
    – – Obtaining credit
  • Firms and other legal entities
    – – Raising capital
    – – Investing

Non-client agents

  • Financial institutions
  • – – Banks (retail and wholesale)
  • – – Hedge funds
  • Credit reference agencies – consumers (Equifax, Experian, etc.)
  • Credit rating agencies – non consumer (Standard and Poor, Moody, etc.)
  • Government
  • – – Central banks
  • – – Regulators

Regulation

  • Capital adequacy requirements
  • National regulatory supervision
  • Accounting regulation
  • Deposit insurance

Table 8: The global financial system (Pre-2009).

Problems in the actual performance of the system emerged in 2007, as a result of a collapse of the US Housing bubble. In 2008 the global financial system failed in a catastrophic manner (Wikipedia, 2007–2009):

  • A number of financial institutions found themselves in financial difficulties leading to effective take over by the government (Northern Rock – UK, Fannie Mae – US, Freddie Mac – US), take over by other institutions (Bradford & Bingley – UK, Bear Stearns – US, Merrill Lynch – US, Washington Mutual – US) and even bankruptcy (Lehman Brothers – US).
  • In order for financial institutions to meet capital adequacy requirements the governments of the US and the UK had to inject $700 billion and £500 billion into financial institutions, respectively.
  • Global equity markets collapsed wiping trillions of dollars off asset values.
    The failure led to a Credit Crunch that has made capital and credit significantly more difficult to obtain and has simultaneously reduced returns on investment, further degrading the actual performance of the system.

For now, a description of the domain of the global financial system will be forgone as a redesign, proposed by the UK Financial Services Authority (FSA) is considered. As might be imagined there are many other potential solutions including, for example, a return to Keynesian approach to economics that dominated between the 1940s and 1970s (Gailbraith, 2008; Stratton and Seager, 2008). In what follows only the FSA’s response is considered in order to illustrate the potential pitfalls of considering redesign without a clear understanding of the design problem.

6.1. The FSA response to the crisis

The Turner Review (Turner, 2009) proposes alterations to the global financial system to avoid a recurrence of recent catastrophic actual performance failures in the future. In order to simplify the presentation only some of the main points of the redesign are listed (see Table 9).

It is perceived that financial systems were not sufficiently capitalized going into the crisis so the FSA recommends that:

‘The quality and quantity of overall capital in the global banking system should be increased’ (Turner, 2009).

Unsurprisingly, the FSA proposes a number of extensions to regulatory supervision including extending regulation to hedge funds and regulation of offshore financial centers based upon globally agreed regulatory standards.

Economic system: global banking system (FSA recommendations)
Clients

  • Consumers
    – – Investing
    – – Obtaining credit
  • Firms and other legal entities
    – – Raising capital
    – – Investing

Non-client agents

  • Banks (retail and wholesale)
  • Credit reference agencies
  • Government

Regulation

  • Increased capital adequacy requirements
  • Extended regulatory supervisio
  • Accounting regulation to include off cycle reserves
  • Regulation of credit rating agencies
  • Increased deposit insurance
  • Modified remuneration structure

Table 9: The FSA response to the crisis.

Domain
Work Transformation

  • To match consumer’s and other legal entities investment and credit
    requirements
  • To enable transactions between clients and to provide reporting of these
    transactions

Client Preferences

  • For investment and credit matches
  • For transaction type
  • For transaction report

Common

  • Transactions should be carried out between correctly identified clients
  • Clients should be aware of the credit worthiness of other parties to
    transactions
  • Client knowledge of the nature of transactions should be sufficient for
    them to be aware of the risks associated with different transactions

Table 10: The design problem of the global financial system.

The FSA believes that the risk management methodologies in use by financial institutions, in particular, the Value at Risk (VAR) (Gastineau and Kritzman, 1996) method did not sufficiently take into account the fluctuations in the economic cycle and thus the ‘Capital required against trading book activities should be increased significantly (e.g. several times)…’ And that published accounts should include an ‘Economic Cycle Reserve’.
The crisis has in part been attributed to failures of the credit rating agencies and so the report proposes that:

‘…they should be subject to registration and supervision to ensure good governance and management of conflicts of interest and to ensure that credit ratings can only be applied to securities for which a consistent rating is possible.’

The FSA recommends that retail deposit insurance is increased ((This measure has already been taken in the UK.)) and that depositors should be made aware of the extent of the insurance cover.

Finally, from the perspective of our analysis, the FSA proposes changes to the remuneration structures within financial institutions to ‘avoid incentives for undue risk taking’.
The recommendations of the Turner review should go a long way to preventing a recurrence of a similar crisis thus avoiding potentially catastrophic actual performance failures in the global financial system. However, the review does not specify a design problem for the global financial system. The closest it comes is to provide a list of ”What went wrong?” This implement and test approach is typical of a craft discipline as outlined by Long and Dowell. Without the consideration of a design problem that identifies desired performance, there is no way to judge, a priori, whether the Turner recommendations will, if adopted act to improve or degrade the ongoing overall actual performance of the global financial system. To attempt such analysis it is necessary to attempt to specify the general design problem for the global financial system.

6.2. A conception based response to the crisis

A simple domain model of the global banking system is postulated in Table 10.
The work transformation is seen as having two elements. The first of these is to match ((It may be argued that the work transformation should be to meet rather than just match consumer and legal entities investment requirements. The distinction between match and meet is a subtle one. Using the formalism of preference orderings, to meet requirements every client’s preference for investment and credit would need to be in the specified set P. This is unlikely to be possible unless some condition on the reasonableness of client preferences with respect to other participants. This seems too strong a condition to impose.)) investors to those requiring credit. This is taken to mean all financial transactions from simple deposits and loans, to complex derivative transactions and indeed any transaction that manages risk. The second element of the transformation is the services of banks that are a key component to the financial system, the provision of transaction management and reporting services to customers.

The client preferences capture preferences for investment and credit matches as well as the type of transactions that may be carried out and the nature of the reports on these transactions.

The common preferences capture key aspects required of the banking system: identity verification, credit reference and rating, and provision of financial advice.

Some of the FSA recommendations outlined above, in particular improved regulation of credit rating agencies and ensuring depositors are aware of the nature of deposit insurance should act to improve actual performance for this domain. However, other effects are likely to have a negative impact on ongoing performance. In order to increase capital and meet requirements for off cycle reserves, financial institutions will need to increase the spread between investment and credit thus providing less preferred investment-credit matches to clients. Increased regulation will also increase costs to financial institutions further increasing spreads. A more worrying aspect of increased regulation is the consequently increased barrier to entry for new financial institutions. This occurs on top of a radical financial institution consolidation that has already increased such barriers. The effect of raised barriers to entry is to reduce innovation in the financial institutions and reduce competition, thus leading to a further degradation of actual performance.

Economic system: proposed redesign of global financial system
Clients

  • Consumers
  • – – Investing
  • – – Obtaining credit
  • Other legal entities
  • – – Investing
  • – – Raising capital

Non-client agents

  • Transaction management institutions with functions:
  • – – Transaction management
  • – – Transaction reporting & accounting
  • – – Identity verification
  • – – Credit rating and reference provision
  • – – Financial advice provision
  • Investment institutions
  • Government
  • – – Central banks
  • – – Regulators

Regulation

  • Capital adequacy requirements for banks
  • Global regulatory supervision
  • Based upon a tiered structure of investment intuitions. With increased regulation for higher tiered institutions. Government guarantees pay- ments for all tier one institutions. Level of government guarantees tails off as you go down the investment institutional tiers
  • Accounting regulation – enforced through transaction management insti- tutions, extended based upon investment institution tier

Table 11: The proposed redesign of the global financial system.

The problem is not that more regulation is not needed but rather that regulation needs to be considered as part of a redesign of other aspects of the financial system. The statement of a design problem opens up the possibility for the knowledge and practices of other disciplines to be employed towards the development of a solution. In Table 11 a design is presented that employs an approach normally used by software system architects:

‘The software architecture of a program or computing system is the structure or structures of the system, which comprise software elements, the externally visible properties of those elements, and the relationships among them.'(Bass et al., 2007).

Such an approach considers the structure and relations of the components of the system, in the economic system case, the non-client agents, and how these components may be reconfigured to improve actual performance. To justify the proposed redesign evidence is given that agents that perform some of the functions described are already emerging.

A key aspect of this redesign is a separation of concerns amongst financial institutions. Such an approach was made after the great depression of the 1930s in the US Glass-Steagall Act (1933), the partial repeal of which in the Leach-Bliley Act (1999) (Barth et al., 2000) has been partly blamed for the current crisis (Halligan, 2009; Housel, 2009). The separation proposed in this redesign, however, goes much further than the 1933 act. The primary separation is between institutions with the function of transaction management and institutions whose function is investment.

The transaction management institutions play no investment role and therefore are risk neutral with respect to investment risks. They fulfill client’s transaction requirements moving money between different client’s investment institutions. It can be argued that emerging organizations are already fulfilling this role (e.g. Paypal ((Paypal actually does hold deposits but this is to facilitate transactions, rather than for investment purposes.))

(Paypal, 2009). A key aspect of any transaction management system is the correct identification of the clients that are party to a transaction. Thus, identity verification is a key role of transaction management institutions. Other functions of transaction management institutions include transaction reporting and financial advice. Web-based organizations have emerged that play this function Wesabe (2000) and Geezeo (2009). These entities go further than merely reporting financial transactions, enabling users to analyze their expenditure by constructing accounts. Finally transaction management institutions, with full knowledge of client’s transactions (and even accounts), and independence from any investment incentive, are ideally placed to offer accurate credit reference and rating information.

The concept of separation of concerns is carried further into investment institutions. A comment from Nobel laureate Paul Krugman acts as motivation for this separation. He postulates the following simple rule:

‘. . . anything that does what a bank does, anything that has to be rescued in a crisis the way banks are, should be regulated like a bank'(Krugman, 2009).

The separation for investment institutions aims to tie the level of regulation to the level at which the institutions will be rescued by governments. At the highest tier might be simple deposit takers that make low credit risk loans. Such institutions would be rescued in full in the event of a collapse through a deposit insurance scheme. By necessity, these institutions would be highly regulated. There are already emerging institutions such as (Zopa (2009) fulfilling this function putting depositors and lenders together in a radically different fashion to that used by existing banking institutions. At the lowest tiers are lightly regulated institutions that are involved in highly risky investments but that under no circumstances would be rescued by government. Transaction management institutions, through their role as independent financial advisors to their clients, are responsible for ensuring that clients understand the difference between the different types of institutions.

The simple proposed design should act to improve actual performance of the global financial system.

Improved identity management should better ensure that transactions are carried out between correctly identified clients. Such identity management may also have applications beyond the financial sector helping to improve identity management across the internet (Cameron, 2005). Competition amongst transaction management institutions should ensure that client preferences for transaction types and transaction reports are met. The provision of accounting services and independent financial advice by transaction managers would act to improve client knowledge of financial transactions and better enable them to understand the risks associated with these transactions. Shiller (2008) cites poor financial advice in the provision of sub-prime mortgages as one of the causes of the housing bubble that led to the financial crisis. He further recommends that financial advice should be offered to individuals through government subsidy. The inclusion of credit reference and rating functions the transaction management institutions, would greatly improve the information upon which the credit worthiness assessments are made. This not only improves client’s knowledge of the other parties to their transactions but also, through the elimination of false negatives, leads to potentially improved investment-credit matches. The tiered structure of investment institutions, and its consequent separation of low risk and high-risk investments enable clients to better select investments, also acts to improve investment-credit matches.

The recommendations of the FSA outlined above can be incorporated into the tiered structure of investment institutions without having such a negative effect on the actual performance of the overall system. Further, the independent transaction management institutions can independently assess the risk profile of investment institutions as part of their credit reference and rating function, reporting to the regulatory authorities.

In contrast to microeconomics, there appears, as of yet, to be no emerging discipline of macro-economic engineering. ((Shiller’s (1993) discussion of the use of macro-markets for managing societies large risks being one possible exception.))

There is no general design knowledge, there are no putative principles to be analyzed. The value the Long and Dowell (1989) work adds here is the address of macro-economic issues within the context of a general design problem.

The simple system architecture solution above is not a complete solution to the current financial crisis. For this to be the case there would need to be elements such as an empirical validation of the problem statement, an implementation plan (for the empirical derivation) that migrated the current financial system to the new architecture, many other issues need to be addressed using the knowledge and practices of multiple disciplines. However the statement of the problem and the solution in this design-focused form does enable, a prior discussion as to the effectiveness of the solution. Just the problem in terms of desired performance opens possibilities of using the knowledge and practices from outside of mainstream economics.

7. Conclusion

Using a generic engineering conception derived from the work of Long and Dowell, and a postulation of the general design problem for economic systems, instances of both microeconomic and macro-economic design have been analyzed.

The general design problem for economic design has been considered in each analysis. Through Roth’s exposition of the redesign of the entry-level labor market for American doctors it was possible to describe the design problem and multiple different economic system solutions in terms of the general problem. The general problem was also used to provide a new perspective upon the redesign of the global financial system in response to the current crisis.

For the Roth work, the analysis against the generic engineering conception illustrated that:

  • The implicit conception of an engineering discipline exposed through the Roth’s example of redesign is consistent with the generic engineering conception.
  • Although Roth’s conception is not complete with respect to the generic conception, completeness might be sought through consideration of the knowledge and practices of other disciplines.

For the case of the global financial system, it has been illustrated that considering the issues within the context of a design problem, may lead to solutions that would otherwise not be considered. Here, too, given the complex nature of the problem, bringing in practitioners from other disciplines and considering the problem from a design-focused perspective may prove beneficial.

The value offered by the Long and Dowell is the conceptualization of the fundamental distinction between the general problems of scientific and engineering disciplines and the consequent distinction this engenders for knowledge and practice. It may be argued (Wikepedia, 2009) that in the past, a scientific discipline of economics has dealt with emergent problems through Kuhnian style paradigm shifts in macro-economics. The response to the great depression of the 1930s led to the dominance of Keynesianism (Keynes, 1936) This paradigm was in turn overthrown in response to the low growth and stagflation of the 1970s, ushering in an era of Monetarism (Freidman, 1962).

Solving the complex design problems of the economic systems of the 21st century may require more that these 20th century paradigm shifts of a scientific discipline.

Practitioners from different disciplines may need to be drawn together into an engineering discipline of economic design, of the type envisaged for HCI by Long and Dowell. Further as the interactions of human economic agents are increasingly mediated through software economic agents one would expect HCI to play a significant role in such a discipline.

References

Barth, J.R., Brumbaugh Jr., R.D., Wilcox, J.A., 2000. The repeal of glass-steagall and the advent of broad banking. Journal of Economic Perspectives 14 (2), 191–204.

Bass, L., Clements, P., 2007. R. Kazman Software Architecture in Practice. Addison Wesley.

Cameron, K., 2005. The Laws of Identity, The Identity Blog website, December 5, 2005. <http://www.identityblog.com/stories/2005/05/13/TheLawsOfIdentity. pdf>.

Dowell, J., Long, J.B., 1989. Towards a conception of an engineering discipline of human factors. Ergonomics 32 (11), 1513–1535.

Dowell, J., Long, J.B., 1998. Conception of the cognitive engineering design problem. Ergonomics 41 (2), 126–139.

Flanagan, D., 2005. Java in a Nutshell. O’Reilly.

Fowler, M., 2003. UML Distilled: A Brief Guide to the Standard Object ModelingLanguage. Addison-Wesley.

Freidman, M., 1962. Capitalism and Freedom. University of Chicago Press.

Gailbraith, J.K., 2008. The collapse of monetarism and the irrelevance of the New
Monetary consensus,25th Annual Milton Friedman Distinguished Lecture at Marietta College, Marietta, Ohio, March 31, 2008. <http://www.gov.utexas.edu/ papers/CollapseofMonetarismdelivered.pdf>.

Gale, D., Shapley, L., 1962. College admissions and the stability of marriage. American Mathematical Monthly 69, 9–15.
Gastineau, G.L., Kritzman, M.P., 1996. Dictionary of financial risk management. Frank Journal of Fabozzi Associates.

The Geezeo Website, 2009. <http://www.geezeo.com>.

Halligan, L., 2009. Outrage at bonuses won’t solve the mess we’re in, The Daily
Telegraph website, February 16, 2009. <http://www.telegraph.co.uk/finance/ comment/liamhalligan/4623601/Outrage-at-bonuses-wont-solve-the-mess- were-in.html>.

Housel, M., Barker, C., 2009. Who’s More to Blame: Wall Street or the Repealers of the Glass-Steagall Act? Notley Fool Website, April 6, 2009. <http:// www.fool.com/investing/general/2009/04/06/whos-more-to-blame-wall-street- or-the-repealers-of.aspx>.

IBM Website – Rational Unified Process, 2009. <http://www-01.ibm.com/software/ awdtools/rup/?S_TACT=105AGY59&S_CMP=WIKI&ca=dtl-08rupsite>.

IBML Website – Rational Rose Developer for Java, 2009. <http://www.01.ibm.com/ software/awdtools/developer/rose/java/index.html>.

Keynes, J.M., 1936. The General Theory of Employment. Interest, and Money. Kroll, P.,

Kruchten, P., 2003. The Rational Unified Process Made Easy: A Practitioners
Guide to the RUP. Addison-Wesley.

Krugman, P., 2009. The Return of Depression Economics and the Crisis of 2008.
W.W. Norton Company Limited.

Kuhn, T.S., 1970. The Structure of Scientific Revolutions. University of Chicago Press.

Lawvere, F.W., Schanuel, S.H., 1987. Conceptual Mathematics, A First Introduction
to Categories. Cambridge University Press.

Long, J.B., Dowell, J., 1989. Conceptions of the Discipline of HCI: Craft, Applied
Science and Engineering, People and Computers V. Cambridge University Press.

MacLane, S., 1998. Categories for the Working Mathematician, second ed. Springer.

Milgrom, P., 2000. Putting auction theory to work: the simultaneous ascending
auction. Journal of Political Economy 108 (200), pp. 245–272.

Osbourne, M.J., Rubinstein, A., 1999. A Course in Game Theory. MIT Press. The Paypal webs, 2009. <http://www.paypal.com>.

Roth, A.E., 1984. The evolution of the labor market for medical interns and
residents: a case study in game theory. Journal of Political Economy 92, 991–
1016.

Roth, A.E., 2002. The economist as engineer: game theory, experimentation, and
computation as tools for economic design. Econometrica 70 (4), 1341–1378.

Roth, A.E., Peranson, E., 1997. The effects of the change in the NRMP matching
algorithm. Journal of the American Medical Association 278, 729–732.

Salter, I.K., 1993. A framework for formally defining the syntax of visual languages. In: Proceedings of the IEEE Symposium on Visual Languages. IEEE Computer
Society Press, pp. 244–248.

Salter, I.K., 1995. The Design of Formal Languages, PhD Thesis, University College
London.

Shiller, R.J., 1993. Macro Markets: Creating Institutions for Managing Society’s
Largest Economic Risks, Clarendon Lectures in Economics. Oxford University
Press, Oxford.

Shiller, Robert J., 2008. The Subprime Solution. Princeton University Press.

Simon, H., 1957. A behavioral model of rational choice. In: Models of Man, Social
and Rational: Mathematical Essays on Rational Human Behavior in a Social
Setting. Wiley, New York. Stratton, A.

Seager, A., 2008. Darling invokes Keynes as he eases spending rules to
fight recession, The Guardian, October 20th 2008. <http://www.guardian.co.uk/
politics/2008/oct/20/economy-recession-treasury-energy-housing>.

Turner, J.A., 2009. The turner review (a regulatory response to the global banking
crisis). Financial Services Authority (3).

The Wesabe Website, 2000. <http://www.wesabe.com>.

Wikepedia – Paradigm Shift, 2009. <http://www.ikipedia.org/wiki/Paradigm_shift>.

Wikipedia – Financial crisis of 2007–2009. <http://www.en.wikipedia.org/wiki/
Financial_crisis_of_2007%E2%80%932009>.

Wilson, R.B., 2002. Architecture of power markets. Econometrica 70, 1299–1340.

The Zopa Website, 2009. <http://www.zopa.com>.