HCI Lifecycle Overview and Initial Analysis

1
Human-Computer Interaction

• HCI Lifecycle Overview and Initial Analysis

2
Lecture Overview

• Overview of interactive system design
• Development team roles
• Problem statement
• Systems analysis HCI perspective
• User analysis

3
HCI and the Software Lifecycle
Problem statement
Definition
Systems Analysis (inc. user and task analysis)
Analysis
Requirements spec. (inc. usability specs.)
User object modeling
System design spec. (inc. Interface design spec.)
U s e r P a r t i ci p a t i o n
Users conceptual model design / Interaction
style
Design
Interaction design / Presentation design
Prototype (inc. online help)
Evaluation (Analytical, Empirical)
Implementation
4
Perspectives in Tension

• Systems analysis and software implementation
• Logical flow of data
• Computational efficiency
• Ease of development
• HCI
• Quality of user interface

5
Systems Analysis HCI Perspective

• Systems analysis
• Identify entities of significance to the system
• Functionally oriented and data driven
• Design notation
• E.g. Data flow diagrams, Entity-Relationship
  diagrams
• Often met with resistance by users
• HCI perspective
• Identifies issues of practical effectiveness
• Usability orientation -
• E.g. speed, error rates
• Design notation
• Designed to be understood by users e.g. task
  hierarchy diagram, screen sketch

6
Microsoft Using Customer Feedback for Developing
Web Site

• Listening to and understanding users
• Observing how they work with software and what
  tasks they perform
• Coming up with features to address these work
  styles and tasks
• Testing the features with the people that
  actually use them

See - http//www.microsoft.com/misc/backstage/co
lu
7
Conventional HCI Data Gathering

• Read background material
• Guided tour of work environment
• Interviews
• Observation
• Questionnaires
• Forms analysis
• Verbal protocol
• Tape / Video recording / Transcript

8
Definition of Design

• . . . the use of
• scientific principles, technical information
• and imagination.

Feilden Committee Report, 1963 Engineering
Design, HMSO
9
Balance Among Conceptual, Interaction and
Presentation Design Effort

• Presentation (Look)
• Visual representations
• Aesthetics
• Interaction (Feel)
• Interaction techniques
• Standard menus

Detailed design
10
Design proceeds mainly from the bottom level up
30
60
Metaphors, object attributes, relationships,
behaviours
Conceptual design
10
Balance of Design Effort

• Conceptual Level 60 of Design Effort
• Deciding what is required in terms of data,
  functions and usability. Deciding on metaphors
  that might be used in the interface. What
  objects should the interface have (buttons,
  keyboard, etc), how should they behave, are there
  any relationships between them?
• Interaction Design 30 of Design Effort
• How will interface feel to the user? How will
  they interact with it press buttons (direct or
  roll-ball device), select from menus? If so, what
  should these contain? Will user need to type in
  data?

11
Balance of Design Effort (2)

• Presentation 10 of Design Effort
• How should the interface look? How will
  information be represented? What colours to use,
  size of objects, buttons, etc.

12
Roles in a Team for Interactive System Development
User (domain expert)
Team
User interaction developer
User interface software developer
13
Design Team Roles

• User (domain expert)
• Person who is to use the system and/or who has
  detailed knowledge about what the system must do
• User Interaction Developer
• Person who designs interface and support
  materials. Designs conceptual models of what is
  required from users point of view. Decides on
  menus, colours, fonts, etc.
• User Interface s/w Developer
• Person who programs and implements designs (data,
  process and interface)

14
Fundamental Activities of Interactive System
Design

• Problem Definition
• Information gathering and model building
• Synthesis (or enhancement) of a solution
• Analysis (or evaluation) of a solution

These activities are iterated
15
Problem StatementA definition of Design
Objectives

• Supported activity human activity that proposed
  system will support
• Users who will perform that activity
• Level of support to be provided - system
  usability
• Form of solution to the problem
• Statement of overall goal of whole system in a
  single phrase or sentence
• Aim show clear understanding of what is needed
• Main assumptions should be separately stated

16
Problem statement - example

• A railway company has a 'situation of concern' -
  passenger queues at ticket offices are too long,
  too often. They might consider a number of
  possible solutions that involve design problems.
• Can you think of possible solutions (think -
  what, precisely, is the problem?)?

17
Queue problem - possible solutions

• A railway company has a 'situation of concern' -
  passenger queues at ticket offices are too long,
  too often. They might consider a number of
  possible solutions that involve design problems.
  For example,
•  
• Easier ticket preparation by the clerks.
• Easier payment handling by clerks.
• Easier record keeping by clerks.
• Ticket machines for passengers.
•  

18
Problem

• Design a cash-operated machine for quick and easy
  purchase of railway tickets for passengers
• Problem Statement
• Design
• A cash-operated machine form of solution
• For quick and easy level of support
• Purchase of railway tickets supported activity
• By passenger - users

19
Problem

• Design a hand-held, inexpensive machine which
  will allow professional/managerial people to
  maintain an appointments diary and which will
  support the functions of adding, deleting,
  modifying, viewing appointments, and will allow
  and alarm to be set for a user-specified time
  before certain appointments

20
Problem Statement Example for Diary Management
System

• Form of solution
• Portable hardware, low selling price
• Level of support to be provided
• Appointment (an object)
• Maintain (an operation)
• Add, modify, delete, view appointments
• Adjust alarm
• Supported activity
• Maintain appointments
• Users
• White collar customers

21
User Analysis

• Expertise level (novice, intermittent, frequent)
• Familiarity with specific hardware and software
• Software with which users are familiar
• Job-related information access needs
• E.g. summary vs detailed
• Skill base e.g. keyboarding
• General educational level
• Organization-specific knowledge and/or experience

22
User Analysis Example for Railway Ticket System

• Expertise level
• Novice eg one off travellers on the line such as
  tourists
• Intermittent eg people in the area who travel
  occasionally
• Expert eg frequent commuters
• Familiarity with specific hardware and software
• No assumptions can be made in this case
• Software with which users are familiar
• Eg ATM machines
• Job-related information access needs
• Cost of journey to specific locations

23
User Analysis Example for Railway Ticket System
(2)

• Skill base
• Are all users likely to be able to type
  accurately and quickly on QWERTY or alphabetic
  keyboard?
• General educational level
• All levels must be catered for including those
  who dont speak English or can handle English
  currency
• Organization-specific knowledge and/or experience
• Can we assume everyone has bought a ticket
  before?

24
User Analysis Example for Diary Management System

• User characteristics
• Professional, white collar
• Keeps schedule for self and/or others
• Sometimes just for personal use
• Keeping diary is a very small part of users job
• Skills
• High general skill level
• Not necessarily computer skilled
• Not all will have keyboard skills
• Conclusions
• Keep it simple
• Functionality and usability greater than for
  paper diary
• Minimize typing, and be quick and easy to learn

25
Lecture Review

• Overview of interactive system design
• Development team roles
• Problem statement
• Systems analysis HCI perspective
• User analysis