1 the design process lecture 6 desiamore

1

The Design Process

Lecture 6

DeSiaMore www.desiamore.com/ifm

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 ModelsDeSiaMore www.desiamore.com/ifm

4

A simple interaction design model

Evaluate

(Re)Design

Identify needs/ establish

requirements

Build an interactive version

Final productExemplifies a user-centered design approach


5

Traditional ‘waterfall’ lifecycle

Requirements analysis

Design

Code

Test

Maintenance


6

A Lifecycle for RAD (Rapid Applications

Development)

JAD workshops

Project set-up

Iterative design and build

Engineer and test final prototype

Implementationreview


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


8

Spiral Lifecycle Model

From cctr.umkc.edu/~kennethjuwng/spiral.htm


9

The Star Lifecycle Model

•Suggested by Hartson and Hix (1989)

•Important features:—Evaluation at the centre of activities

—No particular ordering of activities. Development may start in any one

—Derived from empirical studies of interface designers


10

The Star Model (Hartson and Hix, 1989)

Evaluation

Conceptual/formal design

RequirementsspecificationPrototyping

task/functionalanalysis

Implementation


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


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

RequirementsDeSiaMore www.desiamore.com/ifm

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


16

Requirements

Determining Usability Requirements:Determining Usability Requirements:

•TaskTask Analysis Analysis

•UserUser Analysis Analysis

•EnvironmentEnvironment Analysis Analysis


17

Requirements 1. Task AnalysisTask Analysis

•Task analysis describes the behavior of a system

•Determine cognitive and other characteristics required of users by system

•Observe existing work practices

•Create scenarios of actual use•new ideas before building software!•Get rid of problems early in the design process


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?


19

RequirementsTypes of Task AnalysisTypes of Task Analysis

• Task Decomposition (top-down)1. Select a task 2. Divide the task into sub-tasks 3. If your stopping rule has not been reached, repeat steps 1-3 for

each of the new sub-tasks.

• Knowledge Based Analysis (bottom-up)1. List all of the objects and actions that are relevant to the task2. Groups based on similarity or shared traits3. The groups themselves are then grouped together, building

progressively more abstract categories

• Entity-Relationship Based Analysis (bottom-up)

• concerns itself with objects, actions, and their relationship


20

Requirements 2. User Analysis2. User 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


21

Requirements 3. 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


22

Design Model

Design Model

Requirements

DesignUser-centred design

Build/Develop

Evaluate


23

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 DesignDeSiaMore www.desiamore.com/ifm

24

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


25

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


26

Ethnographic Observation

•Preparation•Understand organisation policies and work culture. •Familiarise 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.


27

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.


28

Participatory Design


29


User-Centred Design

• Participatory design is an approach to design that attempts to actively involve the end users in the design process.

• It assumes that users should play an active role in the creative process: users envision the future by identifying the defining moments from their perspective

DeSiaMore www.desiamore.com/ifm 29

30


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


31


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 organisational politics and

preferences of certain individuals are more important than technical issues


32


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


33


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


34


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


35

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


36

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 InteractionReferencesDeSiaMore www.desiamore.com/ifm

1 the design process lecture 6 desiamore

Documents

spiral lifecycle modelfrom

star lifecycle modelsuggested

design processlecture

star model hartson

overviewlife models

otherlifecycle models

comif kinds of requirements

hci4 basic activities