Toward Engineering Design Principles for HCI

This is the second of two books about engineering design principles for HCI (HCI-EDPs). The books report research taking an HCI engineering discipline approach to the acquisition of initial HCI-EDPs. The first presents the background to the present volume. The background comprises: HCI; HCI design knowledge for EDPs, and HCI-EDPs – a way forward for HCI design knowledge (Long, Cummaford and Stork, 2022, in press). The HCI design knowledge is categorised as: craft artefacts and design practice experience; models and methods, and principles, rules, and heuristics. Together, they constitute best-practice for acquiring HCI-EDPs. This book reports two case studies of the acquisition of such initial HCI-EDPs. It begins with a summary of the earlier volume, sufficient for an understanding of the case studies reported in full here. The themes, concepts and ideas developed in the books concern HCI design knowledge, a critique thereof and the related challenge. The latter is expressed as the need for HCI design knowledge to support design practice more effectively. The challenge, then, to HCI design knowledge, is to increase its fitness-for-purpose in support of such HCI design practice. HCI-EDPs are proposed here, as one response to the challenge. The book reports the acquisition of initial HCI-EDPs. A discipline approach is adopted to provide a framework for HCI. An HCI engineering discipline approach is adopted to provide a framework for HCI-EDPs. The approach affords design knowledge, supporting ‘specify then implement’ design practices. Strategies for developing HCI-EDPs are presented together with conceptions of human-computer systems, required for the operationalisation of their associated design problems and design solutions. Case studies of the two domains of domestic energy planning and control, and business-to-consumer electronic commerce are reported. Acquisition of the initial EDPs applied best-practice design knowledge, at the time of the research, in the form of ‘specify, implement, test and iterate’ design practices. Current best-practice can be used similarly to acquire new HCI-EDPs. Each initial HCI-EDP acquisition case study includes: introduction; two development cycles, and presentation and assessment. Carry forward of the HCI-EDP progress is identified. The HCI-EDPs are considered to be initial, as they are incomplete and unvalidated. It is a book primarily for postgraduate students and young researchers wishing to develop further the idea of HCI-EDPs and comparable other more reliable HCI design knowledge. The book is structured to support both the understanding and the operationalisation of HCI-EDPs, as required for their acquisition, their long-term potential contribution to HCI design knowledge and their ultimate application to design practice.

Keywords

HCI design principles; HCI Engineering Design Principles (HCI-EDPs); discipline; engineering; HCI engineering discipline; design knowledge; critique; challenge; design best-practice; domestic energy planning and control; business-to-consumer electronic commerce; domain; case study.

The book is one of two. The companion volume is ‘HCI Design Knowledge – Critique, Challenge and a Way Forward’ (Long et al., 2022, in press). The title of this book describes its scope and content. The scope is HCI (human-computer interaction) and HCI engineering design principles (HCI-EDPs). The content is the acquisition of initial HCI-EDPs. The challenge to existing HCI design knowledge is identified as its lack of reliability, when applied to design practice. Its support for the latter, then, needs to be more effective. HCI-EDPs are one response to this challenge.

The book presents ‘instance-first’ and ‘class-first’ approaches to the acquisition of HCI-EDPs, as instantiated in the two case studies. The EDPs are constructed from solutions to design problems, themselves derived from user requirements. The case study application domains are domestic energy planning and control, and business-to-consumer electronic commerce. Both report the acquisition of initial HCI-EDPs and comprise chapters on: their introduction; two cycles of development, and their presentation and assessment.

The publication of such a book is timely. Both approaches to the acquisition of HCI-EDPs are novel. They have little by way of competition with the exception of  ‘design patterns’. A review of the HCI research literature indicates the need for more effective support for HCI design practice. The case studies espouse the same HCI discipline and HCI engineering conceptions. Any differences in operationalisation inform future research, for example, the strategy adopted and the types of principle acquired. Both case studies serve to support researchers to build on the work. Practice assignments at the end of each chapter offer further support for research applications. The final chapter suggests carry forward to support future research of acquiring HCI-EDPs.

Such a book is needed. The strategies for acquiring HCI-EDPs, constitute a novel contribution to HCI research. Further, the book differs from other books concerning HCI design knowledge and its application, such as Ritter, Baxter, and Churchill (2014) ‘Foundations for Designing User-Centered Systems’; Hartson and Pyla (2018) ‘The UX Book: Agile UX Design for a Quality User Experience’; Kim (2020) ‘Human-Computer Interaction – Foundations and Practice’ and Zagalo (2020) ‘Engagement Design: Designing for Interaction Motivations’. In contrast, the present book conceives HCI design knowledge in terms of an HCI engineering discipline. HCI-EDPs support ‘specify then implement’ design practice. They are acquired by the existing best-practice at the time of their acquisition. The book constitutes a contrast with the books referenced. Their best-practice, however, can be applied currently to acquire additional HCI-EDPs. 

The book also differs from Long (2021) ‘Approaches and Frameworks for HCI Research’. He proposes an approach and a framework for HCI as engineering and also refers to specific and general HCI engineering principles. He underlines the need for empirical validation to increase the reliability of HCI design knowledge. However, unlike the present book, no conception or operationalisation of HCI-EDPs is offered. Last, Long presents no case studies as reported here. In brief, this book is best understood as starting from where Long left off.

The authors feel qualified to write such a book. They developed the approach to HCI-EDP acquisition, during their time at University College London. It has been used to frame HCI research teaching and to support associated research of which the two case studies are an example.

Chapters 2-6 are based on Stork’s PhD thesis (1999) and Chapters 7-11 on that of Cummaford (2007). Comparable work has yet to be published elsewhere with the exception of design patterns. Long was the initiator of the work and supervisor in both cases. He is also responsible with Morgan&Claypool and Springer for bringing the book to publication. For these reasons, Long appears as first author, with Cummaford and Stork ordered alphabetically. However, all chapters have been reviewed by all authors.

Last but not least, the book would not have been possible without the associated research and support of colleagues, especially that of John Dowell, as well as of PhD students at the EU/UCL Unit (University College London).

The research book is for graduate and postgraduate students of HCI. It is also for young academic researchers and their supervisors. Practice assignments, at the end of each chapter, support their understanding and application of the concepts presented. In particular, the case study-related assignments support researchers in conceptualising and operationalising HCI-EDPs and so building on the present research in the same and different domains of application. The book is also of interest to researchers in related disciplines and movements, contributing to HCI, such as cognitive psychology, UX-design, design science, software engineering, design research, human-factors, agile design, cognitive ergonomics and human-centred informatics (see earlier references).

Acknowledgement

The book is offered as a tribute to colleagues and PhD students at the EU/UCL Unit (University College London), whose earlier research contributions have made it possible (see also <hciengineering.net> for more information concerning those contributions).

Thanks

Thanks are due to Jack Carroll for including the book in his Synthesis Lectures on Human-centred Informatics Series as a ‘red bloodied’ (sic) research outlier intended to maintain the series coverage. Also, to Diane Cerra, Christine Kiilerich and Deborah Gabriel for enthusiastic and faultless editing and compositing, in bringing the book to print.  Thanks are also due to anonymous reviewers, who have con­tributed to improving the clarity and coverage of an earlier draft.

Chapter 1. HCI Design Knowledge – Critique, Challenge and a Way Forward

1.1 HCI

1.2 HCI Engineering

1.3 HCI Engineering Design

1.4 HCI Engineering Design Principles

1.5 Critique, Challenge and a Way Forward

1.6 Practice Assignment

Chapter 2. Introduction to Initial HCI Engineering Design Principles for Domestic Energy Planning and Control

2.1 Conception of Substantive HCI Engineering Design Principles

2.2 Strategy for Developing HCI Engineering Design Principles

2.3 Conception of Human-Computer Systems

2.4 Practice Assignment

Chapter 3. Cycle 1 Development of Initial HCI Engineering Design Principles for Domestic Energy Planning and Control

3.1 Operationalising Specific Design Problems and Solutions

3.2 Conception of Planning and Control

3.3 Cycle 1 Best-Practice Development

3.4 Cycle 1 Operationalisation

3.5 Practice Assignment

Chapter 4. Cycle 2 Development of Initial HCI Engineering Design Principles for Domestic Energy Planning and Control

4.1 Cycle 2 Best-Practice Development

4.2 Cycle 2 Operationalisation

4.3 Practice Assignment

Chapter 5. Initial HCI Engineering Design Principles for Domestic Energy Planning and Control

5.1 Detailed Strategy

5.2 Initial HCI Engineering Design Principles Identified During Operationalisations

5.3 Initial Assumption Assessment from Operationalisations

5.4 Inspirational Initial HCI Engineering Design Principles from Operationalisations

5.5 Initial HCI Engineering Design Principles from General Guidelines

5.6 Initial HCI Engineering Design Principles from MUSE Guidelines

5.7 Initial HCI Engineering Design Principles for HCI from MUSE Tasks

5.8 Practice Assignment

Chapter 6. Assessment and Discussion of Initial HCI Engineering Design Principles for Domestic Energy Planning and Control

6.1 Strategy Assessment and Discussion

6.2 MUSE for Research (MUSE/R)

6.3 Practice Assignment

Chapter 7. Introduction to Initial HCI Engineering Design Principles for Business-to-Consumer Electronic Commerce

7.1 Conception of HCI Engineering Design Principles

7.2 Strategy for Developing HCI Engineering Design Principles

7.3 Method for Operationalising the Class-First Strategy

7.4 Identification of Class Design Problems

7.5 Practice Assignment

Chapter 8. Cycle 1 Development of Initial HCI Engineering Design Principles for Business-to-Consumer Electronic Commerce

8.1 Cycle 1 Development

 8.2 Cycle 1 Class Design Problem/Class Design Solution Specification

8.3 Practice Assignment

Chapter 9. Cycle 2 Development of Initial HCI Engineering Design Principles for Business-to-Consumer Electronic Commerce

9.1 Cycle 2 Development

9.2 Cycle 2 Class Design Problem/Class Design Solution Specification

9.3 Practice Assignment

Chapter 10. Initial HCI Engineering Design Principles for Business-to-Consumer Electronic Commerce

10.1 HCI Engineering Design Principle Specification Requirements

10.2 HCI Engineering Design Principles Acquired in Cycle 1 Development

10.3 HCI Engineering Design Principles Acquired in Cycle 2 Development

10.4 Initial HCI Engineering Design Principles

10.5 Practice Assignment

Chapter 11. Assessment and Discussion of Initial HCI Engineering Design Principles for Business-to-Consumer Electronic Commerce

11.1 Introduction

11.2 Strategy Assessment

11.3 Discussion

11.4 Business-to-Consumer Best-Practice Update

11.5 Practice Assignment

Chapter12. Progress and Carry Forward of HCI Engineering Design Principles for Future Research

12.1 Towards HCI Engineering Design Principles – General Progress and Carry Forward

12.2 HCI Engineering Design Principles – Research Remaining

12.3 Practice Assignment

                                                      CHAPTER 9

Cycle 2 Development of Initial HCI Engineering Design Principles for Business-to-Consumer Electronic Commerce

Summary

This chapter reports the Cycle 2 development of initial HCI-EDPs for the domain of business-to-consumer electronic commerce. The chapter comprises: Cycle 2 development and Cycle 2 class design problem/class design solution specification

9.1 Cycle 2 Development

This section reports the development of a class design problem and class design solution for electronic goods (information and software). The development comprises operationalisation of the method for identifying class design problems and their class design solutions, presented in Section 7.3.2. This section follows the stages of the method.

9.1.1 Introduction

The class design problem for electronic goods is identified on the basis of commonalities between the two specific design problems selected. The latter concern SMS-based sports news alerts (ManUtd.com) and mobile ‘phone ring-tones and software (Jamster.com). The class design problem is evaluated, following the method preesented in Section 7.3.2 and is accepted. A class design solution, corresponding to the class design problem, is then specified. The latter is instantiated as specific design solutions, corresponding to the two specific design problems identified. This enables testing.

The class design solution performance is abstracted from specific performances of the constructed specific design solutions. The actual performance achieved equals the desired performance specified in the class design problem. Hence, the class design solution is also accepted.

The class design problem and class design solutions are presented in Section 9.2. This facilitates comparison of the models with the conception of class design problems and class design solutions presented in Section 7.1.

9.1.2 Selection of Systems for Specific Design Problem and Specific Design Solution Development.

Two e-shops are selected on the basis of similarities in work supported, namely the sale of data products. Both e-shops informally appear to have actual performances that do not equal desired performance. Hence, they are considered promising for the specification of specific design problems. The two e-shops selected were both live commercial operations at the time of the research.

– Specific Design Problem 2a: Manchester United Text Alerts Service (www.manutd.com) is a service offered by the official website of the UK Premiership football club. Users sign up to receive details by SMS of events occurring in football matches played by Manchester United.

– Specific Design Problem 2b: Jamster (www.jamster.com) is a website offering mobile ‘phone ring-tones, games and screen-savers for sale. Users sign up and purchase items, which are then sent to the user’s ‘phone for use.

9.1.3 Testing Procedure

Cycle 2 uses a similar procedure to that of Cycle 1. To determine comparative performance of the specific design problem systems and their associated specific design solution systems, each specific design problem and specific design solution task goal structure is first assessed analytically to enumerate user costs.

Task quality for each specific design problem and specific design solution system is then determined by empirical testing. The latter is carried out following specification of the specific design solution systems. This is to support comparison of the relative workload, incurred using the systems. The results are presented to exemplify the behaviours, which result in actual performance not equalling desired performance for the specific design problem systems.

9.1.3.1 Setup

Following Cycle 1, screenshots were taken and used to create offline simulations of each e-shop. These are termed ‘prototypes’. These ensure that all users interact with the same e-shop design. It also ensures that the analytical data in the relevant design problem costs matrix are  based on the same system.

The prototypes are constructed in PowerPoint, from screen-shots taken during walkthroughs of the live websites. Also presented are photos of SMS messages received from the sites during task completion. Each PowerPoint presentation contains the required screens for users to complete each task specified in the product goal for that system. Additional screens are included where necessary. The latter anticipate users selecting links that are not on the correct path for task completion. Data relating to specified shopping tasks are included in the screenshots, for example, descriptions and prices of the goods to be purchased.

9.1.3.2 Participants

Six participants were recruited for the study of each e-shop design problem/design solution pair. None was tested in Cycle 1, to avoid learning effects. An equal number of male and female participants were tested.

Specific Design Problems 2a and 2b both include the following pre-purchase requirements:

• Customer must be older than vendor’s minimum age limit
• Customer must be within vendor’s domain of contract
• Customer must have a ‘phone which is supported by the vendor
• Customer must have access to payment technology supported by the vendor
• Vendor must offer for sale the items, which the customer wishes to purchase
• Customer must have sufficient funds to complete the transaction
•  

All participants resided in the UK in the vendor’s domain of contract. The participants were all over 16, with experience of using a mobile ‘phone.

The Specific Design Problems 2a and 2b participant models both specify that they have knowledge of shopping, payment, value for money, and personal wherewithal. All participants had previously used an online shop. They were therefore considered to possess the abstract structures specified in the associated participant models. None of the participants had previously used the shops selected for the study, to avoid learning effects.

Four of the participants had first-hand knowledge of purchasing information goods online. For example, news alert services or premium downloads (including ring-tones). So they possessed knowledge of mobile ‘phone services, as specified in the user model. The remaining two participants were interviewed and found to be familiar with the concepts associated with purchasing mobile ‘phone services. All participants are considered to possess the abstract structures specified in the Specific Design Problems 2a and 2b user models.

The order of design problem and design solution presentation is balanced over participants for learning effects between prototypes. Participants are only shown one design problem/design solution pair (that is, 2a or 2b), and not both, to avoid learning effects.

9.1.3.3 Procedure

The Cycle 2 testing followed that of Cycle 1.

9.1.3.4 Testing Tasks

Five tasks were specified for each of the systems tested. The tasks include a range of behaviours encountered during typical shopping experiences. Similar tasks are specified for Specific Design Problems 2a and 2b. The five tasks are:

1. Purchase a single item

2. Find total price for single item

3. Sign up for subscription

4. Find total price for subscription (per month)

5. Cancel subscription

9.1.3.5 Calculation of User Costs

The task goal structure contains descriptions of the user and computer tasks required to complete each task. The user abstract and physical behaviours are also listed. These behaviours are identified using the same criteria as in Cycle 1and as identified in Section 9.1.

The costs matrices show the user costs required to complete each of the specified tasks. The costs are calculated normatively to give an expression of workload for ideal, error free task completion. This enables comparison of the efficiency of the specific design problem and specific design solution systems in terms of their ideal operation. The costs matrices also include the empirical performance data from testing, to determine their relative effectiveness.

The results from each specific design problem test are summarised in the next section. The results from each specific design solution test are summarised later.

9.1.4 Specify Specific Design Problems

The results from the testing of Specific Design Problems 2a and 2b are presented next to exemplify the behaviours resulting in actual performance not equalling desired performance.

9.1.4.1 Specific Design Problem 2a

Users were asked to complete the following specific tasks, with both the specific design problem and specific design solution systems:

T1: Sign to alerts for a single match

T2: Find total price for single match

T3: Sign up for monthly subscription 

T4: Find total price for subscription per month

T5: Cancel subscription

The costs matrix for Specific Design Problem 2a is shown in Table 9.1.

Table 9.1 Specific Design Problem 2a: Costs Matrix

The top area of the first page of the site (Figure 9.1) gives an overview of: the packages available; details of how to unsubscribe from other services; costs for the service, and text detailing how to operate the service. An example is how to unsubscribe. The bottom area is shown in Figure 9.2.

Figure 9.1: Specific Design Problem 2a: Screen S1 Service Overview Page [top]

All users completed T1 successfully. They realised that they must sign up before the match, and then unsubscribe after the match. The high times-to-complete for T1 are due to users searching for a single match sign-up option and to understand that they must subscribe and then unsubscribe.

Figure 9.2: Specific Design Problem 2a: Screen S1 Service Overview Page [bottom]

Users are considered to have completed the task after they had signed up, and realised that they must unsubscribe. They were not required actually to unsubscribe. This is to evaluate the unsubscribe functionality in T5.

Users are provided with a list of the text alerts received during T2. Two users miscalculated the total costs.

The work involved in T3 (‘sign up for monthly subscription’) is similar to the work involved in T1. Users, who had completed T1 successfully performed the task without problems. The sign-up page is shown in Figure 9.3.

Figure 9.3: Specific Design Problem 2a: Screen S2.2b Signup Page

To complete T4, users were again provided with a list of text alerts received during one month (taken form ‘phone records detailing use of the actual service, during the football season). The task completion failures are higher than for T2 possibly because of the larger number of text alerts. This is in addition to Users 4 and 6 not using the correct tariff for their own ‘phone service provider.

In order to complete T5, users had to change the service level to ‘off’. This was not understood by User 2. It also required Users 4 and 6 to re-read the instructions text on the main page, before they understood the correct action required. All users commented that setting the service level to ‘off’ was not an easy concept to understand. An ‘unsubscribe’ option would have been clearer. The service level dropdown is shown open in Figure 9.4.

Figure 9.4: Specific Design Problem 2a: Screen S2.2b Signup Page [showing service dropdown]

9.1.4.2 Specific Design Problem 2b

Users were asked to complete the following specific tasks, with both the specific design problem and specific design solution systems:

T1: Purchase a single ring-tone

T2: Find total price for a single ring-tone

T3: Sign up for a monthly subscription 

T4: Find total price for a monthly subscription

T5: Cancel subscription

The costs matrix for Specific design problem 2b is shown in Table 9.2.

Table 9.2 Specific Design Problem 2b: Costs Matrix

T1 required users to purchase a specific ring-tone (‘Crazy Frog – Axel F’) from the homepage of Jamster.com. When the ring-tone name or the ‘get it now’ button was clicked, a pop-up appeared, offering an audio preview of the ring-tone. The homepage and pop-up are shown in Figure 9.5, with the relevant links circled in green.

9.5 Specific Design Problem 2b: Screen S1 Homepage

When users clicked ‘get it now’ on the pop-up, they were shown the sign-up screen (Figure 9.5). All users then entered their ‘phone number, and clicked ‘next’. This began the process to sign up for a weekly subscription. To sign up for a single ring-tone, the ‘single purchase’ (circled in Figure 9.5) must be clicked, instead of entering a ‘phone number and clicking ‘next’. No user clicked the ‘single purchase’ link, and so no user completed the task successfully.

          Figure 9.6 Specific Design Problem 2b: Screen S2.2b Order Item

Users are then shown a series of SMS message screenshots, taken from actual downloads purchased on the live site (Figure 9.7). Four users realised that they had then signed up for a subscription. They considered the cost of the single ring-tone to be the weekly subscription rate for one week. That is, the total amount that they would have paid before unsubscribing. Two users identified the weekly subscription cost from the message simply as being the cost of the single ring-tone. The weekly subscription rate was not equivalent to the price of a single ring-tone purchase on the site. So no user completed T2 successfully.

Figure 9.7 Specific Design Problem 2b: SMS4.1 Welcome to Subscription and SMS3 Download Item

During T3, users are asked to sign up for a weekly subscription Also, to purchase a screensaver (another Crazy Frog product). User 4 initially did not understand that they must first select a specific product (ring-tone, screen-saver etc) to sign up for a subscription, rather than vice versa. This resulted in a high time-to-complete. However, all users completed the task, by signing up for a screen-saver. Because users had now validated their mobile number for the session, the sign-up page did not require a ‘phone number. The screen-saver club was  a separate weekly subscription from the ring-tone club. So users were committing to an additional weekly recurring cost. No users correctly identified the commitment at this stage of the session. The sign-up page is shown in Figure 9.8.

      Figure 9.8 Specific Design Problem 2b: Screen S3b Enter Validation Code

Users are again shown a series of SMS message screenshots, taken from actual downloads purchased using the site. User 3 was by this point unsure as to what any of the services cost, and so did not complete the task. However, the other users correctly identified the subscription cost.

During the final task (T5), two users did not locate the ‘My Jamster!’ link (circled in Figure 9.9, top right). So they were not able to cancel their subscription. Both users said that they would have then unsubscribed by SMS. But this was counted as a task failure, given that the option to unsubscribe via the site was available.

       Figure 9.9 Specific Design Problem 2b: Screen S1 Homepage, with link to ‘My Jamster!’ highlighted

During discussion after the sessions, it became apparent that users did not generally realise that they had signed up for two separate weekly subscriptions. Even though they had to unsubscribe from two clubs in order to complete T5. They expressed some unwelcome surprise that they had actually committed to a recurring £6 per week of subscriptions. They did not think that this was made clear by the site.

9.1.5 Specify Class Design Problem

Following specific design problem specification, commonalities are abstracted to construct the class design problem domain model, product goal, task-goal structure and interactive worksystem model.

9.1.6 Evaluate Class Design Problem

The evaluated e-shops exhibit different behaviours, resulting in a similar product goal being achieved, but with different performances. There are some similarities between the Specific Design Problems 2a and 2b Task Goal Structures. But it is not possible to abstract a common Task Goal Structure for most tasks. Where no commonalities are abstracted, both Specific Design Problem Task Goal Structures are included in the Class Design problem Task Goal Structure for that task. The Class Design Problem user model and domain model are operationalised analytically, to check that the Task Goal Structure in each Specific Design Problem could be achieved. The user model contains sufficient behaviours to achieve the Task Goal Structure in each of the Specific Design Problems tested. The Class Design problem is thus retained.

9.1.7  Specify Class Design Solution

Class Design Solution 2 comprises a product goal, domain model, user model, computer model, and task-goal structure. The Class Design Problem product goal, domain model and user model are carried forward to the Class Design Solution without alteration. However, the computer model (including the physical structures embodied as screens), and the Task Goal Structure were designed during this phase. A combination of Task Goal Structure re-engineering and ‘craft’ HCI design techniques are used to design a Class Design Solution, which achieved Pd. This follows a similar process to that of Cycle 1.

The initial design activity involved re-engineering the Class Design Solution Task Goal Structure, by allocating as many participant behaviours as possible to the computer. Then, participant behaviours are removed from the set present in the Class Design Problem Task Goal Structure. This leaves the minimum set of behaviours required to effect the user and computer structure activations necessary to achieve the domain transformations specified in the product goal.

For example, the T2 (find price of single item) Class Design Solution Task Goal Structure differed from the Class Design problem Task Goal Structure, in that the computer physical structures in the Class Design Solution include display of the prices for individual items and subscriptions on the service homepage. This reduces the number of user behaviours required to ascertain the price of a single item, as they can simply read it from the homepage. This is instead of reading their phone bill (Specific Design problem 2a) or searching several pages of the site in order to locate it (Specific Design problem 2b). The Class Design Solution Task Goal Structure for T2 is shown in Table 9.3, and the homepage, with the single item price highlighted with a red outline, as shown in Figure 9.10.

Table 9.3 Class Design Solution 2: Task Goal Structure T2 Find Price of Single Item

Figure 9.10 Class Design Solution 2: C Screen S1 Homepage

The computer structures sufficient to support the participant and computer behaviours in the Task Goal Structure are then identified, and grouped into screens. The guidelines for e-commerce applications, identified in Cycle 1, are applied generally. But there was little available substantive support for the design of transaction systems for information goods. The author had commercial experience of designing such applications. As such, they were able to ensure that the Class  Design Solution design benefited from current best practice.

9.1.8 Specify Specific Design Solutions

The Class Design Solution is used to specify Specific Design Problems corresponding to those identified earlier. In contrast to Specific Design Problems 1a and 1b, the Specific Design Problems for Cycle 2 are very different in form.

9.1.8.1 Specific Design Solution 2a

The available packages, including single match packages, are displayed on the service overview page. This enables users to get an overview of the services and, most importantly, their total costs.

       Figure 9.11 Specific Design Solution 2a: Screen S1 Homepage

Once a service had been selected, the sign-up screen shows the package selected. This is in contrast to Specific Design Problem 2a, where users had to remember their desired service after choosing it on the service overview page. They then enter their selection on the sign-up page.

Figure 9.12 Specific Design Solution 2a: Screen S2.1 Enter Details Page (single match sub)

The system requires a validation code, which is sent to the specified ‘phone number by SMS, to be entered in order to complete sign-up. The validation code entry screen and confirmation screen are shown in Figures 9.13 and 9.14. The package selected by the user is included on both screens.

      Figure 9.13 Specific Design Solution 2a: Screen S3.1 Validation Page (single match sub)

      Figure 9.14 Specific Design Solution 2a: Screen S4.1 Confirmation Page (single match sub)

To change or cancel an existing subscription, the user enters their ‘phone number in the box at the bottom of the service homepage (Figure 9.11). They then cancel or select another package on the manage subscription page, as shown in Figure 9.15.

Figure 9.15 Specific Design Solution 2a: Screen S5 Manage Subscription Page

9.1.8.2 Specific Design Solution 2b

The homepage of Specific Design Solution 2b differs from that of Specific Design Problem 2b. The prices of single items and subscriptions are clearly displayed. Also, the login boxes for existing users to manage their subscriptions.

           Figure 9.16 Specific Design Solution 2b: S1 Homepage

The sign-up page presents single purchase and subscription options, with pricing for each. This ensures that the user is informed of the costs prior to purchase.

          Figure 9.17 Specific Design Solution 2b: Screen S2.1 Enter Details Page (single purchase)

The user’s selected package and its price are then displayed on both the validation code entry screen and the confirmation screen.

       Figure 9.18 Specific Design Solution 2b: Screen S3.1 Validation Page (single purchase)

The validation code entry page differs for the subscription option. An entry box for a password is included. This ensures that the user enters a password, and so is able to login on future visits, and so manage their subscriptions.

       Figure 9.19 Specific Design Solution 2b: Screen S3.2 Validation Page (monthly subscription)

       Figure 9.20 Specific Design Solution 2b: S4.1 Confirmation Screen (single purchase)

The manage subscription page presents the user’s remaining credit on their current subscription. The user is able to ascertain the current status of their subscription at any time. The cancel button is clearly displayed.

       Figure 9.21 Specific Design Solution 2b: S5 Manage Subscriptions Page

9.1.8.3 Testing Results

The costs matrices and subjective assessments of relative workload for Specific Design Problems 2a and 2b indicate that user performance is consistently higher when interacting with the Design Solution rather than the Design Problem prototypes.

Specific Design Problem 2a

Table 9.4 Specific Design Solution 2a: Costs Matrix

    Figure 9.22 Participants’ Subjective Ratings of Workload Interacting with Specific Design Problem 2a and Specific Design Solution 2a

Specific Design Problem 2b

       Table 9.5 Specific Design Solution 2b: Costs Matrix

                Figure 9.23 Participants’ Subjective Ratings of Workload Interacting with Specific Design Problem 2b and Specific Design Solution 2b

9.1.9 Evaluate Class Design Solution

The Class Design Solution performance is abstracted from the performances attained by each of the Specific Design Solutions. The Class Design Solution costs matrix contains the mean value for each element from the Specific Design Solution 2a and Specific Design Solution 2b costs matrices. Given that it would not be valid to find the mean task completion rate across individual users, the empirical components (task completion and time to complete) is calculated using mean values across all users for each system.

Table 9.6 Class Design Problem 2: Costs Matrix

Table 9.7 Class Design Solution 2: Costs Matrix

To facilitate comparison, the costs matrix shown in Table 9.7 details the change in values between Class Design Problem and Class Design Solution. Negative values indicate a reduction in costs between the Class Design Problem and Class Design Solution. Where costs increase between, they are shown in red. Task completion rates show the increase in task completion percentages, rather than reductions in tasks failures, in order to maintain a consistency with the labelling of the costs matrices.

Table 9.8 Comparison of Class Design Problem 2 and Class Design Solution 2 Costs Matrices

Users achieved a 100% task completion rate when interacting with the Class Design Solution, whilst incurring reduced costs. The Class Design Solution is therefore considered acceptable. It meets the success criteria defined in the Class Design Solution 2 Product Goal.

There is an increase of 15 keystrokes for T3. This is due to the user not having to register with a password on the Specific Design Problem systems. In Specific Design Problem 2a, the user could simply enter their ‘phone number and select to turn the service on, to subscribe. In Specific Design Problem 2b, the user is already logged in for the session, and so has direct access to the subscribe functionality. The Specific Design Solution systems both require validation of user identity prior to subscribing, for security reasons. Both Specific Design Solution systems require a validation code, sent to the handset via SMS. They also require users to enter a password before the subscription is made active. The validation code is considered necessary, to ensure that only the user of the ‘phone can authorise a billed transaction for their ‘phone number. The password enables the user to amend their subscription in future. A password is considered important. It enables the service to be cancelled, even if the user has lost their ‘phone and so does not have access to any validation codes sent to the ‘phone.

The user ratings of workload and comparative workload support the conclusion that less workload is required to complete the tasks with the Specific Design Solution systems. The latter, and therefore by extension the Class Design Solution, are considered to be acceptable. They fulfill the requirement in the Product Goals for the Class Design Solution and Specific Design Solutions that the systems should result in lower user costs for task completion.

            Figure 9.24 Participants’ Abstracted Ratings of Workload for Class Design Problem 2 and Class Design Solution 2

Figure 9.25 Participants’ Abstracted Comparison of Workload for Class Design Problem 2 and Class Design Solution 2

9.2 Cycle 2 Class Design Problem/Class Design Solution Specification

Section 9.1 reports the development of a class design problem and class design solution for electronic goods transaction systems, by means of the specification of two specific design problems and their corresponding specific design solutions.

9.2.1 Introduction

Section 9.2 presents the class design problem and class design solution models, specified during Cycle 2 development. The models follow the conception of the general design problem and general design solution for HCI.

The class design problem and class design solution presented are later used to develop an initial HCI-EDP. For each Specific Design Problem and Class Design Problem model, its components are presented in bold on first exposition.

9.2.2 Specify Specific Design Problems

Specific Design Problems 2a and 2b are specified.

9.2.2.1 Specific Design Problem 2a

Domain and Product Goal

Specific Design Problem 2a is a transaction system supporting the exchange of SMS-based information services for currency. The following tasks are defined, in order to evaluate the effectiveness of the Specific Design Problem:

T1: Sign to alerts for a single match

T2: Find total price for single match

T3: Sign up for monthly subscription 

T4: Find total price for subscription per month

T5: Cancel subscription

The domain model comprises the user, computer (e-shop) and the goods to be purchased. The domain model contains abstract objects, which are embodied in physical objects.

   Figure 9.26 SDP2a: Domain Model

The affordant domain attributes (shown in bold italics in the model) are changed by the worksystem, in order to achieve the Product Goal. The dispositional domain attributes must have the values specified in the Product Goal for the work to be performed.

The Product Goal specifies the required values for the dispositional domain object attributes. The latter must be satisfied for the work to be performed. Also specified are the affordant domain attribute value transformations that comprise the work.

              Table 9.9 Specific Design problem 2a: Product Goal Dispositional Object Attribute Value Requirements

Table 9.10 Specific Design Problem 2a: Product Goal Affordant Object Attribute Value Transformations

Worksystem

The Worksystem comprises a user, termed ‘SDP2a-U’, who interacts with a computer, termed ‘SDP2a-C’. SDP2a-U and SDP2a-C both comprise Representation Structures and Process Structures.

User model

The SDP2a User Model, termed SDP2a-U, comprises two types of abstract structure –representation structures (shown in boxes in the model) have particular states. For example, ‘items purchased’, which are transformed by process structures (shown in ovals in the model).

  Figure 9.27 Specific Design Problem 2a: User Model

The representation structure states for each stage of the work are detailed in the representation structure states matrix, shown in Table 9.11. Process structure activation is assumed to be coextensive with user abstract behaviours. The latter incurred during the work are specified in the Task Goal Structure.

Table 9.11 Specific Design Problem 2a: User Model Representation Structure States Matrix

SDP2a-U’s process structures support abstract behaviours, which are defined as ‘planning’, ‘controlling’, ‘perceiving’ and ‘executing’. The model represents only cognitive aspects of the user.

SDP2a-U’s abstract structures are embodied by its physical structures, which also support physical behaviours, that is, ‘clicking’, ‘keying’, and ‘searching’.

Computer Model

The SDP2a Computer Model, termed SDP2a-C, like SDP2a-U, comprises both representation structures and process structures, which support abstract behaviours. The abstract structures are embodied in physical structures. For example, memory, processors, which support physical behaviours.

The computer model abstract and physical structures and behaviours are not operationalised fully. The design problem allows for an increase in computer costs. As technological development is proceeding at a rapid pace, measuring computer costs is not considered necessary.

  Figure 9.28 SDP2a: Computer Model

Category mapping between models

The UM, CM and Product Goal contain concepts which appear similar, but are not co-extensive. These are summarised in the category mapping table shown in Table 9.12.

Product Goal	User	Computer
Exchange currency for receipt of SMS messages	Pay to receive SMS alerts	Exchange currency for delivery of SMS messages, and limited usage rights to their contents

            Table 9.12 Specific Design Problem 2a: Category Mapping Table

The user’s notion of item purchase may be naïve. They may consider the transaction to be a simple exchange of the item for the purchase price. However, the user does not ‘own’ the SMS files legally. They cannot, for example, sell the file to another user. By completing the purchase, the user accepts the vendor’s terms and conditions. These set out the user’s rights to personal usage of the file, but preclude any resale or forward communication of the data contained therein.

Task-Goal Structure

SDP2a-U and SDP2a-C interact, to achieve the Product Goal. The user and computer behaviours which interact to achieve the task goals are specified in the Task-Goal Structure. An excerpt from the Task Goal Structure is presented in Table 9.13.

Table 9.13 Specific Design Problem 2a: Task Goal Structure Task 3

The Task Goal Structure contains descriptions of the user and computer tasks required for completion. The user abstract and physical behaviours are also listed. They are categorised according to the criteria in Table 9.14.

User behaviours	Criteria
Encoding	User reads one page of information. If scrolling is required, another ‘encode’ behaviour is diagnosed for each additional screen of information. If the user registers that some information on the page has been updated in response to their recent action, this is not counted as an ‘encode’ behaviour
Planning	Change state of a UM abstract representation (i.e. transforms current plan for shopping)
Controlling	Determine next action to achieve current plan for shopping
Executing	Transcode abstract behaviour into physical behaviours

Table 9.14 Criteria for Diagnosing User Abstract Behaviours during Task Completion

Performance

Actual Performance

The task descriptions contained in the Task Goal Structure are developed normatively. This is to ensure that the data reflect actual user costs associated with error-free task completion. The user costs calculations can thus be compared validly between the Specific Design Problem and the Specific Design Solution. Neither is affected by user errors, which may impact the costs totals.

Actual task quality is measured empirically, as detailed earlier. The expression is a percentage of users who completed each task. Also, the mean time taken to complete each task. Both user costs and task quality are expressed in the costs matrix.

Table 9.29 Specific Design Problem 2a: Costs Matrix

Desired Performance

Task Quality

All instances where the pre-purchase requirements are satisfied should result in the product goal being achieved. A decrease in the time to complete for all tasks is desirable.

IWS costs

User costs should be acceptable. That is, lower than completing the transaction via the specific instances of this class of transaction system tested during Specific Design Problem 2a construction.

Any increase in computer costs is acceptable. The design solution must be implementable using existing technologies (that is, setup costs must not include development of new technologies).

Comparison of actual and desired performance

Actual performance for task completion is 22/30, that is, 73.3%. This is less than the desired 100%. The remaining aspects of Pd are expressed as desired reductions relative to Pa. So Pa is by definition not equal to Pd. Specific Design problem 2a is thus considered to be a design problem, and not a design solution.

9.2.2.2 Specific Design Problem 2b

The operationalisation of Specific Design Problem 2b is similar to that of Specific Design Problem 2a.

9.2.3 Specify Class Design Problem

Following specification of Specific Design problems 2a and 2b, commonalities at the device interaction level of description are identified and abstracted to construct the Class Design problem. This abstraction comprises common aspects of the Specific Design Problems, at a higher level of description, to provide an initial Class Design Problem expression. The Class Design Problem domain model, product goal, Task Goal Structure, user model and computer model are all constructed by abstraction. As it is not possible to test the Class Design Problem directly, there are no class-level users as such, Pa for the Class Design Problem is derived from the Specific Design Problems tested.

9.2.3.1 Domain and Product Goal

Class Design Problem 2 is a class of transaction systems, supporting the exchange of mobile-phone compatible files for currency, which do not achieve a stated desired performance. The class task involves purchasing one item, signing up for an ongoing subscription, and then cancelling that subscription. The task is:

1. Buy single item

2. Find total price for single item

3. Sign up for subscription

4. Find total price for subscription per month

5. Cancel subscription

The class domain model (termed ‘CDP2-D’) comprises the user, computer (e-shop) and the goods to be purchased. The domain model contains abstract objects, which are embodied in physical objects.

Figure 9.30 Class Design Problem 2: Domain Model (CDP2-D)

The affordant domain attributes (shown in bold italics in the model) are changed by the worksystem, to achieve the Product Goal. The dispositional domain attributes must have the values specified in the Product Goal, for the work to be done. The class domain model does not contain specific values for the object attribute values. The requirements for the object attribute values are specified in the Product Goal.

The Product Goal (termed ‘CDP2-PG’) specifies the required values for the dispositional domain object attributes, and a specification of the affordant domain attribute value transformations that comprise the work.

Table 9.15 Class Design Problem 2: Product Goal Dispositional Object Attribute Value Requirements

Table 9.16 Class Design Problem 2: Product Goal Affordant Object Attribute Value Transformations

12.2.3.2 Class Worksystem

The class worksystem comprises a class user, termed ‘CDP2-U’, who interacts with a class computer, termed ‘CDP2-C’. CDP2-U and CDP2-C both comprise Representation Structures and Process Structures. Both CDP2-U and CDP2-C are abstracted from the commonalities between the respective specific user and computer models in Specific Design Problems 2a and 2b.

CDP2-U

CDP2-U comprises two types of abstract structure – representation structures (shown in boxes in the model) have particular states. For example, ‘items purchased’, which are transformed by process structures (shown in ovals in the model).

Figure 9.31 Class Design Problem 2: User Model (CDP2-U)

The representation structure states for each stage of the work are detailed in the representation structure states matrix. Process structure activation is assumed to be coextensive with user abstract behaviours. The user abstract behaviours incurred during the work are specified in the Task Goal Structure, described later.

Table 9.17 Class Design Problem 2: User Representation Structure States Matrix

The process structures in CDP2-U support abstract behaviours, which are defined as ‘planning’, ‘controlling’, ‘perceiving’ and ‘executing’.

The abstract structures in CDP2-U are embodied by its physical structures, which also support physical behaviours, that is, ‘clicking’, ‘keying’, and ‘searching’.

CDP2-C

CDP2-C, like CDP2-U, comprises both representation structures and process structures, which support abstract behaviours. The abstract structures are embodied by physical structures, for example, ROM (read only memory), processors, which support physical behaviours.

Figure 9.32 Class Design problem 2: Computer Model (CDP2-C)

Category mapping between models

CDP2-U and CDP2-C interact to achieve the domain transformations specified in CDP2-PG. However, CDP2-U and CDP2-C’s understanding of the work to be performed are not co-extensive with the domain transformations specified in CDP2-PG. The mappings between the concepts in CDP2-PG and the worksystem models CDP2-U and CDP2-C are summarised in the category mapping table – 9.18.

Product Goal	User	Computer
Exchange currency for receipt of files	Pay to receive single files, or subscribe to receive a specified number of files within a specified time period	Exchange currency for delivery of files to a mobile device, and for limited usage rights on those files

           Table 9.18 Class Design Problem 2: Category Mapping Table

The category mapping table is abstracted from the category mapping tables specified in Specific Design Problems 2a and 2b.

Task-Goal Structure

CDP2-U and CDP2-C interact, to achieve CDP2-PG task goals. The user and computer behaviours, which interact to achieve the task goals are specified in the Class Task-Goal Structure (termed ‘CDP2-TGS’). The specific behaviours in SDP2a and SDP2b, at the device level of description, are not sufficiently similar to support generification of commonalities, and so the SDP2a-TGS and SDP2b-TGS contents are carried forward to CDP2-TGS. The total number of each behaviour required to complete the tasks in TGS-class are derived by taking the mean value for each behaviour across SDP2a and SDP2b. These values are represented in the class costs matrix.

Performance

Actual Performance

The task descriptions contained in CDP2-TGS are abstracted from the commonalities between the Task Goal Structures in Specific Design Problems 2a and 2b. CDP2-TGS is thus computer independent. The computer-specific aspects of the Specific Design Problem Task Goal Structures are not common between Specific Design Problems 2a and 2b. The class actual performance is derived from the mean number of each behaviour contained in the Task Goal Structures for Specific Design Problems 2a and 2b. These mean values are represented in the Class Design problem 2 costs matrix (termed ‘CDP2-CM’).

The class actual task quality is derived from the actual task quality of Specific Design Problems 2a and 2b.

Both user costs and task quality are expressed in CDP2-CM.

Table 9.19 Class Design Solution 1 Costs Matrix

Desired Performance

Task Quality

All instances where the pre-purchase requirements are satisfied should result in the product goal being achieved.

IWS costs

User costs should be acceptable, and lower than the class actual costs derived during specification of CDP2.

Any increase in computer costs is acceptable. The design solution must be implementable using existing technologies (that is, setup costs must not include development of new technologies).

Comparison of desired and actual performance

Actual performance for task completion is 61.67%. This is less than the desired 100%. The remaining aspects of Pd are expressed as desired reductions relative to Pa. So Pa is by definition not equal to Pd. Class Design Problem 2 is therefore considered to be a design problem, and not a design solution.

9.2.4  Evaluate Class Design Problem

The e-shops evaluated during the specification of Specific Design Problems 2a and 2b exhibit different behaviours at the device level of description. These differences result in a similar product goal being achieved, but with different actual performances. However, aspects of the work resulting in high workload are similar. They are therefore included in the Class Design Problem. The latter user model (CDP2-U) and computer model (CDP2-C) are operationalised analytically, to check that the Task Goal Structure in each Specific Design Problem could be achieved. CDP2-U and CDP2-C contain required behaviours to achieve the Task Goal Structure in each of the Specific Design Problems tested. The Class Design Problem is therefore retained.

9.2.5 Specify Class Design Solution

Best practice craft knowledge and guidelines are recruited to develop Class Design Solution 2. In addition, behaviours resulting in low task quality or high user costs are identified and re-engineered to increase potential achievable performance. The development is summarised earlier. Here, the Class Design Solution 2 components are presented to operationalise the conception of class design solutions presented earlier. Also, to enable the commonalities between CDP/S1 and CDP/S2 to be specified later.

9.2.5.1 Domain and Product Goal

Class design Solution 2 is a class of transaction systems, supporting the exchange of mobile-phone compatible files for currency, which achieve a stated desired performance. The class task involves purchasing one item, signing up for an ongoing subscription, and then cancelling that subscription. The task is:

1. Buy single item

2. Find total price for single item

3. Sign up for subscription

4. Find total price for subscription per month

5. Cancel subscription

The class domain model (termed ‘CDS2-D’) comprises the user, computer (e-shop) and the goods to be purchased. The domain model contains abstract objects, which are embodied in physical objects.

Figure 9.33 Class design Solution 2: Domain Model (CDS2-D)

The affordant domain attributes (shown in bold italics in the model) are changed by the worksystem, to achieve the Product Goal. The dispositional domain attributes must have the values specified in the Product Goal for the work to be done. The class domain model does not contain specific values for the object attribute values. The requirements for the object attribute values are specified in the Product Goal.

The Product Goal (termed ‘CDS2-PG’) specifies the required values for the dispositional domain object attributes. Also, a specification of the affordant domain attribute value transformations that comprise the work.

Table 9.20 Class Design Solution 2: Product Goal Dispositional Object Attribute value Requirements

Table 9.21 Class Design Solution 2: Product Goal Affordant Object Attribute Value Transformations

9.2.5.2 Class Worksystem

The class worksystem comprises a class user, termed ‘CDS2-U’ who interacts with a class computer, termed ‘CDS2-C’. CDS2-U and CDS2-C both comprise Representation Structures and Process Structures. Both CDS2-U and CDS2-C are abstracted from the commonalities between the respective specific user and computer models in Specific Design Solutions 2a and 2b.

CDS2-U

Figure 9.34 Class Design Solution 2: User Model (CDS2-U)

CDS2-U comprises two types of abstract structure – representation structures (shown in boxes in the model). For example, ‘item to purchase’, has particular states, which are transformed by process structures (shown in ovals in the model). The representation structure states for each stage of the work are detailed in the representation structure states matrix. Process structure activation is assumed to be coextensive with user abstract behaviours. The user abstract behaviours incurred during the work are specified in the Task Goal Structure, described later.

Table 9.22 Class design Solution 2: User Representation Structure States Matrix

The process structures in CDS2-U support abstract behaviours, which are defined as ‘planning’, ‘controlling’, ‘perceiving’ and ‘executing’.

The abstract structures in CDS2-U are embodied by its physical structures, which also support physical behaviours, that is, ‘clicking’, ‘keying’, and ‘searching’.

CDS2-C model

CDS2-C, like CDS2-U, comprises both representation structures and process structures, which support abstract behaviours. The abstract structures are embodied by physical structures, for example, memory, processors, which support physical behaviours.

Figure 9.35 Class Design Solution2: Computer Model (CDS2-C)

Category mapping between models

CDS2-U and CDS2-C interact to achieve the domain transformations specified in CDS2-PG. However, their models of the work to be performed are not co-extensive with the domain transformations specified in CDS2-PG. The mappings between the concepts in CDS2-PG and the worksystem models CDS2-U and CDS2-C are summarised in the category mapping table shown in Table 9.23.

Product Goal	User	Computer
Exchange currency for receipt of files	Pay to receive single files, or subscribe to receive a specified number of files within a specified time period	Exchange currency for delivery of files to a mobile device, and for limited usage rights on those files

Table 9.23 Class Design Solution 2: Category Mapping Table

Task-Goal Structure

CDS2-U and CDS2-C interact, to achieve a number of task goals. The user and computer behaviours which interact to achieve the task goals are specified in the class task-goal structure (termed ‘CDS2-TGS’). An excerpt from CDS2-TGS is presented in Table 9.24. TGS-class specifies the CDS2-U and CDS2-C task descriptions, but does not contain behaviours. The specific behaviours in SDS2a and SDS2b are not sufficiently similar to abstract commonalities. The total number of each behaviour required to complete the tasks in TGS-class are derived by taking the mean value for each behaviour across SDS2a and SDS2b. These values are represented in the class costs matrix (termed ‘CDS2-CM’

Table 9.24 Class Design Solution 2: Task Goal Structure Task

9.2.6 Evaluate Class Design Solution

Evaluate Class Design Solution

9.2.6.1 Actual Performance

Actual Performance

The task descriptions contained in CDS2-TGS are abstracted from the commonalities between the Task Goal Structures in Specific Design Solutions 2a and 2b. CDS2-TGS is therefore computer independent. The computer-specific aspects of the Specific Design Problem Task Goal Structures are not common between Specific Task Design Solutions 2a and 2b. The class actual performance is derived from the mean number of each behaviour contained in the Task Goal Structures for Specific Design Solutions 2a and 2b. These mean values are represented in the Class Design Solution 2 costs matrix (termed ‘CDS2-CM’).

The class actual task quality is derived from the actual task quality of SDS2a and SDS2b.

Both user costs and task quality are expressed in CDS2-CM.

Table 9.25 Class Design Solution 2: Costs Matrix

9.2.6.2 Comparison of Actual with Desired Performance

Task Quality

All instances where the pre-purchase requirements are satisfied should result in the product goal being achieved. The actual performance is a 100% task completion rate. Thus, Class Design Solution 2 Pa = Pd. As such, it can be considered a valid design solution.

IWS costs

User costs are acceptable, and lower than the class actual costs derived during specification of Class Design Problem 2. A comparison of the costs differences between Class Design Problem 2 and Class Design Solution 2 are shown in the comparison costs matrix shown in Table 9.26.

9.2.7 Class Design Problem/Solution Performance Comparison

Negative values indicate a reduction in costs between the Class Design Problem and Class Design Solution. Where costs increased between Class Design Problem and Class design Solution, they are shown in red. Task completion rates show the increase in task completion percentages, rather than reductions in task failures, in order to maintain a consistency with the labelling of the Costs Matrices.

Table 9.26 Comparison of Class Design Problem 2 / Class Design Solution 2 Costs Matrices

The design solution is implementable using existing technologies, and so can be considered a valid design solution.

9.2.7.1 Evaluation of User Workload Measurements

The user ratings of workload and comparative workload support the conclusion that less workload was required to complete the tasks with the Specific Design Solution systems. The latter, and therefore by extension the Class Design Solution, are therefore considered to be acceptable. They fulfil the requirement in the Product Goals for the Class Design Solution and Specific Design Solutions that the systems should result in lower user costs during task completion.

The Class Design Solution is thus considered acceptable and retained.

Review

The chapter reports Cycle 2 development for the domain of business-to-consumer electronic commerce. The chapter comprises – Cycle 2 development and class design problem/class design solution specification.

9.3 Research Practice Assignment

9.3.1 General

– Read 9.1, concerning Cycle 2 development. 

Check the development informally for completeness and coherence, as required by the case study of business-to-consumer electronic commerce.

The aim of the work assignment is for you to become sufficiently familiar with Cycle 2 development to apply it subsequently and as appropriate to a different domain of application, as in Research Design Scenarios 9.1-2.

Hints and Tips

Difficult to get started?

– Re-read the assignment task carefully.

Make written notes and in particular list the sections, while re-reading 9.1.

Think about how the sections might be applied to describe the Cycle 2 development of a novel domain of application.

Re-attempt the assignment.

Test

List from memory as many of the sections as you can.

– Read 9.2, concerning Cycle 2 class design problem/class design solution specification. 

Check the specification informally for completeness and coherence, as required by the case study of business-to-consumer electronic commerce.

The aim of the work assignment is for you to become sufficiently familiar with Cycle 2 class design problem/class design solution specification to apply it subsequently and as appropriate to a different domain of application, as in Research Design Scenarios 9.1-2.

Hints and Tips

Difficult to get started?

– Re-read the assignment task carefully.

Make written notes and in particular list the sections, while re-reading 9.1.

Think about how the sections might be applied to describe Cycle 2 class design problem/class design solution specification of a novel domain of application.

Re-attempt the assignment.

Test

List from memory as many of the sections as you can.

9.3.1 Research Design Scenarios

 9.1 Applying Cycle 2 Development to an Additional Domain of Application

– Select the same additional domain of application, as used in Research Design Scenarios 7.1-4 and 8.1-2. The domain should be other than that of business-to-consumer electronic commerce.

Apply Cycle 2 development for business-to-consumer electronic commerce (see Section 9.1) to the novel domain of application. The description can only be of the most general kind – that is at the level of the section. However, even qualification at this high level can orient the researcher towards application of Cycle 2 development to novel domains of application. The latter are as might be required subsequently by their own work. The research design scenario is intended to help bridge this gap.

9.2 Applying Cycle 2 Class Design Problem/Class Design Solution Specification to an Additional Domain of Application

– Select the same additional domain of application, as used in Research Design Scenarios 7.1-4 and 8.1-2. The domain should be other than that of business-to-consumer electronic commerce.

Apply Cycle 2 class design problem/class design solution specification for business-to-consumer electronic commerce (see Section 9.2) to the novel domain of application. The description can only be of the most general kind – that is at the level of the section. However, even qualification at this high level can orient the researcher towards application of the Cycle 2 class design problem/class design solution specification to novel domains of application. The latter are as might be required subsequently by their own work. The research design scenario is intended to help bridge this gap.

The Preface makes clear the book’s aims. It is now time to consider how well or not they have been met.

First, the scope and content of HCI as a discipline, HCI as engineering and its associated design problem have been specified by review and operationalised by case study.

Second, following a critique of HCI design knowledge, the challenge of a better guarantee of HCI design knowledge, including that of HCI as engineering, to support HCI design practice, has been identified, documented and addressed.

Third, HCI-EDPs have been conducted in two case studies, as one way of meeting the challenge of the better guarantee required of HCI design knowledge to support more effective HCI design practice.

Fourth, HCI-EDP instance-first and class-first approaches to the acquisition of HCI-EDPs have been developed and implemented in two case studies of different domains of application.

Fifth, early (that is, incomplete) and initial (that is, unvalidated) HCI-EDPs have been acquired. Both the instance-first and class-first approaches, then, need further development. Some progress, however, has been demonstrated and it affords carry forward by future HCI-EDP research. The need for future such research, however, is extensive and is in no way underestimated here.

 Sixth, further research is also required, concerning alternatives to the HCI-EDPs, proposed, to improve the reliability of HCI design knowledge.

Seventh, additional research of this range and magnitude will require researchers to build on each other’s work. Such building needs to create a better consensus, concerning HCI discipline progress as the acquisition and validation of HCI design knowledge to support HCI design practice effectively.

The book’s aims, then, are considered to be met, at least in part. HCI-EDPs indeed have been acquired. However, they are modest in number and mostly by example. Further, they remain incomplete and unvalidated. It is very much a ‘towards’ book, as recognised in its title. At best, a start has been made and much ground has been cleared. Some progress has been made and affords carry forward by future research. For future researchers, however, it will be more ‘attempting to follow in the footsteps’, rather than ‘standing on the shoulders’. Good luck to those researchers willing to have a go at taking up the challenge!

Alterman, R. (1988).  Adaptive Planning.  Cognitive Science 12, 393-421.

Atwood, M., Gray, W. and John, B. (1996). Project Ernestine: analytic and empirical methods applied to a real world CHI Problem. In Rudisill, M., Lewis, C., Polson, P. and McKay, T. (Eds). In Human Computer Interface Design: Success Stories, Emerging Methods and Real World Context,

Barnard, P. (1991). Bridging between Basic Theories and the Artifacts of Human-Computer Interaction in Designing Interaction, Carroll, J. (Ed). UK: Cambridge University Press.

Bayle, E. et al. (1997).  Putting it all together: towards a pattern language for interaction design.  CHI’97 Workshop. 

 Bevan, N. (2001). International standards for HCI and usability. International Journal of Human-Computer Studies, 55(4), 533-552.

Boehm, B. and Lane, J. (2006). 21^st Century Processes for Acquiring 21^st Century Systems of Systems. Cross-talk: the Journal of Defense Software Engineering 19(5), 4-9.

Card, S., Moran, T. and Newell, A. (1983). The Psychology of Human-Computer Interaction. Hillsdale, NJ: LEA.

Carroll, J. (2003). Introduction: Toward a Multidisciplinary Science of Human-Computer Interaction. In Carroll, J. (Ed) HCI Models, Theories and Frameworks. San Francisco, CA: Morgan Kaufmann.

Carroll, J. (2010). Conceptualizing a Possible Discipline of Human-Computer Interaction. Interacting with Computers, 22 (1): 3-12.

Colbert, M. (1994).  Carry Forward in the Development of Military Planning Systems.  Unpublished PhD thesis, University of London.

Cummaford, S. (2000). Validating Effective Design Knowledge for Re-use: HCI Engineering Design Principles. In CHI ’00 Extended Abstracts on Human Factors in Computing Systems.  New York, NY: ACM Press.

Cummaford, S. (2007). HCI Engineering Design Principles: Acquisition of Class-level Knowledge. Unpublished PhD Thesis, University of London.

Cummaford, S. and Long, J. (1998). Towards a Conception of HCI Engineering Design Principles. In Proceedings of Ninth European Conference on Cognitive Ergonomics (ECCE9), Limerick, Ireland.

Cummaford, S. and Long, J. (1999) Costs Matrix: Systematic Comparisons of Competing Design Solutions. In Proc. INTERACT 99, Volume II, Edinburgh UK, 30 Aug-3 Sept 1999.

Denley, I. and Long, J. (2001). Multi-disciplinary practice in requirements engineering: problems and criteria for support. In Blandford, A., Vanderdonkt, J. and Gray, P. (Eds) People and Computers XV – Interaction without Frontiers. Joint proceedings of HCI 2001 and IHM 2001. London: Springer Verlag.

Dowell, J. (1993).  Cognitive Engineering and the Rationalisation of the Flight Strip.  Unpublished PhD Thesis, University College, London.

Dowell, J. (1998). Formulating the Cognitive Design Problem of Air Traffic Management. International Journal of Human-Computer Studies, 49 (5): 743-766.

Dowell J. and Long J. (1989). Towards a Conception for an Engineering Discipline of Human Factors. Ergonomics, 32 (11): 1513-1535.

Friend, J. and Jessop, W.  (1969).  Local Government and Strategic Choice: an Operational Research Approach to the Processes of Public Planning.  UK: Tavistock Publications.

Glaser, B. and Strauss, A. (1967). Discovery of Grounded Theory. London: Aldine.

Hallam-Baker, P. (1996) User Interface Requirements for Sale of Goods. World Wide Web Consortium Technical Paper.

Hartson, R. and Pyla,P. (2018). The UX Book: Agile UX Design for a Quality User Experience. US: Morgan Kaufman.

Hayes-Roth, B., Hayes-Roth, F., Rosenschein, S. and Cammarata, S. (1988).  Modeling Planning as an Incremental, Opportunistic Process.  In: Blackboard Systems, (Eds) Engelmore R. and Morgan, A. Addison-Wesley, 231-583.

Hill, B. (2010). Diagnosing co-ordination problems in the emergency management response to disasters. Interacting with Computers, 22(1): 43-55.

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, (9), S81-S114.

John, B. and Gray, W. (1995). CPM-GOMS: an Analysis Method for Tasks with Parallel Activities. In Conference Companion on Human Factors in Computing Systems CHI’95, ACM.

Kalakota,R and Whinston, A. (1996). Frontiers of Electronic Commerce. US: Addison Wesley Longman Publishing Co., Inc.

Kim, G. (2020). Human-Computer Interaction – Fundamentals and Practice. UK: CRC Press, Taylor and Francis.

Kirsh, D. (2001). The Context of Work. HCI 6(2): 306–322.

Lim K. and Long, J. (1994). The MUSE Method for Usability Engineering. Cambridge, UK: Cambridge University Press.

Linney, J. (1991).  Review of Reactive Planning Literature.  QMW Dept. of Computer Science Technical Report No. 560.

Long, J. (2010). Some Celebratory Reflections on a Celebratory HCI Festschrift, Interacting with Computers, 22 (1): 68-71.

Long, J. (2021). Approaches and Frameworks for HCI Research. Cambridge: Cambridge University Press.

Long, J. and Brostoff, S. (2002). Validating design knowledge in the home: a successful case-study of dementia care. In Reed, D., Baxter, G. and Blythe, M. (Eds). EACE ’12. France: European Association of Cognitive Ergonomics.

Long, J. and Dowell, J. (1989). Conceptions of the Discipline of HCI: Craft, Applied Science and Engineering. In Sutcliffe, A. and Macaulay, L. (Eds), People and Computers V. Cambridge, UK: Cambridge University Press.

Long, J. and Hill, B. (2005). Validating Diagnostic Design Knowledge for Air Traffic Management: a Case-study. In Marmaras, N., Kontogiannis, T. and Nathanael, D. (Eds) EACE ’05. Greece: European Association of Cognitive Ergonomics.

Long, J. and Monk, A. (2002). Applying an engineering framework to telemedical research: a successful case-study. In Khalid, H. and Helander, M. (Eds) Proceedings of 7th International Conference on Working with Computers. Kuala Lumpur, Malaysia.

Long, J., Cummaford, S. and Stork, A. (2022, in press). Towards Engineering Design Principles for HCI. Switzerland: Springer Nature.

Long, J. and Timmer, P. (2001). Design Problems for Cognitive Ergonomics Research: What We Can L from ATM-like Micro-worlds. Le Travail Humain. 64(3), 197-222.

Nielsen, J. (1993) Usability Engineering. San Francisco: Morgan Kaufman.

Norman, D. (1983) Design Principles for Human-Computer Interfaces. In Smith, R., Pew, R. and Janda, A. (Eds) Proceedings of CHI 83, Human Factors in Computing Systems Conference. Boston, Massachusetts: United States ACM.

Norman, D. (1989).  The Psychology of Everyday Things.  NY: Basic Books.

Norman,D. (1993).  Things That Make Us Smart. NY: Diversion Books

Norman, D. (2010). The Transmedia Design Challenge: Technology That Is Pleasurable and Satisfying. Interactions, 17, (1): 12-15.

Norman, D. (2013). The Design of Everyday Things (Revised Ed.). NY: Basic Books.

Pew, R. and Mavor, A. (2007). Human-System Integration in the System Development Process – a New Look. US: The National Academies Press.

Rauterberg, M. (2006). HCI as an Engineering Discipline: To Be or Not To Be!? African Journal of Information and Communication Technology, 2 (4): 163-184.

 Rauterberg M. and Krueger H. (2000). (Eds.). EU Directive 90/270: State-of-the-art in United Kingdom. IPO Report No. 1236. Technical University Eindhoven.

Ritter, F., Baxter, G. and Churchill, E. (2014). User-Centred Systems Design – a Brief History in Foundations for Designing User-Centered Systems, pp33-54. Switzerland: Springer Nature.

Seffah, A. (2015). Patterns of HCI Design and HCI Design of Patterns. Switzerland: Springer Nature.

Shneiderman, B. (1983). Direct Manipulation: a Step beyond Programming Languages. IEEE Computer, 16(8) 57.

Shneiderman, B. (1998). Designing the User Interface: Strategies for Effective Human- Computer Interaction, 3rd Edition. Reading, MA: Addison-Wesley.

Shneiderman, B. (2010). Designing the User Interface: Strategies for Effective Human- Computer Interaction, 5th Edition. Reading, MA: Addison-Wesley.

Smith, M. and Mosier, J. (1986). Guidelines for designing interface software. Mitre Corporation Report MTR9240 Mitre Corporation.

Smith, W., Hill, B., Long, J. and Whitefield, A. (1997). A Design-oriented Framework for Modelling the Planning and Control of Multiple Task Work in Secretarial Office Administration.  Behaviour & Information Technology. 16 (3), 289-309.

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

Stork, A. and Long, J.(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.

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

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

Teo, L. and John, B. (2008). CogTool-Explorer: Towards a Tool for Predicting User Interaction. In Proc CHI EA’08, ACM, pp. 2793–2798.

Timmer, P. (1999).  Expression of Operator Planning Horizons: A Cognitive Engineering Approach.  Unpublished PhD Thesis, University of London.

Timmer, P. and Long, J. (2002). Expressing the Effectiveness of Planning Horizons. Le Travail Humain, 65 (2): 103-126.

Wickens, D. (1984). Engineering Psychology and Human Performance. Columbus: Merrill.

Wickens, D. (1993) Cognitive Factors in Display Design 83 (4): 179-201.

Wickens, C., Lee, J. and Becker, G. (2004).  An Introduction to Human Factors Engineering, 2nd edition, Pearson 2004, Chapter 8.

Wright, P., Fields, R. and Harrison, M. (2000). Analysing Human-Computer Interaction as Distributed Cognition: the Resources Model. Human Computer Interaction, 51 (1): 1–41.

Zagalo, N. (2020). Engagement Design: Designing for Interaction Motivations. Switzerland: Springer Nature.

Index

AB Testing 11.4

AI 3.2.2

Architecture

     Computer 2.3.4

     Human 2.3.3

Air Traffic Management 1.4.1.1, 3.2.1.2

     Planning Horizon 1.4.1.1

Apple 1.2.11

Applied Psychology Frt

Atomic Design Methods 11.4

Best Practice 3.3

     Cycle 1 Development 3.3

     Cycle 2 Development 4.1, 4.1.3

Best Selling Lists 5.5

Betty Brown Teapot 8.1.4.1

Black Tea 8.1.4.q

Boolean Values 3.1.1

Business-to-Consumer Electronic Commerce 9.2, 9.2.1, 9.2.2, 9.2.3, 9.2.4, 9.2.5

     Case Study

Case Studies

Central Heating 1.2.2.1

Challenge 3.3, 5.3, 6.5, 7.3

Civil Engineering 2.1

Class-based Approach Frt, 7.3

     Class-first Strategy 9.2.1

     Class Design Problem 7.4

     Class Design Solution 9.2.1

Cognitive Engineering 1.2

Cognitive Ergonomics Frt

Cognitive Psychology Frt

Computer

     Model 8.2.5.2

     Representation States 10.2.2

     Representation Structure States 10.2.2

Computer Architecture 9.1.1

Computer Costs

     Abstract

          Behavioural

          Structural

     Physical

          Behavioural

          Structural

Computing Technology 1.2.2.2

Conception 3.2.

     Actual Costs 2.1.3.6

     Actual Performance 2.1.3.2

     Actual Quality 2.1.3.4

     Changes 6.1.1

     Cognitive Structures 2.3.2

     Desired Costs 2.1.3.5

     Desired Performance 2.1.3.1

     Desired Quality 2.1.3.3

     HCI General Design Problem 2.1.3

     HCI General Design Solution 2.1.3

     HCI Discipline 1.1

     HCI Design problems 7.1

     Human-Computer Systems 2.3

     Planning and Control 3.2  

     Specific Design Problems 2.1.4

     Specific Design Solutions 2.1.4

     Substantive Engineering Principles 2.1, 2.1.5

Design Principles.1.4

HCI Engineering 1.2

     HCI Engineering Design 1.3

     HCI Engineering Design Principles 7.1

     Generality 5.1.1

          General Guidelines

          MUSE Guidelines

          MUSE Tasks

          Inspirational

     HCI General Design Problem 10.2.1

     HCI General Design Solution 10.2.1

     HCI Specific Design Problem 10.2.1

     HCI Specific Design Solution

     Planning and Control 3.2

          With Design Guidance

          Without Design Guidance

     Substantive Engineering Principles 2.1

…..Computer Architecture 2.3.4

Control

     Domain

     Worksystem

Costs Matrix

Craft Artefacts 5.1/5.2/5.3, 10.1.1

Critique 1.5

Declarative Knowledge 3.2.1

Design 2.1

     Situation

     Funnel Testing 11.4

     Scenario-based 1.4.1.1

Design Guidance 3.2.1, 3.2.2

Design Knowledge 4.1, 5.1, 6.1, 7.1, 10.1

Design Patterns, 1.4.2.2

Design Practice Experience 5.1/5.2/5.3, 10.1.1

Design Principle 1.4

Design Problem 1.2

Design Rationale 1.4.1.1

Design Solution 1.2

Direct Manipulation Theory 1.4.1.1

Domestic Energy Planning and Control 9.1, 9.1.2, 9.1.3, 9.1.4, 9.1.5

     Case Study

Discipline 1.

Domain 2.1.3.1

     Boundary Criteria 2.1.3.1

     Diagram Key 3.1.1

     Model 10.3.1, 8.2.3.1

          Class Model 8.2.3.1

State Stream 3.1.1

Ease of Use 1.2.2.1

Ecological Theory 1.4.1.1

E-Commerce 4.2.2

Effective Support 10.1

Electronic Engineering 2.1

EMCRS 1.4.1.1

Engineering Principles 8.1

Ergonomics

E-Shops 4.2

External Cognition Theory 1.4.1.1

Face Recognition 1.2

Feedfinder 5.2

Firefox

Formality 1.2

Formal Knowledge 1.2

Framewoek

     Interactive Worksystem Costs 3.1.2

     Task Quality 3.1.1

Gaming 1.2

     Guarantees 3.2.1

     Procedural 3.2.1

GOMS – 6.1

Goods 1.2.2.2

     Physical

     Informational

Google Chrome

Graphical User Interface – GUI 1.2.11

Grounded Theory 1.4.1.1

Guidelines

     Business-to-Consumer Electronic Commerce 4.2.2

     Domestic Energy Planning and Control 4.2.1

     General Guidelines

     MUSE Guidelines

Herbs of Grace 8.1.2

HCI Design

     Critique 1.5

     Challenge 1.5

     Scenario-base 1.4.1.1

     Way Forward 1.5

HCI Design Practice

     Scenario-based Design 6.2, 6.5

HCI Design Knowledge 4.2, 10.1.1, 10.1.2, 10.1.3

     Critique 1.5

     Challenge 1.5

     Declarative 3.2.1

     Design Rationale 5.2, 6.4

     Procedural

HCI Engineering 1.2

     Design 1.3

     Principles1.4

HCI Design Patterns 1.4.2.2

HCI Design Practice 1.4.1

     HCI Engineering Design Practice 2.1.2

     Specify and Implement 1.4.1

     Specify then Implement 1.4.1

HCI Design Principles 1.4

     Prescriptive Design Knowledge 10.3

HCI Discipline 1.2

HCI Engineering Design Principles 8.4, 8.5, 8.6

     Achievable Performance 10.1.5

     Acquisition 10.2

     Business-to-Consumer Electronic Commerce

     Class Design Problem 8.2.3

     Classification Space 8.4.1

     Components 10.1.2

     Development Cycle 1 9.1.2

     Development Cycle 2 9.1.3

      Domestic Energy Planning and Control

     Inspirational

     MUSE Guidelines

     MUSE Tasks

     Operationalisation

     Product Goal

     Scope 10.1.3, 10.2

     Specification 10.1.4

     Specification Method 10.1.1

     Status 6.1.2

     Way Forward 8.6

HCI Evaluation

     Domestic Energy Planning and Control 5.2

     Business-to-Consumer Electronic Commerce

HCI General Problem 1.2.1/1.2.1.2, 2.1

HCI Heuristics 1.4.1.2

HCI Knowledge 3.2

HCI Models and Methods 1.4.1.1

HCI Particular Scope 1.2.2/1.2.2.2

     Humans 1.2.2.2

     Computers 1.2.2.2

     Interactions 1.2.2.2

     Performance 1.2.2.2

HCI Principles 1.4.1.2

HCI Research 1.2.3/1.2.3.2

     Future

Progress 12.2.3

     Business-to-Consumer Electronic Commerce Progress

     Domestic Energy Planning and Control Progress

     General

HCI Rules 1.4.1.2

HCI Validation 1.4.1.1

Heuristics 7.1, 7.2, 7.2.3, 10.1.3

Hierarchy of Complexity 3.1.1

Human Architecture 9.1.1, 2.3.3

Human-Centred Informatics

Human-Computer Interaction  (HCI) 1.1

Human-Computer Systems 2.3

Human Factors 1.2

Implementation 2.2.3, 2.

Innovation 1.2

Inspirational Principles

Interaction Design 1.2

Interdisciplinary Overlapping Fields 6.2

Internet Explorer

Jackson System Development 2.2.6

Jamster 9.1.2

Knowledge 3.1, 3.5,

     Declarative (Substantive)

     Decomposition (Kde)

     Procedural (Methodological

     Recomposition (Kre)

     Solution (Kso)

Manchester United

     Text Alerts Service 9.1.2

Mercantile Models 9.2.1

Methods 6.3

Minimal Viable Product (MVP) 11.4

Model Human Processor 1.4.1.1

Models 6.2

     Resource 1.4.1.1

Models and Methods 1.4.1.1

Multi-media 1.2.2.1

…..Challenge 6.5

…..Critique 6.5

Multiple Task Work 6.2

MUSE – Method for Usability Engineering 1.4.1.1, 5.2, 6.3, 2.2.1, 2.2.6, 3.3.3.1, 6.2

MUSE/R – MUSE for Research 6.2

On-line Banking 1.2

On-line Dating 1.2

On-line Shopping 1.2

Operationalisation 3.1

     Cycle 1 3.1,

          Selection 2.2.7.1

     Cycle 2 4.1, 4.2.

          Selection 2.2.7.2

     Initial Engineering Design Principles

     Specific Design Problems

          Specific Desired Quality

          Specific Desired Costs

     Specific Design Solutions

          Specific Actual Costs

          Specific Actual Performance

          Specific Actual Quality

PASHT 3.2.1.2

Performance 1.2.2.2

     Achievable

     Actual 2.1.3.4

          Specific

     Desired 2.1.3.1

     Potential Guarantee 2.2.4

Planning and Control 1.2

…..Composite

     Generalised

     Desired States and Structures

     Interleaved 3.2.1.2

Plans

     In Domain 3.2.1.1, 3.2.2.2

     In Interactive Worksystem 3.2.3.3

     In Separate Worksystems

     Worksystem

PowerPoint 1.2.2.2

Principles 7.1, 7.2, 7.2.1, 8.1, 10.1.3

Procedural Knowledge 3.2.1

Prototypes 1.2

Rules 7.1, 7.2, 7.2.2, 10.1.3

Safari

Secretarial Office Administration 1.4.1.1

Simulation 1.2

Smart Phones 1.2.2.1

Snow Valley 4.2.1

Software Engineering Frt

Specification 2.2.2

Speed and Errors 1.2.2.2

SSADM 2.2.6

Standards

Stash Tea 8.1.2

Storyboard Scenarios 1.2

Strategy 2.2, 6.1, 7.2, 11.2

      Assessment 6.1.3

     Bottom Up

     Changes

     Developing Engineering Design Principles 2.2, 2.2.1

          Detailed Strategy 5.1, 6.1

     Discussion

…..Middle-Out

     Top Down

Storyboard Scenarios 1.2

Streams

     Behaviour

     Structure

Structures

     Composite

Supercraft

System Versions 1.

Task Quality 9.1.2

     Actual Quality

          Specific

     Desired Quality

Testing Procedure

     Setup

     Participants

     Tasks

Theory 10.1.1

     Of Operator Planning Horizons (TOPH) 1.4.1.1, 1.5

Trial and Error 1.2.2.2

Usability 1.2.2.1

User 2.1.3.5

     Affective

     Cognitive

     Conative

     Model 8.2.3.2

          Class Model 8.2.3.2

     Representation States

     Representation Structure States

User Costs 9.1.2

     Actual

          Specific 3.4.1.3

     Calculation

          Desired

          Human

          Abstract  (Mental) Behavioural

               Structural

          Physical Behavioural

               Structural

Costs Matrix 8.1.4.1, 8.1.9

User Experience 1.2.2.1

User Requirements 2.2.1, 3.3.1, 4.1.1

     Selection Criteria

     Identified 2.2.7.2.1

UX Design Frt

Widgets

Validation 1.5

Wire-Frame Models 1.Worksystem

Worksystem 2.1.3.1

     Boundary Criteria 2.1.3.1

     Class 8.2.5.2

World Health Organisation – WHO 5.2

World of Work

     Desired Performance 2.1.3.1

     Desired Quality

     Attributes

          Abstract

          Physical

          Related

          Task Goals

          Unrelated

     Objects

     Product Goals

          Achieved

Task Goals

          Achieved

     States

     Structures  8.2.5.2

Xerox 1.2.11

Yourdon 2.2.6

BLOG 1

I have always argued for the strongest possible relations between HCI research and HCI practice, whether as Engineering or alternative approaches. For example: ‘The HCI discipline can be summarised as: the use of HCI knowledge (acquired by research) to support practices (of design and evaluation) seeking solutions to the general problem of HCI (humans interacting with computers to do something, as desired/ to perform tasks effectively, as desired) [1]. My own research (along with many others) has acquired such knowledge in the form of design models, methods and principles to support practice.

However, I have always been acutely aware of the gap between knowledge acquired by HCI research and its application by designers. Bellotti reported empirical support for such a gap in her study of commercial system interface design projects [2]. She concluded that: ‘The study suggests that HCI design and evaluation techniques, although potentially valuable to commercial design, are not applied in practice’. A comparable study of London HCI Centre designers (the commercial arm of the Ergonomics Unit/UCL) reached the same conclusion. Later, in 1997, I cited Bellotti’s paper, concluding that: ‘In terms of the capability maturity model [3], HCI fails to support design practices, which are either ‘defined’, ‘repeatable’, ‘managed’ or ‘optimised’.

My view has remained unchanged, in spite of the intervening years. In my 2010 Festschrift, I wrote: ‘….I would like to celebrate the world of HCI. Obviously, students, practitioners and researchers, who identify themselves with HCI and who together make up the HCI community. But also IT professionals, outside the community, who do not identify with HCI; but who actually design so many of the interfaces in use to-day. Most IT interfaces continue to be designed and implemented by such professionals. We forget them at our (professional) peril.’ [4]

Further, I expressed the hope that: ‘HCI research improves the effectiveness of the design knowledge, which it acquires to support HCI design practices (a hope shared by festschrift authors – knowledge, which is ‘more assured’ [5], ‘more reliable’ [6] and ‘offering a better guarantee’ [7]. Anyone who doubts this need should seriously consider:

1. How much interface design is performed by IT professionals, outside the HCI community;

2. How little HCI actual design, as opposed to related studies or evaluation, is carried out by individual HCI practitioners (as consultants) or even by those working as teams in large organisations; and

3. How much design is performed with little or no reference to HCI design knowledge (of any or no kind), other than perhaps evaluation. But how is this much-needed improvement in HCI design knowledge to be achieved? In my view, it can only come about, if HCI research and practice diagnose more design problems and prescribe more design solutions and in so doing evaluate the effectiveness of HCI design knowledge (of whatever kind, engineering and other).’

However, lots of HCI water has passed under the bridge in the last 25 years or so. Also, I am a researcher and not a practising designer. A timely reconsideration of the relations between HCI research and practice – past, present and future, seemed a good idea for the website to address. By sheer good fortune, I was in contact with Victoria Bellotti at this time and she agreed to an e-mail exchange on the topic. Victoria is both a very successful researcher and designer and, of course, set the ball rolling in 1988 with her paper cited earlier.

References

[1] Long and Dowell, 1989 

[2] Bellotti, 1988 

[3] Paulk et al., 1993 

[4] Long, 2010 

[5] Dix, 2010 

[6] Carroll, 2010 

[7] Hill, 2010