How & When do we apply Human Factors ideas?

The design cycle: Introducing design as an activity

What is design?

Some general points

• all artefacts are result of process of design
• often ideas about design are muddled in with notions derived from more specific practices of design methods
• good design can be marred by faulty fabrication but no amount of constructional skill can disguise poor design
• what is being designed influences the nature of the design process
  e.g. the dynamic nature of software systems complicates the process of design
  because you are designing a process therefore one needs to model and describe its behaviour as well structure and also the function it will perform.
• multiple descriptions and representations needed offer different views of the system

Objectives for design

• to produce a description of how a particular need is met, to produce a "blueprint"
• produce a solution to a problem
• produce a description of how a requirement can be met
• ultimate requirement is one of 'fitness for purpose'
• designs can be approximate or precise
• designs can indicate sequencing of activities in the eventual construction process
  e.g. specifying how to build a piece of furniture, specifying a house move

Some views of the design process

Design as a general process model

a design problem arises:

• postulate a solution
• build a model of the solution
• evaluate the model against the original requirement
• elaborate the model to produce a detailed specification of the solution (a form of "blueprint")

Design as problem solving

designer evaluates different options within a design space, considering trade-offs

• using a number of tools (e.g. design methods, design representations)
• using abstraction to consider critical features

A definition from an expert

J. Christopher Jones Design Methods: Seeds of Human Futures (1970)

"The fundamental problem is that designers are obliged to use current information to predict a future state that will not come about unless their predictions are correct. The final outcome of designing has to be assumed before the means of achieving it can be explored: the designers have to work backwards in time from an assumed effect upon the world to the beginning of a chain of events that will bring the effect about."

And it gets worse

"If, as is likely, the act of tracing out the intermediate steps exposes unforeseen difficulties or suggests better objectives, the pattern of the original problem may change so drastically that the designers are thrown back to square one" (Jones).

Contrast designing with scientific reasoning

The process of design is not linear

• involves
• iterations and backtracking
• revision of choices

Design is very different from analytical techniques that lie at root of scientific reasoning

Design as an ill structured problem (Herbert Simon, 1984)

Design as a 'wicked problem' (Rittel and Webber, 1984)

Properties of wicked problems

no single convergent solution

no definitive formulation

difficulties of specifying needs

specification and design hard to separate clearly

understanding the problem is bound up with the ideas that we have about solving it

no stopping rules

solutions to wicked problems are not true or false but good or bad

lack of stopping rules = lack of any certain criteria that can be used to establish when the solution to a problem has been found such that any further work will not be able to improve upon it. e.g. software: lack of any quality measures that can be used to establish that any one system is the 'best' one possible

therefore

life cycle models etc, where the task of specification is followed neatly by that of design is rarely a realistic description of actual practices

software designs usually come in shades of grey in that there are usually no right or wrong solutions or structures

every wicked problem can be considered to be a symptom of another problem. Resolving discrepancy or inconsistency in a design may pose another problem in its turn.

e.g. in writing a computer program a choice of data structure that helps with resolving one problem may well present an entirely new difficulty later.

E.g. designing real time systems:

it may be possible to organise the system so that it can produce a response to one type of event within some required interval but the way that this is achieved may place such constraints upon the operation of the system that it will then be unable to meet some other demand in an adequate time.

Models of design process

frameworks (for software development)

aim is to produce plans so that software production can proceed

idea is to influence organisation of software development

2 types of design process structure

(1) life cycle forms, e.g. 'software life cycle'

e.g. 'waterfall model' (Royce, 1970)

• sequential process
• each activity is self contained iteration
• tasks and techniques for each phase readily identified
• i.e. software production is divided into a sequence of phases which can be divided into sub-phases

pros

• strong management framework,
• setting of milestones,
• recording of progress,
• framework for development of documentation in stages

cons

• task support,
• job content,
• formalisation,
• power and influence,
• personnel politics

e.g.

* when design models become enshrined in procedures there is always a danger that such models may constrain creativity rather than support it

* rigidity of procedures

* problems with formalisation

* job content issues: division of tasks

* communication problems

* distance from users

* distance from requirements specification

view life-cycle models as descriptive frameworks rather than as prescriptive frameworks

(2) incremental forms

• develop system through creating a sequence of enhancements to a set of interim solutions
• prototyping, simulations, mock-ups (e.g. wizard-of-oz)
• ongoing user testing

e.g.

User centred design

Human centred design

pros

• technical experiment,
• easier involvement of end users in user-oriented evaluation tasks

cons

• management, validity and reliability
• hard to fit into traditional management structures
• adequacy of prototype hard to establish
• does not have a well defined development path

Questions to ask in the design process

Validation: are we building the right product?

needs analysis

Verification: are we building the product right?

test, evaluate, iterate, know your user