From HCI to Interaction Design

ACM SIGGRAPH Computer Graphics, 1987

ACM SIGGRAPH Computer Graphics, 1987

This written report summarizes the discussions an d conclusions of the goals and objectives group at th e ACM/SIGGRAPH Workshop on Software Tools for Use r Interface Development. The report is organized into th e following sections : e Section 1-Overview of group goals and discussion s Section 2-Definition and characteristics of a UIM S ® Section 3-Criteria used to develop a taxonomy of a UIM S Section 4-Tasks and tools fo r user interface developmen t o Section 5-Suggested topics and areas of research 1. Overview of group goals and discussion s The members of the group have been both developer s and end users of user interfaces. This experience provide d two perspectives on the nature of user interface software. Both of these views played a major role in our discussion s and the conclusions presented here. The two primary goals of the group were to enumerate the various tasks or actions involved in the development o f user interfaces and to determine the software tools that coul d provide automated support for these actions. Prior to discussing the activities and software tool s required for user interface development, the group discusse d these topics : e Definition of a UIM S o Characteristics of a UIM S o Criteria to be used in developing a taxonomy of a UIM S The group also defined several areas and topics o f research on user interfaces and UIMS that should b e investigated by the academic and industrial research community. This report documents these discussions an d conclusions .

2004

Preface Part A: Best of the Classics 1.Usability 2. Prototyping and iterative design 3. Data presentation 4. Mental models and interface design Part B: Systematic Interface Design 5. Analysis, visions and domain description 6. Virtual windows design 7. Function design 8. Prototypes and defect correction 9. Reflections on user interface design Part C: Supplementary Design Issues 10. Web-based course rating 11. Designing an e-mail system 12. User documentation and support 13. More on usability testing 14. Heuristic evaluation 15. Systems development 16. Data modelling 17. Exercises 18. References Index

Computer Science and Information Systems, 2015

We identify a suite of activities in the development process of Graphical User Interfaces (GUI) and include them as part of an approach to a generic model for the GUI Development Process (GDP). This work contributes with: (1) the identification of common activities of previous GDPs, (2) the definition of an approach to a generic GDP limited to its phases and activities, and (3) the integration of such a generic GDP with any software-system development life cycle (SDLC), illustrated with the Spiral SDLC. We show this work is useful by a) highlighting the advantages of our proposal over other methodologies for GDP in Human-Computer Interaction (HCI), b) showing one example of the integration of the GDP into a SDLC, and c) showing the usefulness of our approach in a case example.

In the Human-computer interaction (HCI) literature, it has been recommended that user involvement and HCI considerations in the software development life cycle (SDLC) is an important mechanism for a successful system implementation. However, it is still unclear to what extend do the user involvement and HCI consideration have been adopted by software development practitioners. This paper reports the results of a survey on the importance of HCI in SDLC from practitioner perspective. The survey involves thirty two software designers. The objectives of the study are to identify the state of user involvement in SDLC and to identify the HCI elements that have been addressed. Results have found that many of practitioners involve users in SDLC, but majority are only during the requirement analysis phase. The findings also reveal that HCI elements on functionality are well addressed, however, the non-functionality elements such as cultural and affective values have not been emphasized by practitioners. The paper concludes with recommendation to further investigate on user awareness on the importance of user involvement in the software development.

2002

INTERACT 2001-Workshop on Usability throughout the entire software development lifecycle INTERACT 2001-Workshop on Usability throughout the entire software development lifecycle 4 of the evaluation process and be aimed primarily at organisations without usability expertise. The below figure illustrates the evaluation process. Determining test targets Determining test targets Choosing test method Choosing test method Develop test material Develop test material Planning und Organization Planning und Organization Executing the test Executing the test Editing Data Editing Data Evaluating Data Evaluating Data Writing the Study Writing the Study Fig1: The eight phases in the usability evaluation process • A Usability Designer at Work-Göransson B. Göransson describes the usability designer role, which merges ideas from usability engineering as described by, for instance, Nielsen and the interaction design approach suggested by Cooper. The usability designer participates continuously throughout the entire development project. He/she has the responsibility for the user-centred approach and all usability-related activities in the project, including taking an active part in the design process. Göransson particularly wants to address the problems with the "usability-at-the-end" view and the fact that many commercial software development models do not honour the importance of usability. Usability is taken for granted. He also argues that user-centred design, a prerequisite for usability, is about attitudes and process, with an emphasis on attitudes. User-centred design ought to be the standard operating procedure for software development, and the usability designer provides a way of achieving that. INTERACT 2001-Workshop on Usability throughout the entire software development lifecycle 8 Separate Track or Seamless Integration Many projects start without the intended users-they start with the functional requirements and client requirements expressing the business goals rather than the user requirements. The ideal would be to start with a group containing user representatives, usability experts and software engineers, even before the requirements capture phase starts. Requirements can then be captured by means of user research. Fig 3: Development cycle Users and designers need to get to know each other. Users must be involved early and continuously and particularly in the design phase. Some of the participants argued that it is easier to involve users in interface design activities than in use case modelling. Does this mean that the interface should be designed before the use case modelling starts? The matter will be further discussed in the section on tasks and use cases below. Do we need a separate usability process or should it be seamlessly integrated into the software development process? The group did not reach agreement on the matter, but everyone at least agreed that it is a key problem. Why do we need a usability process at all? Processes are rarely used to guide the day-today work and most people only care about their own parts of the process. Processes are, however, useful for reasoning about one's work and describe it to others. They are particularly important for persuading management to introduce usability activities in software development. Having a separate usability process may help in making the software development process more suitable for a usability focus. Patterns Design patterns or usability patterns have raised the hopes amongst software designers and the HCI community of late. With patterns, good design solutions may be re-used, and bad ones hopefully eliminated. Design patterns could be seen as user needs resolved into working solutions, representing best design practices. Patterns can be used to facilitate communication between different groups, but need not be understood by users. One concern is finding a design pattern to fit a particualar design problem-naming design patterns suitably is therefore important. The names of the patterns should help jog the imagination of the designer. There are a number of product-based design patterns and pattern languages. Pattern languages are groups of patterns that capture a philosophy of solutions. The patterns in a language share the same design philosophy and come from the same design rationale. A pattern language can be domain specific or system type specific. Pattern languages were further discussed at the INTERACT 2001 conference by Mahemoff and Johnston, in the paper Usability Pattern Languages: the "Language" Aspect. Design patterns or usability patterns are typically product-oriented-but methods and techniques could be seen as process-oriented patterns. The USEPACKs (Usability Engineering Experience Package) discussed by Metzker in his position paper, Evidence-Based Usability Engineering: Seven Thesis on the Integration, Establishment and Continuous Improvement of Human-Centred Design Methods in Software Development Processes, could be seen as a kind of patterns. A USEPACK is used to capture best practices in applying various HCI methods and techniques. It is a semi-formal notation and describes the HCI activity or method with an increasing level of complexity and detail. The USEPACK describes the activity/method, the development context in which it is suitable and provides a set of artifacts such as checklists and templates. The idea is to provide guidance and inspiration in such a way that USEPACKs can be mapped into the software engineering process also by less experienced usability workers. The project over time Users SW eng Usab exp Requirements Design Evaluations Implementation INTERACT 2001-Workshop on Usability throughout the entire software development lifecycle 9 User-centred Design versus Usability Engineering Are usability engineering and user-centred design the same? Or is it so that engineers equate usability engineering with user-centred design, just because of the engineering suffix? Do they need an engineering suffix in order to accept a user-centred design approach? The computer scientists participating in the workshop said that to many software engineers, user-centred design is just another word for usability engineering. Software engineering is far from being a mature discipline, it certainly needs further research and development as regards user-orientation. User-centred design is a philosophy opposed to the system-driven development philosophy that is the traditional way of seeing and doing things in software development. User-centred, or human-centred design is the way we want to move in software development, but it has not become established practice. Hopefully, it will become the established, traditional way of doing things. However, to dislodge the system-oriented approach takes an enormous amount of effort or a miracle. It may be on its way with new technologies and decentralised software development. It is important though, to use the terminology unequivocally. It is perhaps a bit unfortunate that usability engineering has become the way of thinking about user-centred design in the software engineering community. Usability engineering focuses on requirements and evaluations preserving, perhaps, a technical, engineeringoriented attitude to software development. User-centred design, on the other hand, addresses designing with the users. Seffah presented a slide clarifying the differences between human-centred and technology-driven development, see the illustration below.

Users' dissatisfaction on the software used will impact the efficiency. Moreover, the lack of knowledge of users' involvement in the development of the software will cause issues to the user's later on. In the case of human-computer Interaction (HCI),it has been suggested that a user's participation and HCI concern in the application growth lifecycle (SDLC) as an important procedure for a successful program execution. However, it is still not sure to what extend user participation is important and HCI problem have been settled by system professionals.The result which is mentioned in this paper and the review opinions from the experts' point of view are taken from analysis on the value of HCI in SDLC. The objectives of the analysis are to identify the condition of the users' contribution in SDLC and to identify the HCI elements that have been settled. Results show that many of the experts have engaged the customers in SDLC, but the majority only during the need research stage. The conclusions have also shown that HCI components on performance are well resolved. However, the non-functionality components such as social, environmental issues have not been highlighted by experts. This paper indicates with recommendations to further analyze the users' interest on the value of the users' contribution in the program development.

IEEE Transactions on Software Engineering, 1986

TELEKTRONIKK, 1997

This article looks at the interface design process and reflects upon its practice in projects. Methods and disciplines are discussed based upon recent project experience, and some future directions for interface design are suggested. The article focuses on systems aimed at the consumer market, although the distinction between home users and office users is now becoming less and less distinct. The paper takes a pragmatic and personal view of the design process, rather than an idealised view. This view is of course my own, and does not necessarily reflect the views of the organisations or projects I work for.

IEEE Transactions on Software Engineering, 2000