The Design Process

1
The Design Process

• Lecture 9
• Date 2nd March

2
Overview

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

3
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
4
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
5
Traditional waterfall lifecycle
Requirements analysis
Design
Code
Test
Maintenance
Life-Cycle Models
6
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
7
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
8
Spiral Lifecycle Model
From cctr.umkc.edu/kennethjuwng/spiral.htm
Life-Cycle Models
9
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
10
The Star Model (Hartson and Hix, 1989)
task/functional analysis
Implementation
Requirements specification
Evaluation
Prototyping
Conceptual/ formal design
Life-Cycle Models
11
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
12
Usability engineering Lifecycle Model
Life-Cycle Models
13
Design Model
Requirements
Design
Build/Develop
Evaluate
Design Model
14
Requirements

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

Requirements
15
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
16
Requirements

• Determining Usability Requirements
• Task Analysis
• User Analysis
• Environment Analysis

Requirements
17
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
18
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?
• Whats the relationship between user data?

Requirements
19
Requirements

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

Requirements
20
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
21
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
22
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
23
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
24
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 departments
  attitude and remit, user support, communications
  structure and infrastructure, availability of
  training

Requirements
25
Design Model
Requirements
Design User-centred design
Build/Develop
Evaluate
Design Model
26
User-Centred Design

• Why involve users at all?
• What is a user-centered approach?
• Understanding users work
• Ethnographic observation
• Participatory design
• PICTIVE
• CARD

User-Centred Design
27
Why involve Users?

• Expectation management
• 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
28
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
29
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/qualitat
  ive data.
• Follow any leads that emerge from the visits.

User-Centred Design
30
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
31
Participatory Design
User-Centred Design
32
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
33
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
34
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
35
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
36
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
37
Summary of Lecture

• Lifecycle 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

38
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