You are here: Home › Towards Engineering Principles for Human-Computer Interaction

Towards Engineering Principles for Human-Computer Interaction

Adam Stork & John Long

University College London, Gower Street, London, WC1E 6BT, UK
Corresponding author: Adam Stork, 32 Chisenhale Road, Bow, London E3 5QZ.  Tel: 0794 383 7676.  Email: adam@adamstork.com

Abstract

The paper summarises the key points and conclusions from the PhD research by Adam Stork [1] that was supervised by John Long.  The research aimed to develop ‘engineering principles’ as proposed by Dowell and Long [2].

The research was successful in developing early and initial engineering design principles: early, because the principles required further generalisation; and initial, because the principles had not been validated through application.  Hence, the research was considered to have made significant progress towards engineering principles.

Given that progress, the research provided a valuable perspective on a strategy for developing engineering principles.  This perspective led to the development of a version of a structured Method for Usability Engineering (MUSE [3]) for use in research (termed MUSE/R) along with shorter-term research products.  The paper focuses on this perspective on the basis that it provides input to research strategies.  Readers interested in the detail of the specific research strategy and the early initial engineering principles developed are recommended to consult the PhD itself.

1. Introduction

The research was primarily concerned with improving Human-Computer Interaction (HCI) design through the development of HCI design knowledge.  The requirement to develop design knowledge arose from a specific operational problem with design, raised by the industrial sponsor of the research.  The research demonstrated that this specific design problem was more widespread.  Essentially, the general operational problem was a failure to be able to design human-computer systems effectively, as expressed succinctly by Draper [4]:

‘The fundamental fact about HCI today is that neither computer science or cognitive science have any theories to offer that are adequate for predicting how a given design of user interface will perform.’

The primary aim in the research was to address these challenges for HCI, and enable HCI to deliver considerable benefits to human-computer systems.

2. Engineering principles as the technical solution

The technical expression of that general operational problem was identified as the requirement to make HCI knowledge more effective, and specifically to acquire HCI knowledge with a guarantee of application.

Dowell and Long’s (D&L) assessment of the discipline of HCI [2, 5] was applied to identify the technical problem.  Dowell and Long propose the development in the longer term of an engineering discipline, with knowledge that has a guarantee.  They term this knowledge ‘engineering principles’.

The development of engineering principles for HCI was the long-term technical solution addressed by this research.  The technical aim of this research was to make progress towards these engineering principles, through the development of a conception of engineering principles, a strategy for their acquisition, and an assessment of that strategy.

2.1 Conception of (substantive) engineering principles

Part of D&L’s proposal is a conception of the general design problem of an engineering discipline of HCI.  However, the research required and developed a conception of engineering principles, and scoped that conception to ‘substantive’ principles.  Substantive engineering principles ‘prescribe the features and properties of artefacts’ (D&L).  Components of engineering principles were conceptualised: general design problems; general design solutions; specific design problems; specific design solutions; partial design problems; and partial design solutions.
Since human-computer system costs are poorly conceptualised by D&L relative to task quality, the research also proposed an initial conception of human-computer systems and their costs.

2.2 Strategy for acquiring engineering principles

The research proposed a strategy for developing such substantive engineering principles and compared it with alternative strategies.

The strategy adopted took a bottom-up approach with two main steps:

  • To identify general relationships between specific design problems and their solutions.  These general relationships would be considered putative, i.e. requiring validation, and termed initial engineering principles.  The identification of general relationships between specific design problems and their solutions requires the operationalisation of specific HCI design problems and their solutions from the conceptions of specific HCI design problems and specific HCI design solutions.
    The research applied best-practice current HCI design (‘SuperCraft’) to develop the specific HCI design solutions.
  • To validate initial engineering principles by testing.

The research aimed to assess the proposed strategy by developing examples of initial engineering principles, which have not been validated by application.  They are, however, tested through evaluation (and thereby acquire ‘potential guarantee’).

The research was further scoped to cognitive ‘planning and control’ engineering principles and an initial conception of planning and control was developed based on the relevant literature.

2.3 Two cycles of best-practice development and operationalisation

The research conducted two cycles of best-practice development to solve two sets of energy management user requirements.  The resulting artefact specifications were informally evaluated against the user requirements, both analytically and empirically.  The evaluations were positive, supporting the subsequent operationalisations of the specific design problems and their solutions.

The operationalisations were of the specific design problem and solution conceptions, incorporating the conception of human-computer systems and the conception of planning and control.

2.4 Initial Engineering Principles

Examples of initial engineering principles were acquired by identifying general relationships between specific design problems and their solutions.  A detailed strategy for this acquisition was presented, to clarify this ‘identify’ process for finding general ‘relationships’.  ‘Identify’ was clarified as targeting relationships that are more likely to be general, and six forms of targeting are presented.  ‘Relationships’ are clarified as commonalities.  General relationships, either within or between operationalisations, are initial engineering principles.

The six forms of targeting were:

  • Initial engineering principles identified during operationalisation(s).
  • Initial assumption assessment from operationalisation(s).
  • Inspirational initial engineering principle from operationalisation(s).
  • Initial engineering principles from general guidelines.
  • Initial engineering principles from guidelines.
  • Initial engineering principles from task analysis.

The research developed specific notations for the initial engineering principles to enable their precise representation.

3. Assessment of the research strategy

The assessment of the strategy rests on the status of the acquired initial engineering principles.

3.1 Strategy and conception changes

The research strategy was initially considered to be a bottom-up strategy.  It might be claimed that the strategy is closer to a top-down strategy:

  • The human-computer systems and the planning and control conceptions directly influenced the content of the initial engineering principles.
  • The detailed strategy based the identification of initial engineering principles on Craft substantive design knowledge.

There remained a contrast with a top-down strategy, however.  Stork, Lambie and Long [6, 7] described a project that attempts the top-down strategy.  They started with an informal statement of Craft substantive design knowledge and then attempted to operationalise it as an initial engineering principle.  Accordingly, Stork and Long [8] proposed that there might be a continuum of strategies between the bottom-up and the top-down strategies, along a continuum of the expected initial generality.  Therefore, the research strategy was closer to the top-down strategy than originally anticipated, although it can still be distinguished from the top-down strategy.  Application of the alternative strategies outlined would have been beneficial to confirm strategy selection.

Identifying initial expected generality in the strategy raised a concern for the conception of engineering principles.  If the specific design problem and its solution conception contains concepts that relate to engineering principle acquisition, then are they required for engineering practice?  Possibly yes, although a specific design problem and its solution conception might need to encompass alternative such general conceptions to match the partial design problem and solution operationalisations (potentially to be applied).  However, it seemed more likely that it would be possible to operationalise partial design problems and solutions directly from the user requirements.  (A similar strategy that operationalised initial expected generality—the Hill et al [9] model of the planning and control of multiple tasks—for design is described in Stork et al [6].)

3.2 Status of initial engineering principles

Initial engineering principles were acquired.  These initial engineering principles had the pre-requisites for acquiring potential guarantee:

  • They are conceptualised according to a conception of the discipline of HCI.
  • They are operationalisations of conceptions based on that conception.
  • They are generalised over or within the two cycles.
  • They are tested by successful evaluations of the two cycles.

The generality was a remaining concern for the initial engineering principles.  Particularly, two or fewer cycles were considered poor generality, indicated by the difficulty of selecting appropriate general cycle types.  A further concern was that the expression of the initial engineering principles might not be appropriate for application.  These concerns indicate that the initial engineering principles should be considered ‘early’.

3.3 Validation of initial engineering principles

Validation of the initial engineering principles would involve re-expression as required and testing by application to a design situation.  Methodological engineering principles would be required for application.  The guarantee of engineering principles validated by application would be based on:

  • The initial engineering principle guarantee.
  • The operationalisations.
  • The (known) generality.

Testing would be a challenge, however, since the effect of a particular engineering principle needs to be identified.  The alternatives appear to be:

  • To control the designs to include or exclude the engineering principle application.
  • To ‘trace’ the engineering principle application and its contribution to effectiveness.  Simulation may support this tracing.

Metrification of the guarantee of engineering principles could be considered at this stage.

3.4 Method and tool support

The research highlighted a requirement for methodological and tool support for the research strategy.  The strategy products could have been integrated with a method (see section 4).  Tool support could usefully support:

  • Application of best-practice.
  • Operationalisation.
  • Detailed strategy: the identification of relationships.
  • Initial engineering principle validation.

3.5 Craft and scientific knowledge

The strategy provided a means of potentially incorporating Craft and (Applied) Scientific knowledge into initial engineering principles.  Craft knowledge was incorporated by (Super-)Craft design.  Scientific knowledge was incorporated through the conceptions (for example, a cognitive architecture conception was included in the human-computer systems conception) and the operationalisation.

Dowell [10] claimed that engineering ‘principles could be validated through utility or through explanation by science’.  (Scientific disciplines have a general science problem of the explanation and prediction of phenomena.)  It seems likely that the potential guarantee of the early initial engineering principles was improved by their Craft and Scientific knowledge basis.  However, the status of the Craft and Scientific knowledge for design is not known, therefore determining that improvement is not possible.

3.6 Formal methods

The early initial engineering principles were formal in that they were operationalised to the level of metrics.  These metrics enable mathematical techniques to be employed.

‘Expressed as simply as possible, the goal of Formal Methods is to base the software development process squarely upon a workable set of mathematical techniques.’  Gerhart [11]

Formal methods are an approach that was being followed by Software Engineering (SE) [12, 13] to solve the SE ‘software crisis’ [14].  There had been significant analysis of the issues surrounding formal methods in SE [15, 16] and some in Human Factors (HF) [17, 18].  Stork [17] identified that their use in HF was restricted mainly to the formal description of interfaces (for example [19, 20, 21]).  There were several concerns about formal methods with implications for their use in informal engineering principles: the Fetzer ‘gap’ [15], the complexity of systems; the purposiveness of animates; and the executability of specifications.

Fetzer [15] argued against formal verification. He accepted that there may be a formal path between requirements specification and a solution specification, but claimed that there will never be an unbroken path from the formal solution specification to a solution implementation.  The initial engineering principles distinguished between a general design solution and its artefact specification.

Cantwell-Smith [16] claimed that the increasing complexity of computer programs would prevent them from being proven correct.  The analogy considered in the research was that engineering principles might be too complex to be formally applicable.  However, the initial engineering principles were not complex.  Also, in high risk situations (for example, safety critical systems) complexity may deliver valuable results and so be worth significant effort in formal application.

Becker [22] underlined the value of mathematics: ‘Mathematics arises from man’s attempt to find concepts that allow a wide range of phenomena to be described in similar terms, and thereby understood in a coherent manner.’  He claimed that mathematics cannot be used for the phenomena of behaviours:  ‘It is quite possible that animate behavioural systems are organized in ways (e.g., ultra-high parallelism) that are not compatible with our traditional habits of induction and part-whole analysis.’; and ‘A “behavior” is not a well-defined thing like a numerical quantity; rather it is a selective account of an event that is defined only by certain decisions on the part of us, its describers.’  However, the initial engineering principles were not concerned with a scientifically-correct description of the behaviour, only the utility of the initial engineering principle.

Hoare [23] dismissed the requirement for formal specifications to be executable: ‘To require a specification or design of a program to be executable is hardly less absurd than requiring the specification of a building to be habitable or the blue-prints of a car to be driveable.’  However, tool support may be required to apply engineering principles.  Further, the formalism may need to be altered to enable tool support [24].

The main concern for a formalism ‘is whether it is useful, and I would add usable to that’.  (Stork [17], following [25, 26]).  The known guarantee of engineering principles would ensure usefulness.  Usability of engineering principles relates to the requirement for that known guarantee (e.g. safety critical systems may be worth significant effort).

4. MUSE for Research (MUSE/R)

A MUSE application involves the construction of products that have a well-defined scope, process, and notation.  Similarly, the application of the research strategy involved the construction of products that have a well-defined scope and notation.  The scope and notation of the MUSE products and the research products were related to each other to propose a version of MUSE to support research similar to the research.  The research proposed and outlined such a version of MUSE, termed MUSE for Research (MUSE/R).

4.1 Scope and notation

The research strategy had four main products: specific current design operationalisations; specific design problem operationalisations; specific design solution operationalisations; and initial engineering principles.  The scope of the products is expressed in the product name.  The notations for the specific current design and specific design solution were covered by: domain, structure, and behaviour diagrams; and quality, structure changes, and behaviour formulae values.  The notations for the problem and initial engineering principles were logical/mathematical expressions.
MUSE was considered to have potential for supporting the research strategy because:

  • Most of the products are operationalisations of specific design situations: either systems being analysed or the system being designed.
  • The products are explicit with a well-defined and explicit scope.

The scope, processes, and notations of the MUSE products were considered to need to be enhanced to accomodate the research conceptions and to support the research strategy.

MUSE has three phases: the information elicitation and analysis (IEA) phase; the conceptual design (CD) phase; and the detailed design (DD) phase.  The first stages of the IEA phase involve the analysis of extant systems: including operationalisations of the ‘tasks’ and ‘domains of discourse’ of the systems; and generalisations of the tasks.  For MUSE/R, these stages were re-scoped to operationalise: the specific structures and behaviours of the extant worksystems; their structural and behavioural costs; their domain; the quality of their work; and appropriate generalisations of these operationalisations.  Thus, the first stages of the IEA phase operationalise specific current designs according to the research conception.
The final stages of the IEA phase and the first stages of the CD phase in MUSE involve the specification of a human factors statement of the user needs.  For MUSE/R, these stages were re-scoped to operationalise the specific design problem.  The final stages of the CD phase and the DD phase in MUSE involve the specification of the interaction artefact and the documentation of the design rationale.  For MUSE/R, these stages were re-scoped to operationalise the specific design solution and the previously-acquired HF knowledge applied to develop the specific design solution.

The notations for the re-scoping were those employed by the research strategy, which are similar or additional to the MUSE notations no longer employed.

HCI design knowledge, including MUSE/R, was considered to also have potential for application to more general research strategies, including validation of HCI knowledge.  Stork and Long [27] outlined the more general case for HCI research and development.

4.2 Process

The redefinition of scope of MUSE/R suggested the process changes.  Figure 1 shows the overview of the processes of MUSE/R.  The redefinition demonstrated potential for reduction in research effort relative to this research.


Figure 1.  MUSE/R Overview

4.3 Support for design

MUSE/R needs to support HCI practice at least as well as MUSE.  The accomodation of the research conceptions suggested that the MUSE/R products will be more complete and coherent (relative to the general design problem conception of HCI) than the MUSE products, suggesting improved support for design.  (Linked with claims for non-Engineering application of the D&L general design problem conception.)

Görner [28] claimed that ‘a significant relationship [exists] between the amount of goal characteristics analysed and the quality of resulting design solution’ (see also Chung et al [29] who employ a similar diagram for design).  MUSE/R emphasised the operationalisation of task quality relative to MUSE, so potentially increasing ‘the amount of goal characteristics analysed’.  Further, Gomaa et al [30] claimed that domain model analysis supports design (including different views of the domain, as implied by the specific design conceptions).  Ege and Stary [31] successfully employed a combined task and object approach to designing interfaces.

MUSE/R has been applied to the design of an in-car newspaper-information device.  The scope, process, and notation of the products were defined further and MUSE/R applied informally.  A different research strategy was employed: the Hill et al [9] model of planning and control of multiple tasks was operationalised for the products, to attempt informal validation of the model for design.  A successful design was produced.

4.4 Further research on MUSE/R

Although an initial application of MUSE/R was conducted, the scope, process, and notation of the products needed to be defined further to support application.  Further resarch and design case-studies need to be performed to assess the support MUSE/R offers for research and design.  Further, the apparently strong relationship between research and design in HCI needs to be investigated further.

The evaluation component of the strategy could be incorporated into the MUSE/R method (and remain consistent with design [32]).  Tool support designed for MUSE/R would be essential, since both the design and research parts of this research would have been significantly assisted by designed tool support.  Automatic generation of prototype interfaces would be advantageous (for example, the DIANE method provides automatic help generation [33]).

5. Conclusions

Research is the acquisition of knowledge to support a purpose.  The research has acquired: a conception of engineering principles, a strategy for the acquisition of engineering principles, examples of early initial engineering principles, a positive assessment of the strategy at this juncture, and next steps for the acquisition of engineering principles.  The research has made significant progress towards solving the operational problem of the inability to design human-computer systems effectively.

In addition, shorter-term benefits can be identified.

Recognising the targets of the research was an important aim in appropriately focussing the research and acquiring knowledge towards solving the operational problem.

5.1 Technical solution

The research acquired early initial engineering principles to support the effective design of human-computer systems.  The acquisition of these early initial engineering principles supported the research strategy and took HCI substantially towards engineering principles.

5.2 Operational solution

Taking HCI towards engineering principles offered the potential for more effective HCI practice, as required to solve the operational problem, which was the inability to design effectively human-computer systems.

5.3 Strategy

The explicit strategy and implementation for the research, and its discussion, provided a basis for other HCI researchers to consider their acquisition of HCI knowledge.  The MUSE/R method provided a basis for other researchers (and designers) to apply the strategy.

5.4 Informal assessment of Dowell and Long

The D&L consideration of the discipline of HCI as an Engineering discipline and their conception of the general design problem of HCI enabled the research to acquire early initial engineering principles.  The research informally supports D&L’s consideration and conception.

5.5 Shorter term benefits

Several shorter-term research goals have been met by the research.

A version of MUSE was developed, MUSE/R, that supports more complete, coherent, and consistent specification of the design problem and solution.  It is expected that MUSE/R has the potential to improve HCI practice in the medium- and longer-terms.
Conceptions and operationalisations of design problems and solutions are available to assist practitioners in the short term to be better able to identify their design problems and solutions, and to be better able to assess that the solutions solve their design problems.

A short term goal of MUSE assessment had been achieved (Stork et al [34]).  MUSE applications have been delivered that can be used to support MUSE training and application.  Two example artefacts to HCI user requirements have been developed.  Guidelines from the development of the artefacts have been acquired.

6. References

[1] Stork, A. 1999.  Towards Engineering Principles for Human-Computer Interaction (Domestic Energy Planning and Control).  PhD thesis, University of London.

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

[3] Lim, K. Y., and Long, J. (1994).  The MUSE Method for Usability Engineering.  Cambridge University Press.

[4] Draper, S. (1991).  User Interface Performance Measurement.  JCI Summer School August 1991.

[5] Long J. & Dowell J. (1989).  Conceptions for the discipline of HCI: Craft, Applied Science and Engineering.  In: A. Sutcliffe & L. Macaulay (eds).  Proceedings of the Fifth Conference of the BCS HCI SIG, Nottingham, England, 5-8 September 1989, Cambridge: Cambridge University Press.  pp. 9-32.

[6] Stork, A., Lambie, T., and Long, J. (1998).  Cognitive Engineering Coordination in Emergency Management Training.  HCI ’98 Conference Companion, J. May, J. Siddiqi, and J. Wilkinson (eds), pp. 36-37.

[7] Lambie, T., Stork, A., and Long, J. (1998).  The Coordination Mechanism and Cooperative Work.  Proc. of the Ninth European, Conference on Cognitive Ergonomics, T. Green, L. Bannon, C. Warren, and J. Buckley (eds), pp. 163-166.

[8] Stork, A., and Long, J. (1998).  Strategies for Developing Substantive Engineering Principles.  HCI ’98 Conference Companion, J. May, J. Siddiqi, and J. Wilkinson (eds), pp. 36-37.

[9] Hill, B., Long, J., Smith, W., and Whitefield, A. (1995).  A Model of Medical Reception—the Planning and Control of Multiple Task Work.  Applied Cognitive Psychology, vol. 9, pp. S81-S114.

[10] Dowell, J. (1993).  Cognitive Engineering and the Rationalisation of the Flight Strip.  PhD thesis, University College, London.

[11] Gerhart, S. (1991).  Formal Methods: An International Perspective.  13 Int. Conf. on Software Engineering, Austin Texas, pp. 36-37.

[12] Hoare, C. (1969).  An Axiomatic Basis for Computer Programming.  Communications of the ACM, vol. 12, no 10, pp. 576-583.

[13] Gerhart, S. (1990).  Applications of Formal methods: Developing Virtuoso Software.  IEEE Software, September 1990, pp. 7-10.

[14] Pressman, R. S. (1982).  Software Engineering: a practitioners approach.  McGraw-Hill.

[15] Fetzer, J. (1988).  Program Verification: The Very Idea.  Communications of the ACM, vol. 31 no. 9 pp. 1048-1063.

[16] Cantwell-Smith, B. (1985).  The Limits of Correctness.  Paper prepared for the Symposium on Unintentional Nuclear War, Fifth Congress of the International Physicians for the Prevention of Nuclear War, Budapest, Hungary.

[17] Stork, A. (1992).  A Formal Description of Worksystem Behaviours and Interactions.  MSc (Ergonomics) Thesis.  University of London.

[18] Bauer, B. (1995).  Proving the Correctness of Formal User Interface Specifications.  Design, Specification and Verification of Interactive Systems ’95.  P. Palanque and R. Bastide (eds).  Springer.  pp. 224-241.

[19] Alexander, H. (1985).  Two Techniques for Specifying and Prototyping Interactive Software.  University of Stirling internal report.

[20] Alexander, H. (1987).  Executable Specifications as an Aid to Dialogue Design.  Formal Methods and HCI 1987, IEE Computing & Control Division Colloquium.

[21] Anderson, S. (1987).  Analysis and Synthesis in HCI.  Formal Methods and HCI 1987, IEE Computing & Control Division Colloquium.

[22] Becker, J. (1975).  Reflections on the Formal Description of Behavior.  In: Representation and Understanding, Bobrow and Collins (eds), Academic Press, pp. 83-102.

[23] Hoare, C. (1989).  Formal Methods in Computer System Design.  Computer Physics Communications 57, pp. 206-210.

[24] Breuer, P.T. and Bowen, J.P.  (1994). Towards correct executable semantics for Z. In Proc. Z User Meeting, J.P. Bowen and J.A. Hall (Editors), Springer Verlag Workshops in Computing, pages 185–209. Springer Verlag, June 1994. Cambridge, UK.

[25] Milner, R. (1989).  Communication and Concurrency.  Prentice-Hall.

[26] Dix, A. (1991). Formal Methods for Interactive Systems.  Academic Press, Cambridge.

[27] Stork, A. and Long, J. (1997).  Structured Methods for Human Factors Research and Development.  HCI International ‘97.

[28] Görner, R. (1994).  Zur Psychologischen Ayalyse von Konstrukteur- und Entwurfstätigkeiten.  Die Handlungsregulationstheorie.  Von der Praxis einer Theorie, B. Bergmann and P. Richter (eds).  Hogrefe, pp. 233-241.

[29] Chung, L., Nixon, B., and Yu, E. (1995).  Using Non-Functional Requirements to Systematically Support Change.  Proc. of the 2nd IEEE International Symposium on Requirements Engineering, pp. 132-139.

[30] Gomaa, H., Kerschberg, L., and Sugumaran, V. (1992).  A Knowledge-Based Approach to Generating Target System Specifications from a Domain Model.  Information Processing 92, vol. 1, pp. 252-258.

[31] Ege, R., and Stary, C. (1992).  Designing Maintainable, Reusable Interfaces.  IEEE Software, November 1992, pp. 24-32.

[32] Hacker, W. (1997).  Improving Engineering Design—Contributions of Cognitive Ergonomics.  Ergonomics, vol. 40, no. 10, pp. 1088-1096.

[33] Barthet, M-F.  (1993). L’intégration de l’ergonomie aux méthodes informatiques de conception de logiciels. In: Congresso Latino Americano de Ergonomia, II, 1993, Florianópolis. Anais… Florianópolis: ABERGO: FUNDACENTRO, 1993. p. 87-111.

[34] Stork, A., Middlemass, J., and Long, J. (1995).  Applying a Structured Method for Usability Engineering to Domestic Energy Management User Requirements: A Successful Case-study. BCS HCI 1995.  pp. 367-385.