The Design Process Lecture 9 Date: 2nd March

Overview Life-Cycle Models in HCI 4 basic activities in HCI Requirements Design Develop/Build Evaluation

Lifecycle Models Show how activities are related to each other Lifecycle models are: management tools simplified versions of reality Many lifecycle models exist, for example: from software engineering: waterfall, spiral, JAD/RAD from HCI: Star, usability engineering Life-Cycle Models

A simple interaction design model Identify needs/ establish requirements (Re)Design Evaluate Build an interactive version Final product Exemplifies a user-centered design approach Life-Cycle Models

Traditional ‘waterfall’ lifecycle Requirements analysis Design Code Test Maintenance Life-Cycle Models

A Lifecycle for RAD (Rapid Applications Development) Project set-up JAD workshops Iterative design and build Engineer and test final prototype Implementation review Life-Cycle Models

Spiral Model (Barry Boehm) Important features: Risk analysis Prototyping Iterative framework allowing ideas to be checked and evaluated Explicitly encourages alternatives to be considered Good for large and complex projects but not simple ones Life-Cycle Models

Spiral Lifecycle Model From cctr.umkc.edu/~kennethjuwng/spiral.htm Life-Cycle Models

The Star Lifecycle Model Suggested by Hartson and Hix (1989) Important features: Evaluation at the center of activities No particular ordering of activities. Development may start in any one Derived from empirical studies of interface designers Life-Cycle Models

The Star Model (Hartson and Hix, 1989) Implementation task/functional analysis Requirements specification Prototyping Evaluation UCD is a very general philosphy that instantiates itself in the context of a design project. Within HCI there have been many attempts to come up with actual life cycles where users are central. Examples include Rubinstein and Hersch successive iteration of 5 stages, info collecion, design, implementation, evaluation and deploment. The one here is taken fromHartson and Hix model came about by analysing how design takes place in practice evaluation is central: results of each ativity are evaluated before going onto next one both bottom-up and top -down required in waves software designers are familiar with this in their work and call it ‘yo-yoing’ it is important to do both structure and detail at the same time in practice this is what is done - but the end result suggests otherwise corporate requirments dictate a top=down approach which is wha gets recorded ch 5 of Developing User Interfaces (An Overview of Systems Analysis and Design) p- nice step-by-step methodology for doing user-centred design Conceptual/ formal design Life-Cycle Models

Usability engineering Lifecycle Model Reported by Deborah Mayhew Important features: Holistic view of usability engineering Provides links to software engineering approaches, e.g. OOSE Stages of identifying requirements, designing, evaluating, prototyping Can be scaled down for small projects Uses a style guide to capture a set of usability goals Life-Cycle Models

Usability engineering Lifecycle Model Platform Capabilities/ Constraints General Design Principles Usability Goals Contextual Task Analysis User Profile Style Guide REQUIREMENTS ANALYSIS Function/Data Modeling OOSE: Requirements Model Start Application Architecture OOSE: Analysis Model Screen Standards SDS Prototyping Iterative Evaluation LEVEL 2 Met Goals? NO YES Work Reengin- eering Conceptual Model CM Mockups LEVEL 1 Eliminated Major Flaws? Start App. Design/Development OOSE: Design Model/Imp. Model Feedback Detailed UI DUID LEVEL 3 All Functionality Addressed? Unit/System Testing OOSE: Test Model Issues Resolved? Installation Enhancements DONE! DESIGN/TESTING/DEVELOPMENT INSTALLATION UE Task Development Task T Decision Point Documentation Complex Application Simple Application Life-Cycle Models

Design Model Requirements Design Build/Develop Evaluate Design Model

Requirements A requirement is something the product must do or a quality that the product must have Requirements

Requirements Different kinds of requirements: Functional: What the system should do Historically the main focus of requirements activities Non-functional: memory size, response time.. Data: What kinds of data need to be stored? How will they be stored (e.g. database)? Usability: learnability throughput flexibility attitude Requirements

Requirements Determining Usability Requirements: Task Analysis User Analysis Environment Analysis Requirements

Requirements Task Analysis Task analysis describes the behavior of a system Determine cognitive and other characteristics required of users by system search strategy prereq knowledge cognitive loading etc. Observe existing work practices Create scenarios of actual use new ideas before building software! Get rid of problems early in the design process Requirements

Requirements Task Analysis Who is going to use the system? What tasks do they now perform? What tasks are desired? How are the tasks learned? Where are the tasks performed? What’s the relationship between user & data? Requirements

Requirements Types of Task Analysis Task Decomposition Knowledge Based Analysis Entity-Relationship Based Analysis Requirements

Requirements Task Decomposition Task Decomposition: top-down process in which a task is split into component sub-tasks: Select a task Based your data (from observation, documentation, and expert advice), divide the task into sub-tasks. If your stopping rule has not been reached, repeat steps 1-3 for each of the new sub-tasks. The stopping condition you use - the level of detail you recurse to - depends on your purpose in performing the analysis. Requirements

Requirements Knowledge-Based Analysis Knowledge-based analysis works from the bottom up The starting point for the process is a list of all of the objects and actions that are relevant to the task that is being analyzed, based on data collected . The objects are then arranged into groups based on similarity or shared traits. The groups themselves are then grouped together, building progressively more abstract categories Requirements

Requirements Entity-Relationship Based Analysis Entity-relationship analysis is also a bottom-up approach to task analysis, inheriting much of its structure from object-oriented programming. Entity-relationship analysis concerns itself with objects, actions, and their relationship: Objects - simple objects, actors, composite objects, and events. Object-relationship analysis - relationship between objects Requirements

Requirements User Analysis Who are they? Characteristics: ability, background, attitude to computers System use: novice, expert, casual, frequent Novice: step-by-step (prompted), constrained, clear information Expert: flexibility, access/power Frequent: short cuts Casual/infrequent: clear instructions, e.g. menu paths Requirements

Requirements Environment Analysis Physical: dusty? noisy? vibration? light? heat? humidity? …. (e.g. OMS insects, ATM) Social: sharing of files, of displays, in paper, across great distances, work individually, privacy for clients Organisational: hierarchy, IT department’s attitude and remit, user support, communications structure and infrastructure, availability of training Requirements

Design Model Requirements Design Build/Develop Evaluate User-centred design Build/Develop Evaluate Design Model

User-Centred Design Why involve users at all? What is a user-centered approach? Understanding user’s work Ethnographic observation Participatory design PICTIVE CARD User-Centred Design

Why involve Users? Expectation management Ownership Realistic expectations No surprises, no disappointments Timely training Communication, but no hype Ownership Make the users active stakeholders More likely to forgive or accept problems Can make a big difference to acceptance and success of product User-Centred Design

What is a User-Centred Approach? User-centered approach is based on: Early focus on users and tasks: directly studying cognitive, behavioural, anthropomorphic & attitudinal characteristics Empirical measurement: users’ reactions and performance to scenarios, manuals, simulations & prototypes are observed, recorded and analysed Iterative design: when problems are found in user testing, fix them and carry out more tests User-Centred Design

Ethnographic Observation Preparation Understand organization policies and work culture. Familiarize yourself with the system and its history. Set initial goals and prepare questions. Gain access and permission to observe/interview. Field Study Establish rapport with managers and users. Observe/interview users in their workplace and collect subjective/objective quantitative/qualitative data. Follow any leads that emerge from the visits. User-Centred Design

Ethnographic Observation Analysis Compile the collected data in numerical, textual, and multimedia databases. Quantify data and compile statistics. Reduce and interpret the data. Refine the goals and the process used. Reporting Consider multiple audiences and goals. Prepare a report and present the findings. User-Centred Design

Participatory Design User-Centred Design

Participatory Design Controversial More user involvement brings: more accurate information about tasks more opportunity for users to influence design decisions a sense of participation that builds users' ego investment in successful implementation potential for increased user acceptance of final system User-Centred Design

Participatory Design However, extensive user involvement may: be more costly lengthen the implementation period build antagonism with people not involved or whose suggestions rejected force designers to compromise their design to satisfy incompetent participants build opposition to implementation exacerbate personality conflicts between design-team members and users show that organizational politics and preferences of certain individuals are more important than technical issues User-Centred Design

Participatory Design PICTIVE Plastic Interface for Collaborative Technology Initiatives through Video Exploration Intended to empower users to act a full participants in design Materials used are: Low-fidelity office items such as pens, paper, sticky notes Collection of (plastic) design objects for screen and window layouts Equipment required: Shared design surface, e.g. table Video recording equipment User-Centred Design

Participatory Design PICTIVE (cont.) Before a PICTIVE session: Users generate scenarios of use Developers produce design elements for the design session A PICTIVE session has four parts: Stakeholders all introduce themselves Brief tutorials about areas represented in the session (optional) Brainstorming of ideas for the design Walkthrough of the design and summary of decisions made User-Centred Design

Participatory Design CARD Collaborative Analysis of Requirements & Design Similar to PICTIVE but at a higher level of abstraction: explores work flow not detailed screen design Uses playing cards with pictures of computers and screen dumps Similar structure to the session as for PICTIVE PICTIVE and CARD can be used together to give complementary views of a design User-Centred Design

Summary of Lecture Lifecycle models HCI design models Software engineering lifecycle models HCI lifecycle models   Usability Engineering Lifecycle Model Star Lifecycle Model HCI design models Requirements Design User-centred design Develop/Build Evaluation

Terms of Reference Preece, J. et al. (2002) Interaction Design Shneiderman, B. & Plaisant, C. (2005) Designing the User Interface Benyon, D. et al (2005) Designing Interactive Systems Helander, M. et al (1997) Handbook of Human- Computer Interaction Hartson, R. & Hix, D. (1989) Towards Empirically Derived Methodologies and Tools for HCI Development Mayhew, D. (1995) The Usability Engineering Lifecycle Alan Dix et al (1993) Human Computer Interaction References