The design process
This presentation is the property of its rightful owner.
Sponsored Links
1 / 38

The Design Process PowerPoint PPT Presentation


  • 58 Views
  • Uploaded on
  • Presentation posted in: General

The Design Process. Lecture 9 Date: 2 nd March. Overview. Life-Cycle Models in HCI 4 basic activities in HCI Requirements Design Develop/Build Evaluation. Lifecycle Models. Show how activities are related to each other Lifecycle models are: management tools

Download Presentation

The Design Process

An Image/Link below is provided (as is) to download presentation

Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author.While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server.


- - - - - - - - - - - - - - - - - - - - - - - - - - E N D - - - - - - - - - - - - - - - - - - - - - - - - - -

Presentation Transcript


The design process

The Design Process

Lecture 9

Date: 2nd March


Overview

Overview

  • Life-Cycle Models in HCI

  • 4 basic activities in HCI

    • Requirements

    • Design

    • Develop/Build

    • Evaluation


Lifecycle models

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


A simple interaction design model

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


Traditional waterfall lifecycle

Traditional ‘waterfall’ lifecycle

Requirements analysis

Design

Code

Test

Maintenance

Life-Cycle Models


A lifecycle for rad rapid applications development

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


Spiral model barry boehm

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


Spiral lifecycle model

Spiral Lifecycle Model

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

Life-Cycle Models


The star lifecycle model

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


The star model hartson and hix 1989

The Star Model (Hartson and Hix, 1989)

Implementation

task/functional

analysis

Requirements

specification

Prototyping

Evaluation

Conceptual/

formal design

Life-Cycle Models


Usability engineering lifecycle model

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


Usability engineering lifecycle model1

Usability engineering Lifecycle Model

REQUIREMENTS ANALYSIS

UE Task

T

Development Task

User

Profile

Contextual

Task

Analysis

Platform

Capabilities/

Constraints

General

Design

Principles

Decision Point

Documentation

DESIGN/TESTING/DEVELOPMENT

Complex Application

Usability

Goals

Simple Application

LEVEL 3

Function/Data Modeling

OOSE: Requirements Model

Detailed

UI

Design

Style

Guide

INSTALLATION

LEVEL 1

Unit/System Testing

OOSE: Test Model

Work

Reengin-

eering

Iterative

DUID

Evaluation

LEVEL 2

Installation

Conceptual

Model

Design

Screen

Design

Standards

Met

Usability

Goals?

NO

User

Feedback

Enhancements

CM

Mockups

SDS

Prototyping

YES

Style

Guide

All

Issues

Resolved?

Style

Guide

NO

Style

Guide

Iterative

CM

Evaluation

Iterative

SDS

Evaluation

YES

All

Functionality

Addressed?

YES

Eliminated

Major

Flaws?

Met

Usability

Goals?

NO

YES

NO

YES

NO

DONE!

Start Application Architecture

OOSE: Analysis Model

Start App. Design/Development

OOSE: Design Model/Imp. Model

Life-Cycle Models


Design model

Design Model

Requirements

Design

Build/Develop

Evaluate

Design Model


Requirements

Requirements

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

Requirements


Requirements1

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


Requirements2

Requirements

Determining Usability Requirements:

  • Task Analysis

  • User Analysis

  • Environment Analysis

Requirements


Requirements3

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


Requirements4

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


Requirements5

Requirements

Types of Task Analysis

  • Task Decomposition

  • Knowledge Based Analysis

  • Entity-Relationship Based Analysis

Requirements


Requirements6

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


Requirements7

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


Requirements8

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


Requirements9

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


Requirements10

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


Design model1

Design Model

Requirements

Design

User-centred design

Build/Develop

Evaluate

Design Model


User centred design

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


Why involve users

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


What is a user centred approach

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


Ethnographic observation

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


Ethnographic observation1

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


Participatory design

Participatory Design

User-Centred Design


Participatory design1

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


Participatory design2

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


Participatory design3

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


    Participatory design4

    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


    Participatory design5

    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


    Summary of lecture

    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


    Terms of reference

    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


  • Login