S. Cummaford and J. Long
Ergonomics & HCI Unit, University College London, 26 Bedford Way,
London, WC1H 0AP
ABSTRACT
Current HCI design knowledge is generally not well specified and thus not validatable. There is a need for more formal design knowledge, which can be validated, such that guarantees may be developed. This need would be met by Engineering Design Principles (EDPs). EDPs support the specification then implementation of a class of design solution for a class of design problem within the scope of the EDP. A conception of the general EDP (GEDP) is proposed here, illustrated with reference to internet-based transaction systems. The GEDP is derived from the conception of the general design problem of an engineering discipline of HCI, and the general design solution, as conceptualised here. This conception of the GEDP, it is argued, is sufficiently formal to support the initial operationalisation of class-level design problems to support the development of class-level EDPs. A strategy for developing class-level design problems is proposed and illustrated with reference to transaction systems. This strategy appears promising for the development of class-level EDPs, supported by empirical guarantees.
Keywords Engineering, design principles, conception, human-computer interaction, performance guarantees, internet transaction systems.
NEED FOR HCI ENGINEERING DESIGN PRINCIPLES
Current best practice in HCI design has produced many technologies that interact with the user to perform effective work. However, the knowledge applied in the design of these technologies is all-toooften not explicitly stated and so not formally conceptualised, although it may be successfully operationalised by designers. Reliance on such ‘craft’ skills militates against the identification, and so the validation, of successful design knowledge and, as a result, its take-up and re-use. The lack of validation and the consequent ineffective development of design knowledge thus leads to slow and inefficient HCI discipline progress (Long 1996).
There is a need for more formal HCI design knowledge, that is, whose conception is coherent, complete and fit-for-purpose, such that guarantees may be developed and ascribed. HCI Engineering Design Principles (EDPs) would meet this need by establishing these guarantees on the basis of analytic and empirical testing, leading to their validation. EDPs are explicit, and so validatable, prescriptions of substantive and methodological design knowledge which, when applied to a design problem within the scope of the principle, would support the specification then implementation of a design solution with guarantee (Dowell & Long, 1989). The development of such knowledge would thus increment the knowledge of an engineering discipline of HCI and would be fit-for-purpose, by providing support with a better guarantee for the practices of solving HCI design problems.
The benefits of such EDPs would be numerous. By employing design knowledge, which has already been shown to support the development of successful design solutions to design problems of a similar type, the need for iterative system development would be reduced. The first iteration would benefit from previous solutions. The re-use of such design knowledge would thus reduce the development time for a technology for which a principle had been formulated. Consequently, the cost of iterative usability testing would be reduced. Furthermore, the structuring of EDPs, at varying levels of generality, would support the re-use of successful design knowledge in new design problems, providing these problems could be characterised similarly at a general level. EDPs would also facilitate design knowledge organisation, by offering a structure with which to taxonomise acquired design knowledge, relating to classes of design problem.
This paper seeks to inform EDP development by conceptualising design knowledge sufficient to prescribe a general design solution (GDS) for a general design problem (GDP). Conceptualisation of such design knowledge, once the general EDP (GEDP) has been established as applicable, is required by EDP development to make explicit the concepts, which need to be instantiated as class-level EDPs (CEDPs). The process of EDP validation comprises four stages: conceptualisation; operationalisation; test; and generalisation (Long, 1996). These four stages support the development of formal, and so validatable, HCI engineering design knowledge. Conceptualisation supports the identification of promising knowledge, which guides instantiation of the GEDP, to produce a CEDP. Instantiated CEDPs may then be operationalised, tested and generalised. These four stages of validation support the ascription of performance guarantees.
This paper begins with an expression of the GDP of an engineering discipline of HCI, as proposed by Dowell and Long (1989; 1998), which is then used to inform the conceptualisation of the GDS, the components of the GEDP and the relationships between the GDP, the GEDP and the GDS. GEDP concepts are illustrated with respect to internet-based transaction processing systems (transaction systems). These transaction systems are in widespread use in electronic commerce, e.g. the order collation and payment system in an internet bookshop. The second section addresses CEDP development issues. Two contrastive strategies are presented, the ‘initial instance’ strategy (Stork & Long, 1994) and the ‘initial class’ strategy, as proposed here. These strategies are assessed and the ‘initial class’ strategy is developed by consideration of class-level design problems (CDPs) and an approach to developing CDPs to support the development of CEDPs. CDPs are illustrated with respect to transaction systems.
PRACTICES SUPPORTED BY EDPS
Long and Dowell (1989) characterise disciplines as comprising: a general problem with a particular scope; practices which provide solutions to the general problem; and knowledge, which supports those practices. EDPs would be the knowledge of an engineering discipline of HCI. They argue that disciplines, and so knowledge, may be characterised by the completeness with which solutions are specified, supporting the practices of implement and test, if incomplete; or specify then implement, if complete. EDPs seek to support the practices of specify then implement by employing formal, and so validatable, design knowledge, which offers complete, coherent, prescriptive design support. The efficacy of prescriptive design knowledge may be seen in more mature engineering disciplines (such as electrical engineering), in which discipline knowledge supports the complete and coherent specification of design solutions prior to implementation.
CONCEPTION OF THE RELATIONS BETWEEN GDP, GEDP AND GDS
To support the development of such EDPs, Dowell & Long (1989) proposed a conception of the GDP of an engineering discipline of HCI in terms of: work; the interactive worksystem; and performance, as task quality and worksystem costs. This conception of the GDP is summarised below to inform the conception of the GDS and GEDP as proposed here. By conceptualising the relations between the GDP, the GEDP and the GDS, coherence and completeness may be assessed. The conception of the GDS is proposed here in terms of: work; the interactive worksystem; and performance, as task quality and worksystem costs. The concepts of the GDP are thus recruited into the conception of the GDS. The concepts of the GDP form criteria for the success of the GDS; use of the same concepts supports assessment of the success of the GDS in satisfying the criteria in the GDP. The conception of the GEDP of an engineering discipline of HCI is proposed here in terms of: scope, comprising a class of users, a class of computers and a class of achievable performances; substantive component; methodological component; and guarantees. These relationships between the concepts of the GEDP and their relationship to concepts contained in the GDP and GDS are discussed later. The discussion of these relationships supports the conceptualisation of complete and coherent relations between the conceptions of the GDP, GEDP and GDS of an engineering discipline of HCI.
GENERAL DESIGN PROBLEM
A design problem 1 expresses an inequality between actual performance (Pa) and desired performance (Pd) of some interactive worksystem (i.e. Pa >Pd with respect to some domain; a successful design solution specifies some interactive worksystem (hereafter worksystem) which achieves the desired performance (Pa = Pd) with respect to some domain. Worksystems comprise users and computers, both of which have structures supporting behaviours. The desired performance is expressed as work, achieved to a desired level of task quality, whilst incurring an acceptable level of costs to the worksystem. Work is expressed as transformations of the attribute values of objects in the domain of the worksystem. These domain transformations (Dowell & Long) inform the conception of the GDS and GEDP and are in italics on first exposition. Engineering Design Principles are achieved at some desired level of task quality (Tq), whilst incurring some acceptable level of costs to the user (Uc) and the computer (Cc). Attributes are features of domain objects, which afford transformation by the worksystem. The goals of the worksystem are defined as a product goal, which is a transformation of object attribute values. Realisation of a product goal may involve the transformation of many attributes and their values, these transformations being termed task goals. Thus, a product goal may be re-expressed as a task goal structure, which specifies the order and relations between a number of task goals, sufficient to achieve the product goal. As more than one task goal structure may be sufficient to achieve a product goal, it is necessary to distinguish between alternative task goal structures in terms of task quality. Task quality describes the difference between the product goal and the actual transformation specified by a task goal structure. This concept supports evaluation of alternative structures of this type (Dowell & Long, 1989). The worksystem comprises one or more users interacting with one or more computers, each of which is characterised by structures which support behaviours. Desired performance is thus effected by a particular class of user and computer structures, supporting behaviours, which achieve domain transformations, whilst incurring some acceptable level of costs. Worksystem structures are necessary to support behaviour, e.g. knowledge of financial transactions is necessary to support transacting behaviours. Worksystem behaviours involve the transformation of object attributes and their values, e.g. transferring ownership of goods from the vendor to the customer in transaction processing may be expressed as transforming the attribute ‘owner’ from value ‘vendor’ to value ‘customer’ for domain object ‘book x’.
SUBSTANTIVE AND METHODOLOGICAL EDPS
Dowell and Long assert that EDPs may be either substantive or methodological. They state that substantive EDPs “prescribe the features and properties of artefacts, or systems that will, constitute an optimal design solution to a general design problem.” Methodological EDPs “prescribe the methods for solving a general design problem optimally.” (Dowell & Long, 1989). In the conception of EDPs proposed here, substantive and methodological knowledge is assumed to be unitary. The issue of whether optimal solutions are commensurate with EDPs is not addressed, as the guarantees ascribed here would be derived from empirical testing. Thus, these guarantees cannot be claimed optimal, but empirically established.
NEED FOR CONCEPTION OF GDS AND GEDP
The Dowell and Long conception supports the development of EDPs by offering a coherent and complete expression of the GDP to be addressed by the GEDP. However, the relationship between the concepts of the GDP and the concepts of the GEDP are not formally conceptualised. Furthermore, the conception of the GDS is implicit. Thus, the relationship between the GEDP and the GDS is not formally conceptualised. The GDS is conceptualised below, as required to inform the development of EDPs.
CONCEPTION OF GDS
A design solution 2 contains the specification of a worksystem for which the actual performance equals the desired performance (i.e. Pa = Pd), as stated in the design problem. Worksystems comprising users and computers are conceptualised as structures, which support behaviours, which interact to perform work in a domain. Work is expressed as transformations of object attribute values to achieve task goals, which comprise a task goal structure. The quality with which the task goal structure achieves the product goal specified in the GDP is expressed as Tq and the costs incurred by the users and computers are expressed as Uc and Cc.
CONCEPTION OF GEDP
A conception of the GEDP may be considered complete, if its expression is sufficient to identify the applicability of the GEDP, in terms of the GDP. It may be considered coherent, if its expression is sufficient to prescribe design knowledge for specifying the GDS. The ascription of performance guarantees must also be explicitly conceptualised for coherence. The conception of EDPs proposed here includes the concepts of: scope; comprising a class of users, a class of computers and a class of achievable performances; substantive component; methodological component; and performance guarantees. This conception of the GEDP 3, it is argued, is sufficiently coherent and complete to support the initial operationalisation, test and generalisation of EDPs, and so is potentially fit-forpurpose. The concepts of the GEDP are formally conceptualised at a level commensurate with the conception of the GDP. This conception of the GEDP supports carry-forward of coherent and complete design knowledge by supporting the expression of design knowledge, at the appropriate level of generality. This knowledge supports the operationalisation of CEDPs, and its success determines whether it is fit-for-purpose. CEDPs formally specify the relationship between a CDP and a corresponding CDS. The concept of classes supports the representation of design knowledge at different levels of generality. These classes are 2 Concepts from Dowell & Long which have been recruited into the conception of the GDS and the GEDP are in bold italics on first exposition.
Concepts which are novel to this paper are in bold on first exposition. Cummaford and Long 82 identified by reference to the scope of CEDPs – class hierarchies are not intended to constitute a taxonomy of all possible CDPs, but rather only of those CDPs for which a CDS exists. The ultimate success of a CEDP is measured by the performance achieved by the specific technologies supported by its application. The associated guarantees are based on the empirical testing of a series of instances of CEDP application. The coherent and complete conceptualisation which guides this operationalisation may thus be assessed for fitnessfor- purpose. The concepts of the GEDP are informed by the concepts of the GDP and GDS, as the purpose of the GEDP is to identify its applicability to the GDP and prescription of the GDS, if applicable. The GEDP supports the prescription of a GDS, which achieves the desired performance stated in the GDP, if identified as applicable. Scope of the GEDP Specifying criteria for identifying design problems, to which an EDP may be applied, ensures that the knowledge is applied only to those design problems for which it supports the specification of a design solution. Design problems contain not less than one or more users, interacting with not less than one or more computers, and some desired performance. The scope of the GEDP thus comprises a class of users (U-class), a class of computers (C-class) and a class of achievable performances (P-class). If the user and computer in the design problem are members of U-class and C-class respectively, and the desired performance stated in the design problem is a member of P-class, then a design solution would be produced and the actual performance of the solution would equal the desired performance stated in the design problem. The relationship between Uclass, C-class and P-class is developed by empirical testing of the implemented design solutions, produced by CEDP operationalisation. If the user, computer or the desired performance are outside the scope of the principle, then there is no guarantee that the design solution may be specified then implemented. For transaction systems, the criteria for establishing U-class membership would establish the minimum structures and behaviours required for some user, in conjunction with some member of C-class, to achieve a performance which is a member of P-class. Such structures might include knowledge of financial transactions with card-based payment technologies. Supported behaviours might include matching goods descriptions to their shopping goals. The criteria for C-class membership might include structures such as a Virtual Shopping Cart, and supported behaviours, such as real-time processing of payments via the internet. P-class would specify the product goal, e.g. support the exchange of resources for currency, which could be achieved by members of U-class and C-class, to a desired level of task quality, whilst incurring an acceptable level of costs.
Substantive and Methodological Components of GEDP
EDPs contain substantive and methodological design knowledge which may be applied to any design problem within the scope of the EDP. The substantive component is characterised by the conceptualisation of user and computer structures and behaviours, comprising the worksystem, which are present in some instance of the class of users (Uclass) or class of computers (C-class) respectively. The methodological component supports the conceptualisation of a task goal structure, comprising task goals, to be effected by the worksystem, which achieves the product goal stated in P-class. The product goal specifies the work to be effected in the domain by the worksystem, in terms of object attribute value transformations. The structures and behaviours specified in the substantive component are sufficient to achieve the task goal structure specified in the methodological component to an acceptable level of task quality, whilst incurring some acceptable level of costs; where task quality and worksystem costs are members of P-class. This sufficiency is supported by empirical testing of a CEDP, which indicates whether the GEDP is fit-for-purpose. Support for the conceptualisation of user and computer structures and behaviours may take the form of models of interaction between user and computer, expressed as structures supporting behaviours. In the case of transaction systems, a mercantile model of the stages of a transaction to support the specification of behaviours, sufficient to achieve the required domain transformations, would constitute candidate substantive knowledge. One such model (Kalakota & Whinston, 1996) characterises a transaction as: prepurchase determination (information seeking); purchase (agreement of a contract for exchange); and postpurchase interaction (exchange, and evaluation of the product). This model might indicate that information seeking behaviours are necessary to complete a transaction, these behaviours being supported by structures, e.g., purchasing goals, hands. Summary of GEDP Conception This paper proposes a conception of EDPs within which guarantees may be developed for formal HCI engineering design knowledge. The conception proposed thus far comprises the following concepts and relationships: For any design problem {user, computer, Pd} and any EDP {U-class, C-class, P-class, substantive component, methodological component} If user is a member of U-class and computer is a member of C-class, then user structures and behaviours, and computer structures and behaviours, stated in the substantive component are present. If user structures and behaviours and computer structures and behaviours specified by the substantive component are present then the task goal structure specified by the methodological component is achievable. If the task goal structure specified in the methodological component is effected by a worksystem comprising the structures and behaviours specified in the substantive component then the product goal will be achieved, task quality will be x, user costs will be y and computer costs will be z. If task quality x, user costs y and computer costs z are achieved, Then Pa = Pd. Therefore, Pd is a member of P-class for a worksystem comprising instances of U-class and C-class. This conception may be said to be coherent, as it is based on two relationships: the relationship between the task goal structure and Tq for some product goal, and the relationship between the worksystem structures and behaviours, sufficient to achieve this task goal structure, and Uc and Cc. These relationships may be said to be coherent, as performance is a function of the efficacy with which some task goal structures are achieved by some worksystem structures and behaviours. The GEDP conception may be considered complete, as the concepts of the conception of the engineering discipline of HCI, which inform its development, appear within it. The issue of fitness-for-purpose will be addressed via operationalisation of the conception of the GEDP to inform the development of CEDPs, which may then be tested and generalised.
Validation and Ascription of Guarantees to EDPs
Operationalisation of the GEDP as CEDPs supports empirical testing of the class-level design solutions prescribed. This testing establishes whether the GEDP is fit-for-purpose, that is, it supports the specification then implementation of a design solution which achieves the desired level of performance stated in the design problem. The fourth stage of validation, generalisation, involves establishing the generality of the CEDP. These four stages of validation support the ascription of a guarantee that a worksystem, which performs the task goal structure specified in the methodological component of the EDP, achieves a level of Tq within the P-class stated in the EDP. A second guarantee, that the substantive component supports the specification of a worksystem, which exhibits the structures and behaviours sufficient to achieve the task goal structure, specified in the methodological component, whilst incurring a level of costs within the P-class stated in the EDP, may then be ascribed. A third guarantee, that correct application of the EDP to a design problem, within its scope supports the specification then implementation of a design solution which achieves Pd, is then ascribed on the basis of the former guarantees and further empirical testing. EDPs thus support the specification then implementation of a design solution which achieves the desired performance, if the design problem is within the scope of the EDP.
STRATEGY FOR CEDP DEVELOPMENT
Stork & Long (1994) have applied the conception of HCI to establish a basis for developing EDPs. They have operationalised the general HCI design problem by metricating the concepts, of which it is comprised, to express a specific design problem (SDP) in the domain of domestic energy management. Metrication provides observable and measurable criteria against which to assess performance. The design solutions (SDSs) of such specific design problems and the abstraction of prescriptive knowledge would constitute an EDP – the goal of Stork and Long. However, the operationalisation of an SDP per se does not ensure that a CDP, of which the SDP is an instance, will be found, other than by the assumption of a single domain. This strategy may be termed the ‘initial instance’ strategy, as it seeks to develop CEDPs by specifying design knowledge for SDPs, by means of SDSs, and then generalising across instances. This approach may be contrasted with an alternative ‘initial class’ strategy for CEDP development, as proposed here. The ‘initial class’ strategy supports CEDP development by constructing solutions to CDPs and then construing relevant design knowledge. Because this knowledge is construed at the class level, it is promising for CEDP development. The development of CDPs prior to operationalisation is therefore desirable, as this development constrains the DPs operationalised to those which offer promise in supporting the identification of class-level knowledge. A class may be considered promising for development, if an SDS exists and there are SDPs which share features of the solved SDP. Once such an initial class hypothesis has been formulated, the viability of the class may be assessed by examination of the work performed and the worksystem structures and behaviours sufficient to achieve Pd. If the performance achieved by the worksystem (Pa), specified in the SDS, is similar to the Pd of other SDPs (i.e. Pa = Pd), then the SDPs show promise for CDP development. Cummaford and Long 84
Method for CDP development
The first phase of the ‘initial class’ strategy for CDP development involves identification of an SDP and a corresponding SDS. The second stage involves identifying further SDPs which require a similar Pd, which supports specification of P-class. The user(s) and computer(s) which are to achieve P-class are then assessed for similarities. They may be considered similar, if the user(s) and computer(s), specified in each SDP, comprise sufficient structures supporting sufficient behaviours to achieve P-class. If this sufficiency holds, these user(s) and computer(s) form U-class and C-class of the CDP respectively. In practice, once P-class has been specified, developing CDPs involves identifying U-class and testing instances (members) of this class interacting with instances of C-class. These instances of U-class and C-class are then used to inform the development of a CDS, which achieves P-class. The level of generality should be considered prior to development. Classes which contain very few instances low in the hierarchy contain design knowledge which is very specific. The costs of developing a class at a given level of generality should be balanced against the number of instances to which it may be applied successfully.
Candidate CDPs: Internet-Based Transaction Systems
A class of transaction system design problems has been identified and is presented to illustrate the concept of CDPs. This parent class has three instances (subclasses), each of which is also a class. Each subclass is characterised by P-class, to be achieved by U-class interacting with C-class with respect to some domain. The general characteristics of each of these CDPs are inherited from the parent class. The subclasses of transaction system CDP are: (homogeneous) physical goods (e.g. books); information (e.g. online newspapers); and banking and finance (e.g. loans). These subclasses are abstractions over SDPs, e.g. a design problem concerning a transaction system to support the effective exchange of books for currency in an internet bookshop is an instance of the class of (homogeneous) physical goods. Subclasses may be distinguished by P-class. Differences in the product goal required for each of these subclasses have been identified for physical goods and information sub-classes (Hallam-Baker, 1997). In addition to these two classes, a banking CDP has been developed. The classes differ in the nature of the resources exchanged, the immediacy of the exchange, the possibility for reversing the transaction and the potential loss to the vendor. These differences in product goal indicate that the CDSs for these subclasses will specify classes of worksystem with different task goal structures, as the respective worksystems perform different work. It should be noted that candidate CDPs are identified on the basis of differences in the domain objects transformed by the respective worksystems. Operationalisation of CDPs will support the assessment of whether such differences will result in different worksystem specifications. Each CDS specified is then assessed to establish the task goal structure, sufficient to achieve a level of Tq within P-class. This sufficiency informs the development of the methodological component of the corresponding CEDP. The worksystem structures and behaviours sufficient to achieve the task goal structure, whilst incurring a level of Uc and Cc within P-class, are then construed. These structures and behaviours inform the development of the substantive component of the CEDP. Validation and the ascription of guarantees are based on subsequent operationalisations of the conceptualised CEDPs.
FUTURE RESEARCH
The ‘initial class’ strategy will be operationalised, resulting in CDPs and CDSs for the three transaction system subclasses identified. These CDPs and CDSs will be used to inform CEDP development. The resulting CEDPs will be operationalised and tested to inform the development of guarantees. If these stages of validation are successful, the CEDPs will be generalised and the CEDPs may be considered valid. Abstraction of these subclass CEDPs will be used to produce the parent CEDP, which will then be operationalised, tested and generalised.
ACKNOWLEDGEMENTS
This research associated with this paper was carried out under an EPSRC studentship.
REFERENCES
Dowell, J. and Long, J. B. (1989) Towards a conception for an engineering discipline of human factors. Ergonomics 32, 1513-1536.
Dowell, J. and Long, J. B. (1998) Conception of the cognitive engineering design problem. Ergonomics 41, 2, 126-139.
Hallam-Baker, P. M. (1997) User Interface Requirements for Sale of Goods. Available from: http://www.w3.org/ECommerce/interface.html
Kalakota, R. and Whinston, A. B. (1996) Frontiers of Electronic Commerce. Reading, Mass: Addison-Wesley.
Long, J. B. (1996) Specifying relations between research and the design of human-computer interactions. International Journal of Human Computer Studies, 44, 6, 875-920.
Long, J. B. and Dowell, J. (1989) Conceptions of the discipline of HCI: craft, applied science, and engineering. in Sutcliffe A. and Macaulay L., (Eds.) Proceedings of the Fifth Conference of the BCS HCI SG. Cambridge: Cambridge University Press.
Stork, A. and Long, J. B. (1994) A specific planning and control design problem in the home: rationale and a case study. in Proceedings of the International Working Conference on Home- Oriented Informatics, Telematics and Automation. University of Copenhagen, Denmark. 419-428.