Chapter 5 Interaction Design and HCI in the

Chapter 5 Interaction Design and HCI in the Software Process 1

Outline • Interaction Design • Process of interaction design • HCI in software Process 2

Interaction design is about developing high quality interactive systems and products that support, enhance, and extend the way people work, communicate, and interact 3

What is Design? Achieving goals within constraints: • Goals : the purpose of the design we are intending to produce • who is it for, why do they want it • Constraints: the limitations on the design process by external factors • Like materials, platforms, cost, time, health and safety • Trade-offs: choosing which goals or constraints can be relaxed so that others can be met. 4

golden rule of design understand your materials 5

for Human–Computer Interaction understand your materials • understand computers • limitations, capacities, tools, platforms • understand people • psychological, social aspects • human error • and their interaction … 6

To err is human • accident reports. . • aircrash, industrial accident, hospital mistake • enquiry … blames … ‘human error’ • but … • concrete lintel breaks because too much weight • blame ‘lintel error’ ? … no – design error we know how concrete behaves under stress • human ‘error’ is normal • we know how users behave under stress • so design for it! • treat the user at least as well as physical materials! 7

Central message … the user • The core of interaction design: put the user first, keep the user in the center and remember the user at the end. 8

Interaction design process what is wanted scenarios task analysis what is there vs. what is wanted guidelines principles analysis dialogue notations evaluation heuristics precise specification design prototype implement and deploy architectures documentation help 9

Steps … • requirements • what is there and what is wanted … • analysis • ordering and understanding • design • what to do and how to decide • iteration and prototyping • getting it right … and finding what is really needed! • implementation and deployment • making it and getting it out there 10

Interaction Design Processes 1. 2. 3. 4. Identifying needs and establishing requirements. Developing alternative designs that meet those requirements. Building interactive versions of the designs/prototyping/ Evaluating designs 11

… but how can I do it all ! ! • limited time design trade-off • usability? • finding problems and fixing them? • deciding what to fix? • Which usability problem is worth fixing? ? • a perfect system is badly designed • too good too much effort in design 12

Interaction Design Cont. • Three key characteristics of the interaction design process • User focus • Specific usability criteria • Iteration 13

User Focus It is the way of identifying your users • Who are they? • Probably not like you! • Talk to them • Watch them • Where they are going to use the product • Kind of activities people are doing while interacting with the product. 14

Activity 1 • How does making of a phone call differs when using • A public phone box • A cell phone? • How have these devices been designed to take in to account • The kind of the users • Type of activities • Context of use 15

User focus Cont. • Gather as much information as possible about the future users of the system. • Stakeholders: people affected directly or indirectly by a system. • Participatory design: bringing a potential user fully into the design process • Persona: rich picture of an imaginary person who represents your core user group. • Cultural probes provide a way of gathering information about people and their activities. • Use your imagination. 16

persona • description of an ‘example’ user • not necessarily a real person • use as surrogate user • what would Betty think • details matter • makes her ‘real’ 17

example persona • Betty is 37 years old, She has been Warehouse Manager for five years and worked for Simpkins Brothers Engineering for twelve years. She didn’t go to university, but has studied in her evenings for a business diploma. She has two children aged 15 and 7 and does not like to work late. She did part of an introductory in-house computer course some years ago, but it was interrupted when she was promoted and could no longer afford to take the time. Her vision is perfect, but her right- 18

cultural probes • direct observation • sometimes hard • in the home • psychiatric patients, … • probe packs • items to prompt responses • e. g. glass to listen at wall, camera, postcard • given to people to open in their own environment they record what is meaningful to them • used to … • inform interviews, prompt ideas, enculture designers 19

20

Scenarios • are stories for design Explore the depth • Explore interaction-what happens when • Explore cognition-what are the users thinking • Explore architecture-what is happening inside • scenarios are linear – they represent a single path amongst all the potential interactions • easy to understand • But no alternatives 21

Scenarios Cont. Use scenarios to: • Communicate with others-designers, clients, users • Validate other models-‘play’ it against other models • Express dynamics • Screenshots – appearance • pictures – behaviour 22

HCI in Software Process 32

HCI in the software process • Software engineering and the design process for interactive systems • Usability engineering • Iterative design and prototyping • Design rationale 24

the software lifecycle • Software engineering is the discipline for understanding the software design process, or life cycle • Designing for usability occurs at all stages of the life cycle, not as a single isolated activity 25

The waterfall model Requirements specification Architectural design Detailed design Coding and unit testing Integration and testing Operation and maintenance 26

Activities in the life cycle Requirements specification designer and customer try capture what the system is expected to provide can be expressed in natural language or more precise languages, such as a task analysis would provide Architectural design high-level description of how the system will provide the services required factor system into major components of the system and how they are interrelated needs to satisfy both functional and nonfunctional requirements Detailed design refinement of architectural components and interrelations to identify modules to be implemented separately the refinement is governed by the nonfunctional requirements 27

Verification and validation Real-world requirements and constraints The formality gap Verification designing the product right Validation designing the right product The formality gap validation will always rely to some extent on subjective means of proof Management and contractual issues design in commercial and legal contexts 28

The life cycle for interactive systems cannot assume a linear sequence of activities as in the waterfall model Requirements specification Architectural design Detailed design Coding and unit testing lots of feedback! Integration and testing 29 Operation and maintenance

Usability engineering The ultimate test of usability based on measurement of user experience Usability engineering demands that specific usability measures be made explicit as requirements Usability specification • usability attribute/principle • measuring concept • measuring method • now level/ worst case/ planned level/ best case Problems • usability specification requires level of detail that may not be • possible early in design satisfying a usability specification • does not necessarily satisfy usability 30

part of a usability specification for a VCR Attribute: Backward recoverability Measuring concept: Measuring method: Now level: Worst case: Planned level: Best case: Undo an erroneous programming sequence Number of explicit user actions to undo current program No current product allows such an undo As many actions as it takes to program-in mistake A maximum of two explicit user actions One explicit cancel action 31

ISO usability standard 9241 adopts traditional usability categories: • effectiveness • can you achieve what you want to? • efficiency • can you do it without wasting effort? • satisfaction • do you enjoy the process? 32

some metrics from ISO 9241 Usability objective Effectiveness measures Efficiency measures Suitability for the task Percentage of goals achieved Rating scale Time to complete a task for satisfaction Appropriate for Number of power trained users features used Learnability Percentage of functions learned Error tolerance Percentage of errors corrected successfully Satisfaction measures Relative efficiency Rating scale for compared with satisfaction with an expert user power features Time to learn criterion Rating scale for ease of learning Time spent on Rating scale for correcting errors error handling 33

Iterative design and prototyping • Iterative design overcomes inherent problems of incomplete requirements • Prototypes • simulate or animate some features of intended system • different types of prototypes • throw-away • incremental • evolutionary • Management issues • • time planning non-functional features contracts 34

Throw-away Prototyping The prototype is built and tested. The design knowledge gained from this exercise is used to build the final product, but the actual prototype is discarded. 35

Incremental Prototyping • The final product is built as separate components, one at a time. • There is one overall design for the final system, but it is partitioned into independent and smaller components. The final product is then released as a series of products, each subsequent release including one more component. 36

Evolutionary Prototyping • The prototype is not discarded and serves as the basis for the next iteration of design. In this case, the actual system is seen as evolving from a very limited initial version to its final release 37

Techniques for prototyping Storyboards need not be computer-based can be animated Limited functionality simulations some part of system functionality provided by designers tools like Hyper. Card are common for these Wizard of Oz technique Warning about iterative design inertia – early bad decisions stay bad diagnosing real usability problems in prototypes…. …. and not just the symptoms 38

Design rationale is information that explains why a computer system is the way it is. Benefits of design rationale • communication throughout life cycle • reuse of design knowledge across products • enforces design discipline • presents arguments for design trade-offs • organizes potentially large design space • capturing contextual information 39

Design rationale (cont’d) Types of DR: • Process-oriented • preserves order of deliberation and decision-making • Structure-oriented • emphasizes post hoc structuring of considered design alternatives • Two examples: • Issue-based information system (IBIS) • Design space analysis 40

Issue-based information system (IBIS) • basis for much of design rationale research • process-oriented • main elements: issues – hierarchical structure with one ‘root’ issue positions – potential resolutions of an issue arguments – modify the relationship between positions and issues • g. IBIS is a graphical version 41

structure of g. IBIS Position supports Argument responds to Issue responds to Position specializes objects to Argument generalizes Sub-issue questions Sub-issue 42

Design space analysis • structure-oriented • QOC – hierarchical structure: questions (and sub-questions) – represent major issues of a design options – provide alternative solutions to the question criteria – the means to assess the options in order to make a choice • DRL(Decision Representation Language) – similar to QOC with a larger language and more formal semantics 43

the QOC notation Option Question … Criterion Consequent Question … 44

Psychological design rationale • to support task-artefact cycle in which user tasks are affected by the systems they use • aims to make explicit consequences of design for users • designers identify tasks system will support • scenarios are suggested to test task • users are observed on system • psychological claims of system made explicit • negative aspects of design can be used to improve next 45

Summary The software engineering life cycle • distinct activities and the consequences for interactive system design Usability engineering • making usability measurements explicit as requirements Iterative design and prototyping • limited functionality simulations and animations Design rationale • recording design knowledge • process vs. structure 46