1

The Design Process

Lecture 9Date: 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

Evaluate

(Re)Design

Identify needs/ establish

requirements

Build an interactive version

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

JAD workshops

Project set-up

Iterative design and build

Engineer and test final prototype

Implementationreview

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)

Evaluation

Conceptual/formal design

RequirementsspecificationPrototyping

task/functionalanalysis

Implementation

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

PlatformCapabilities/Constraints

PlatformCapabilities/Constraints

GeneralDesign

Principles

GeneralDesign

Principles

UsabilityGoalsUsability

Goals

ContextualTask

Analysis

ContextualTask

Analysis

UserProfile

UserProfile

StyleGuide

REQUIREMENTS ANALYSIS

Function/Data ModelingOOSE: Requirements Model

Start Application ArchitectureOOSE: Analysis Model

ScreenDesign

Standards

ScreenDesign

Standards

SDSPrototyping

SDSPrototyping

IterativeSDS

Evaluation

IterativeSDS

Evaluation

LEVEL 2

MetUsabilityGoals?

NO YES

StyleGuide

WorkReengin-

eering

WorkReengin-

eering

ConceptualModelDesign

ConceptualModelDesign

CMMockups

CMMockups

IterativeCM

Evaluation

IterativeCM

Evaluation

LEVEL 1

EliminatedMajor

Flaws?NO YES

StyleGuide

Start App. Design/DevelopmentOOSE: Design Model/Imp. Model

UserFeedback

UserFeedback

DetailedUI

Design

DetailedUI

Design

IterativeDUID

Evaluation

IterativeDUID

Evaluation

LEVEL 3

AllFunctionalityAddressed?

NO

YES

MetUsabilityGoals?

StyleGuide

Unit/System TestingOOSE: Test Model

NO

YES

AllIssues

Resolved?

Installation

NO

Enhancements

DONE!

YES

DESIGN/TESTING/DEVELOPMENT

INSTALLATION

UE Task

Development TaskT

Decision Point

Documentation

Complex Application

Simple Application

13

Design Model

Design Model

Requirements

Design

Build/Develop

Evaluate

14

Requirements

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

have

Requirements

15

RequirementsDifferent kinds of requirements:

•Functional:Functional: •What the system should do•Historically the main focus of requirements activities

•Non-functional:Non-functional: •memory size, •response time..

• Data:Data:•What kinds of data need to be stored?•How will they be stored (e.g. database)?

•Usability:Usability: •learnability •throughput•flexibility•attitude

Requirements

16

Requirements

Determining Usability Requirements:Determining Usability Requirements:

•Task AnalysisTask Analysis

•User AnalysisUser Analysis

•Environment AnalysisEnvironment Analysis

Requirements

17

Requirements Task AnalysisTask 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

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

RequirementsTypes of Task AnalysisTypes of Task Analysis

•Task Decomposition

•Knowledge Based Analysis

•Entity-Relationship Based Analysis

Requirements

20

RequirementsTask DecompositionTask 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 AnalysisKnowledge-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

RequirementsEntity-Relationship Based AnalysisEntity-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 AnalysisUser Analysis

•Who are they?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 AnalysisEnvironment 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

Design Model

Requirements

DesignUser-centred design

Build/Develop

Evaluate

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

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

33

Participatory Design

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

34

Participatory Design

PICTIVEPICTIVE•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.)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

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