HCI Lifecycle Overview

1
Advanced HCI COM719M1

• HCI Lifecycle Overview
• Task Analysis
• Dr Joan Condell
• Supported by Ms Anne Hinds

2
Advanced HCI Module Assessments

• Assignment 1 Prototype
• 30
• Individual project Design and implement a simple
  interactive system
• Individual presentation
• Prototype and Report Submission during week 8
  (presentations weeks 7, 8 and 9)
• Assignment 2 Group Critique Report
• 20
• Group work Critical evaluations and comparison
  of selected individual projects
• Group presentations weeks 10 and 11
• Report Submission during week 12
• 3 hr Examination
• 50

3
Weeks 1, 2, 3 and 4

• HCI and Cognitive Frameworks, Perception
• Attention / Memory Knowledge / Conceptual
  Models Learning. HCI Guidelines
• Human Capabilities Physiology HCI
  Accessibility Tasks and Contexts
• Interactive System Design. Compare traditional vs
  HCI systems analysis Data gathering and design
  Problem statement and design solutions User
  analysis Hierarchical Task Analysis (HTA) and
  Task Hierarchy Diagramming (THD)

4
YouTube Mar 09iPhone Ocarina Demo

• http//www.youtube.com/watch?vtERtCiAvdfQ
• Ge Wang (Stanford Univ., Smule CTO)
• 2009 eComm (Emerging Communications) Conference
  San Francisco
• Expressive Social Media App
• Touch / Breathe Mobile Phone App

5
Lecture Overview

• Overview of interactive system design
• Compare
• Traditional Systems analysis
• HCI approach perspective
• Data gathering and design
• Interactive systems design
• Problem statement and design solutions
• User analysis
• Hierarchical Task Analysis (HTA)
• Task Hierarchy Diagramming (THD)
• Action and object lists
• HTA Examples of THD

6
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
7
HCI vs. Systems Analysis and Design

• Traditional Systems Analysis
• End user plays minor role
• User consulted on what info is input, what output
  is needed BUT dont consider how tasks are
  performed
• Main emphasis on tasks technical aspects (data
  structures and programs)
• HCI Approach
• Focus on USERS goals, needs, abilities,
  knowledge, preferences
• User involved at all stages of design

8
Perspectives in Tension 1 - Traditional Systems
Analysis

• Different characteristics of design process
• Functionally oriented and data driven
• Functional requirements
• Logical flow of data
• Computational efficiency
• Ease of development
• Identify entities of significance to system
• Design notation
• E.g. Data flow diagrams, Entity-Relationship
  diagrams
• Often met with resistance by users (as not
  consulted!)

9
Perspectives in Tension 2 HCI approach

• Identifies issues of practical effectiveness
• What suits user?
• Usability orientation/factors e.g. speed, error
  rates
• Quality of user interface User requirements
• Design notation Nothing formal - designed to be
  understood by users e.g. task hierarchy diagram,
  screen sketch
• In future integrate HCI into formal development
  rather than add-on

10
Conventional HCI Data Gathering

• Same techniques BUT different emphasis on kind of
  info gathered
• INTERVIEWS
• Conventional what processes should be included?
• HCI what do you like/dislike? What have you
  experience of? Why do you prefer one system to
  another?
• Read background material
• Guided tour of work environment
• Observation/Questionnaires
• Forms analysis/Verbal protocol
• Tape / Video recording / Transcript (during
  experiments)

11
Definition of Design

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

Feilden Committee Report, 1963 Engineering
Design, HMSO
How do you define design?
12
YouTube Dec 08, Good and Bad Design

• http//www.youtube.com/watch?vzSWB31OwhlU
• IIT Bombay Anirudha Joshi

13
YouTube Aug 06, Alan Partridge on Bad
Interaction Design

• http//www.youtube.com/watch?vPM8LLp7Q5WQfeature
  PlayListp4DFB463031238A89index0
• Alan illustrates a hierarchy of alerts within the
  dashboard/fascia control system of the Rover 200.
  
• He's . exasperated as he doesn't know why his
  Rover make an alarm noise when he turns the key
  in the ignition. For the last ten minutes, he's
  been exploring the possible reasons for the
  alarm.
• Lynn's suggestions serve only to force Alan to
  explain a few things about in-car control systems
  ...

14
Balance Among Conceptual, Interaction and
Presentation Design Effort (3 levels of design
task)

• 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
Have knowledge of users then use this in design!
15
YouTube Karel Vredenburg Oct 07, Conceptual
Design

• http//www.youtube.com/watch?veONPODwf-zMfeature
  PlayListp4DFB463031238A89index5
• "User-Centered Design An Integrated Approach" by
  Karel Vredenburg, Scott Isensee, and Carol Righi.
  

16
Balance of Design Effort (1)

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

17
Balance of Design Effort (2)

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

18
GROUP Team Roles in Interactive System
Development Process
User (domain expert)
Team
User interaction developer
User interface software developer
No agreed starting point often carry out
different steps in parallel
19
3 Inter-related Design Team Roles

• User (domain expert)
• Person to use system (NB could be range of users)
  
• Person with knowledge about what system must do
• User Interaction Developer
• Person designing interface/support materials
• Designs conceptual models of what is required
  from users viewpoint (decides on menus, colours,
  fonts, etc.)
• User Interface s/w Developer
• Person programming/implementing designs (data,
  process and interface)

20
4 Fundamental Activities of Interactive System
Design

• Problem Statement Definition
• Information gathering (with model building)
• Building of solution (or enhancement)
• Evaluation of solution

These activities are iterated
ALWAYS FOCUS ON USER!
21
Problem StatementDefinition of Design Objectives

• Important to get right!
• Parts could change later as system evolves
• Statement of goal of system in phrase/sentence
• Aim show clear understanding of what is needed
• State main assumptions
• 4 issues
• Form of solution to the problem
• Level of support to be provided - system
  usability (features needed to carry out
  functions, fast, flexible)
• Human activity that proposed system will support
• Users who will perform that activity

22
Problem statement exampleQueue problem

• 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.
• Possible solutions (1)?
• Think - what, precisely, is the problem?
• Dont just jump in with solution

23
Possible solutionsQueue problem

• Easier ticket preparation by the clerks.
• Easier payment handling by clerks.
• Easier record keeping by clerks.
• Ticket machines for passengers.
• Choosing between these is down to
• experience
• preliminary analysis of each solution
• preference of managers/designers
• E.g. choose ticket machine solution then.

24
Design problem for Ticket Machine Solution to
Queue problem

• Design a cash-operated machine for quick and
  easy purchase of railway tickets for passengers
• Problem Statement
• 4 issues for design
• Form of solution a cash-operated machine
• Level of support for quick and easy
• Human activity purchase of railway tickets
• Users by passenger

25
Problem Diary Management System

• 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
  an alarm to be set for a user-specified time
  before certain appointments

26
Problem Definition Diary Management System

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

NB form of soln level of support human
activity users
27
Problem Statement Diary Management System

• Form of solution
• Portable hardware, low selling price
• Level of support
• Appointment (an object)
• Maintain (an operation)
• Add, modify, delete, view appointments
• Adjust alarm
• Human activity
• Maintain appointments
• Users
• Professionals/managers White collar customers

28
User AnalysisTo obtain info on potential users

• Expertise level (novice, intermittent, frequent)
• Familiarity with specific hardware and software
• Software with which 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

These may not all be relevant for specific
problems
29
User Analysis Ticket Machine Solution for
Queue Problem (1)

• Expertise level
• Novice e.g. one off travellers on line such as
  tourists
• Intermittent e.g. people in area who travel
  occasionally
• Expert e.g. frequent commuters, many times per
  day
• Familiarity with hardware/software (N/A)
• Software with which familiar
• E.g. ATM machines
• Job-related information access needs
• Cost of journey to specific locations

30
User Analysis Ticket Machine Solution for
Queue Problem (2)

• Skill base
• Can all users type accurately/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?

31
Task analysis?

• Determining tasks for which users want to use
  software
• Sits alongside other processes in systems
  development
• e.g. determining processes in programs
• Emphasis always on what user wants to do with
  software i.e. user-centred HCI

32
YouTube Karel Vredenburg Oct 07, Task Analysis

• http//www.youtube.com/watch?v1KML29WefLofeature
  PlayListp4DFB463031238A89index6
• "User-Centered Design An Integrated Approach" by
  Karel Vredenburg, Scott Isensee, and Carol Righi.
  

33
Definition of a Task
Tasks are how the user sees an interface.
(Hix and Hartson, 1993)

• Something user wants to achieve
• Work element or ACTIVITY with specific
  start/end
• Must be meaningful to user
• Goal directed e.g.
• Identify particular invoice
• Making decision to label a document
• Described using appropriate language (THD)

34
Definition of Task Analysis

• Describe tasks in terms of
• Goals (or states) they achieve
• Steps involved
• Relevant contextual information
• Interface design relies on knowledge of frequency
  of use and ordering of tasks
• Techniques exist for analysis
• Task decomposition (split tasks into subtasks in
  sequence)
• Knowledge-based techniques (what users need to
  know)
• Hierarchical Task Analysis (decompose tasks into
  subtask with no reference to order)

35
Hierarchical Task Analysis

• Task analysis may provide logical task allocation
  proposals and users terminology
• Make initial design decisions
• Directly drives design
• Hierarchical Task Analysis (HTA)
• Range of techniques to describe what people do
• Represents descriptions, predicts difficulties
• Evaluates systems against usability / functional
  requirements

36
Building the Picture

• Identify major tasks (fundamental)
• Regular tasks must be easily accessed and visible
  (and vv)
• Identify tasks to be achieved (and into subtasks)
• Determine frequency of tasks (and level of
  detail)
• Determine necessary or typical task ordering
• Tasks grouped/related are ordered in logical
  sequence
• Aids usability and saves time
• Structure task domain to match users mental
  model
• Identify parallel tasks
• Specify in terms of objectives

37
Building the Picture (Contd)

• Build up hierarchy of tasks/subtasks
• Draw subtasks as layered diagram
• Obtain details by generating scenarios
• Continue decomposition consistently
• Ask real users to check analysis
• Analyse individual tasks for possible error
  conditions
• Results of task analysis
• Users goals (higher and lower levels)
• Actions
• Objects

38
Task DecompositionSummary of questions to ask
in developing HTA
Why?
What happens before?
What happens next?
TASK
What subtasks?
General approach work through typical /
exceptional scenarios OR observe users at task
39
Task Hierarchy Diagram (THD) Structure Chart

• Represents normal sequence of tasks/sub-tasks
• Parallel interaction can be indicated (double
  bar)
• Basis for
• User interface design decisions
• Training and documentation materials
• Annotations on contextual info e.g.
• How often task/sub-task occurs
• How long they take to complete
• Errors that might occur
• Time it takes user to become proficient in task
• Other relevant information, e.g. forms or tools
  used

40
Additional Points on THD

• Abstract representations of user tasks
• Should not be constrained by implementation
  details E.g. NO mention of input devices or
  screen formats
• Task labels written as operation followed by
  object
• verb noun e.g. Enter text
• Used as guide in dialogue design
• Frequency
• Sequence
• Criticality
• Interleaving

41
Derive Action and Object Lists from THD

• Basis for naming / grouping commands and
  parameters
• Action list mental or physical
• Object list physical or symbolical
• on which actions are performed e.g. report
• Actions and/or objects may become visible
  interface components
• Menu items / icons / lists in combo boxes
• Task qualifiers e.g. parameters
• Items about which data is held

42
Hierarchical Task Analysis (HTA) Example of THD

• GOAL To develop a set of icons
  (using an icon drawing package that
  exists)
• What are main tasks and sub-tasks needed to
  achieve this goal?
• (Think of tasks needed to design/produce ONE
  icon - these would then be repeated for further
  icons.)

43
Develop Set of Icons
Develop Set of Icons
Determine object/action /feature to represent
Make icons
Save, print, etc.
Assess suitability of existing icons
Decide main shape/symbol
Modify pixels
Assess aesthetics/ compatibility with others
View likely icons
Consider style of icons in current system
Compare with other icons
Copy existing icon
Add shape
Cut/paste/ undo
Draw line
Colour, rotate, flip, invert etc.
Retrieve set of icons
Refer to printed material
NB Parallel lines denote parallel tasks
44
HTA Allocation of Function between Human and
Computer
Can assess user reaction to system AND
costs/benefits Is it worth developing if
computer doesnt do much?
Human in Control
Spectrum of allocation types
L. Macaulay, 1995
45
Develop Set of Icons
Shared Human-Computer Task
Develop Set of Icons
Determine object/action /feature to represent
Make icons
Save, print, etc.
Assess suitability of existing icons
Decide main shape/symbol
Modify pixels
Assess aesthetics/ compatibility with others
Copy existing icon
Cut/paste/ undo
Draw line
View likely icons
Consider style of icons in current system
Compare with other icons
Add shape
Colour, rotate, flip, invert etc.
Retrieve set of icons
Refer to printed material
This highlights allocation of function (tasks
used by human WHITE and computer/shared GREEN)
46
Task Hierarchy for Interpreting Brief for CAD
SystemDepict flow of items/function allocation
Interpret Brief
Read Brief
Identify Constraints
Produce Outline Scheme
Undertake cost/ Benefit Analysis
Identify Causes of Problem
Invent Possible Solutions
Write report on Recommendations
Draw maps of alternative Solutions
L. Macaulay, 1995
47
THD for Interpret Brief (for CAD System)
Interpret Brief
Shared Human - Computer Task
Read Brief
Produce Outline Scheme
Identify Constraints
Identify Causes of Problem
Write report on Recommendations
Invent Possible Solutions
Undertake cost/ Benefit Analysis
Draw maps of alternative Solutions
L. Macaulay, 1995
48
Lecture Review

• Overview of interactive system design
• Compare
• Traditional Systems analysis
• HCI approach perspective
• Data gathering and design
• Interactive systems design
• Problem statement and design solutions
• User analysis
• Hierarchical Task Analysis (HTA)
• Task Hierarchy Diagramming (THD)
• Action and object lists
• HTA Examples of THD