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)
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

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

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?
What’s 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 department’s attitude and remit, user support, communications structure and infrastructure, availability of training
Requirements

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

26. 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

27. 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

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/qualitative 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 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

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