Embed Size (px)
Citation preview
This article was downloaded by: [Florida State University]On: 12 November 2014, At: 12:08Publisher: Taylor & FrancisInforma Ltd Registered in England and Wales Registered Number: 1072954 Registeredoffice: Mortimer House, 37-41 Mortimer Street, London W1T 3JH, UK
ErgonomicsPublication details, including instructions for authors andsubscription information:http://www.tandfonline.com/loi/terg20
How system designers think: a studyof design thinking in human factorsengineeringSotiris Papantonopoulos aa Department of Industrial Engineering and Management TokyoInstitute of Technology 2-12-1 Oh-okayama Meguro-ku, Tokyo152-8552 JapanPublished online: 09 Nov 2010.
To cite this article: Sotiris Papantonopoulos (2004) How system designers think: a studyof design thinking in human factors engineering, Ergonomics, 47:14, 1528-1548, DOI:10.1080/00140130412331290916
To link to this article: http://dx.doi.org/10.1080/00140130412331290916
PLEASE SCROLL DOWN FOR ARTICLE
Taylor & Francis makes every effort to ensure the accuracy of all the information (the“Content”) contained in the publications on our platform. However, Taylor & Francis,our agents, and our licensors make no representations or warranties whatsoever as tothe accuracy, completeness, or suitability for any purpose of the Content. Any opinionsand views expressed in this publication are the opinions and views of the authors,and are not the views of or endorsed by Taylor & Francis. The accuracy of the Contentshould not be relied upon and should be independently verified with primary sourcesof information. Taylor and Francis shall not be liable for any losses, actions, claims,proceedings, demands, costs, expenses, damages, and other liabilities whatsoeveror howsoever caused arising directly or indirectly in connection with, in relation to orarising out of the use of the Content.
This article may be used for research, teaching, and private study purposes. Anysubstantial or systematic reproduction, redistribution, reselling, loan, sub-licensing,systematic supply, or distribution in any form to anyone is expressly forbidden. Terms &Conditions of access and use can be found at http://www.tandfonline.com/page/terms-and-conditions
How system designers think: a study of design thinking in
human factors engineering
SOTIRIS PAPANTONOPOULOS*
Tokyo Institute of Technology Department of Industrial Engineering andManagement 2-12-1 Oh-okayama, Meguro-ku, Tokyo 152-8552, Japan
Keywords: System design; Design thinking; Interpretation;Requirements analysis; Design research; Ontological design.
The paper presents a descriptive study of design thinking in human factorsengineering. The objective of the study is to analyse the role of interpretation indesign thinking and the role of design practice in guiding interpretation. Thestudy involved 10 system designers undertaking the allocation of cognitivefunctions in three production planning and control task scenarios. Allocationdecisions were recorded and verbal protocols of the design process were collectedto elicit the subjects’ thought processes. Verbal protocol analysis showed thatsubjects carried out the design of cognitive task allocation as a problem ofapplying a selected automation technology from their initial design deliberations.This design strategy stands in contrast to the predominant view of system designthat stipulates that user requirements should be thoroughly analysed prior tomaking any decisions about technology. Theoretical frameworks from designresearch and ontological design showed that the system design process may bebetter understood by recognizing the role of design hypotheses in system design,as well as the diverse interactions between interpretation and practice, means andends, and design practice and the designer’s pre-understanding which shape thedesign process. Ways to balance the bias exerted on the design process werediscussed.
1. Design thinking in system design as an area of inquiry
1.1. Motivation and scope of the studyThe motivation for this paper came from observations on the system design processwhile conducting an experimental study on task allocation.The study involved system designers performing the allocation of cognitive tasks
in three emergency handling production planning and control tasks in the design offlexible manufacturing. While following the design process as it unfolded during theexperiment, it was observed that the subjects’ allocation decisions were based on, orwere strongly influenced by, their mental models of the computer system and theirparadigmatic beliefs regarding the human role in systems and automation. In thesubsequent analysis of the subjects’ verbal protocols of the design process, collectedfor that purpose during the study, it became evident that allocation decisions werealso strongly influenced by the subjects’ design strategies and, in general, by theirdesign practices.
*Author for correspondence. Makri 5, Athens 11742, Greece. e-mail: [email protected]
Ergonomics ISSN 0014-0139 print/ISSN 1366-5847 online # 2004 Taylor & Francis Ltdhttp://www.tandf.co.uk/journals
DOI: 10.1080/00140130412331290916
ERGONOMICS, NOVEMBER, 2004, VOL. 47, NO. 14, 1528 – 1548
Dow
nloa
ded
by [
Flor
ida
Stat
e U
nive
rsity
] at
12:
08 1
2 N
ovem
ber
2014
These observations seemed to contradict the emphasis traditional human factorsengineering places on decision parameters endogenous to the tasks to be allocated(task characteristics, human and computer abilities and limitations in performingthese tasks, etc.) as the basis for allocating tasks between human and computer. Theobservations instead accentuated the role of interpretation in design thinking and therole of design practice in guiding interpretation. In other words, the observationsrecognized the role of the system design practitioner and design practice in the designof cognitive task allocation, factors exogenous to the tasks themselves.1 Thisprompted the study of how system designers think and work. The paper is asystematization of, and commentary on, the findings from the study.
1.2. Theoretical backgroundHuman factors engineering is traditionally predicated on the human–machine systembeing the unit of analysis and on individuals (single users) engaged in tasks. Recentextensions to the theory and practice of human factors engineering tend toemphasize the work practices that shape the human interaction with technologicalartefacts as they become established over time and the organizational context inwhich the interaction occurs.
Despite this broadening of conceptual scope, human factors engineeringapproaches system design as a highly analytical and normative process. Threeobservations are made here.
First, the highly analytical and normative orientation of system design in humanfactors engineering shall be viewed as part of a ‘rationalistic orientation to systemdesign’ (Winograd and Flores 1986, Coyne 1995) and can be depicted as a series ofsteps:
(1) Analyse a system in terms of identifiable objects with well-defined properties.(2) Find general rules that apply to the system in terms of those objects and
properties.(3) Apply the rules logically to the system of concern, drawing logical
conclusions about what should be done (Winograd and Flores 1986: 14 – 15).
Second, conceptual frameworks usually do not offer methodological guidanceregarding ‘the process and the data collection methods that an analyst should adoptin eliciting the knowledge required to perform the analysis’ (Vicente 1999: 35).Furthermore, this lack of methodological guidance is seldom acknowledged by theresearchers and theorists of conceptual frameworks (for a notable exception, seeVicente 1999). It is expected instead that the systematic application of conceptualframeworks and resulting analysis of the system of concern will lead to logicalconclusions about what should be done.
Third, methodological guidance is normative, prescribing what the systemdesigner shall do while failing to address the cognitive, professional, andorganizational factors that shape the actual practice of system design.
There are obvious questions concerning how system designers analyse a systeminto correspondence with systematic representations of objects and properties, howthey come to know general rules, etc. In much of the rationalistic orientation tosystem design, however, these questions are deferred in favour of emphasizing theformulation of systematic rules that can be used to draw logical conclusions(Winograd and Flores 1986).
1529How system designers think
Dow
nloa
ded
by [
Flor
ida
Stat
e U
nive
rsity
] at
12:
08 1
2 N
ovem
ber
2014
An alternative orientation to system design recognizes system design as situatedaction (Suchman 1987). This orientation fosters an understanding of the actualpractice of system design as an emergent and contingent human activity, an activitythat grows directly out of the particularities of a given situation and is characterizedas being commutative, opportunistic, and chaotic (Archer 1979, Fuld 1993, Card1996, Vicente 1999). In this respect, this orientation to system design employs abroader concept of rationality that is derived from experience and practisedunderstanding (‘the hidden rationality of practice’, Stolterman 1991).We therefore need to develop a better understanding of the cognitive and
methodological aspects of the actual practice of system design, including bothanalytical and non-analytical modes of design thinking. Equally well we need todevelop a better understanding of the actual practice of system design in itsprofessional, organizational, and social dimensions. This broadening of the scope ofhuman factors engineering has been emphasized more by researchers andpractitioners in human–computer interaction (Winograd and Flores 1986, Carrollet al. 1991, Kapor 1996, Winograd 1996) who noted that ‘design is a process with awell-established practice that can only be impacted if it is understood in intimatedetail’ (Carroll et al. 1991: 74). In a similar vein, Fuld (1993, 2000: 229) advocatedthat ‘it is necessary to embrace the unmanageable pluralism of the wicked designproblem and to discard the hope of strong theoretical consistency in the designprocess’.An initial approach to the understanding of design thinking in system design is
developed by treating the designer as a user and design as a work activity, in Section1.3. A second theoretical framework is the theory of ontological design (Winogradand Flores 1986), the major tenets of which are outlined in Section 1.4.
1.3. Theoretical frameworks: design as a work activity/design researchOne way to study system design in actual practice is by treating system design as awork activity and by observing the design process and collecting empirical designdata by the same methods used by human factors engineering to collect behaviouraldata of non-design work activities. To this end, the system designer shall beconsidered as the user of a design practice.This metaphor becomes stronger if the definition of technology is extended to
include techniques, formulae, know-how or expertise, or any organization ofknowledge for the achievement of practical purpose (McGinn 1990), where thedesign practices employed by the designer can be incorporated. This broaderdefinition of technology seems more appropriate to the human experience withtechnological artefacts as tools mediating the achievement of practical purpose andencompassing both material artefacts (e.g. a hand-tool) and non-material practices(e.g. a design method). Accordingly, system design may be viewed as a case of humaninteraction with technology (i.e. applying a design method) and may be studied asany other case of human interaction with technology, the study of which is theproper subject of human factors engineering.Furthermore, the study of the system design process as a work activity can also
benefit from similar design studies conducted by design research. Design research isthe multidisciplinary approach to understanding the design process across alldomains where designing is fundamental (engineering design, architectural design,product design, etc.). This includes how designers work and think, the establishmentof appropriate structures for the design process, the development and application of
1530 S. Papantonopoulos
Dow
nloa
ded
by [
Flor
ida
Stat
e U
nive
rsity
] at
12:
08 1
2 N
ovem
ber
2014
new design methods, techniques, and procedures, and reflection on the nature andextent of design knowledge and its application to design problems. Design researchstudies the work activities and professional practices of design practitioners,individual or collaborative, interpreting them as problem-solving activities. For agood introduction to design research see Cross (1984) or Cross et al. (1996).
1.4. Theoretical frameworks: ontological designThe theory of ontological design was introduced by Winograd and Flores (1986) as anew foundation for design. Their work draws heavily from the philosophicaltraditions of phenomenology, the philosophical examination of the foundations ofexperience and action, and hermeneutics, the philosophy of interpretation, asdeveloped by the philosophers E. Husserl, M. Heidegger, H.-G. Gadamer, and M.Merleau-Ponty, among others.
Ontological design examines how a designer perceives a system as a particularcomposition of objects and properties that comprise a certain representation of asystem. According to Winograd and Flores, things do not exist or bear propertiesindependent of interpretation. What a particular system is depends on interpreta-tion, the particular constitution of objects and properties comprising the systemarising through the designer’s concernful activity or orientation. The way in whichthe functional properties of a system are perceived by a designer very much dependsupon the designer’s goals and intentions. In general, objects in the environment existisolated from the background only in the mind of the person, and the properties theyare allocated depend on the person’s actual intentions. A stone may disappearunrecognized in the general scenery. It may be recognised as a stone, maybe ageologic specimen. It may even be considered an item suitable to scare away athreatening dog, or possibly a useful weight that prevents manuscript sheets frombeing blown away by the wind, all depending upon the needs or interests of a humansubject (Rasmussen 1986). A designer develops an orientation to the worlddepending on his/her immediate concerns, an orientation that organizes the worldand the system to be designed as part of a specific human project.
While guided towards concernful activity, a designer’s orientation also reflects ahorizon of pre-understanding that sets and restricts possibilities or options foraction. The horizon of pre-understanding itself is a product of previous acts ofinterpretations and concernful activities. Interpretation and therefore design dependson the designer’s orientation (intention) as well as the designer’s horizon (pre-understanding) in defining the ontology of system, namely the particularcomposition of objects and properties that comprise a certain representation ofthe system.
By examining how a designer interprets a design, the theory of ontological designunderlines the primacy of ontology in defining the interaction between the designerand the design problem. In this vein, design can be understood as the interaction ofthe ontology of the designer and the ontology of the user, created by the attempt ofthe designer to anticipate user/system requirements by mentally creating the possibleuses the system might be put into.
1.5. Organization of the paperThe paper is based on data derived from an experimental design study of cognitivetask allocation in Advanced Manufacturing Systems. The experimental design studywas initially conducted for the purpose of evaluating a decision model for cognitive
1531How system designers think
Dow
nloa
ded
by [
Flor
ida
Stat
e U
nive
rsity
] at
12:
08 1
2 N
ovem
ber
2014
task allocation, the Analytic Cognitive Task Allocation (Sharit 1997, Papantono-poulos and Salvendy 2004). The results and observations from the experimentaldesign study were further systematized in a comparative study where the decisionmodel was compared to cognitive task allocation in actual practice, i.e. performedwith no decision support but based on the designers’ acquired understanding andpractice (Papantonopoulos 2004).This paper instead is based entirely on those sessions of the experimental design
study that involved system designers conducting the design of cognitive taskallocation without any decision support (the control group in the experimentaldesign study). These sessions offer a case study of a system design in actual practice(subject to the limitations of being conducted in an experimental setting rather thanin situ) and were analysed towards an understanding of design thinking in systemdesign. The part of the experimental design study of interest is outlined in Section 2.The experimental results are reported in Section 2.2. An interpretation of the resultsby means of theoretical frameworks developed by design research and ontologicaldesign is offered in Section 3. A discussion of the implications and conclusions of thestudy follows in Section 4.
2. A study of design thinking
2.1. Experimental design2.1.1. Overview: The study of design thinking involved subjects performing thedesign of cognitive task allocation in three task scenarios in production planning andcontrol of an FMS cell. Subjects were asked to read an experimental manualcontaining a definition of cognitive task allocation, descriptions of the FMS cell(including the functions of the cell computer controller), the three task scenarios andrespective task strategies, and the experimental procedure. Subjects were then askedto allocate three functions (each selected from a different task scenario) by decidingwhether each function should be allocated to the human operator or be automated.The subjects’ allocation decisions were recorded; verbal protocols were also
collected to elicit the subjects’ thought processes.
2.1.2. Selection of tasks: Three tasks were selected representing a sample of thework content of the human supervisor of an FMS cell in production planning andcontrol. The selected tasks involved either the handling of scheduling contingenciesor the interpretation and implementation of higher order planning and controlobjectives. The experimental tasks were selected to contain elements favouringhuman allocation and elements favouring automation and, consequently, wereexpected to elicit weak preferences for either human or computer allocation.Task 1 involved diagnosing the cause of premature toolwear which was detected
at a machine of the FMS cell. Task 2 involved expediting a late part. Task 3involved selecting a dispatching rule appropriate to the dynamics of the schedulingprocess.
2.1.3. Selection of subjects: A total of 10 subjects were selected from the graduatestudents and junior faculty of the School of Industrial Engineering at PurdueUniversity. The criterion for the selection of each subject was a strong knowledge ofadvanced manufacturing technology and the associated production planning andcontrol technologies and techniques as evidenced by graduate coursework andresearch, industrial experience, or both.
1532 S. Papantonopoulos
Dow
nloa
ded
by [
Flor
ida
Stat
e U
nive
rsity
] at
12:
08 1
2 N
ovem
ber
2014
2.1.4. Experimental procedure: Subjects (Ss) performed the design of cognitive taskallocation by applying the definition of the process outlined in the experimentalmanual and without receiving any decision support. The experimental procedure foreach task scenario was as follows:
Step 1. Ss were asked to perform the experimental task mentally as surrogateusers by following the respective task strategy.Step 2. Ss were asked to analyse the requirements of the function to be allocatedand decide whether a function should be allocated to the human operator or beautomated.Step 3. Ss were requested to compare and rate human and computer performanceof the function on a ratio scale ranging from 9, indicating the highest preferencefor human allocation, to 1/9, expressing the highest preference for automation,with 1 at the centre of the scale indicating equal preference for the two alternatives(table 1).
2.2. Experimental results2.2.1. Allocation decisions: The allocation decisions formed mainly two separateclusters on the two ends of the scale (figure 1). The larger cluster on the one end of thescale included ratings expressing strong or higher than strong preference forautomation (wij4 1/5); the smaller cluster on the other end of the scale includedratings expressing strong or higher than strong preference for human allocation(wij5 5). There was therefore no statistical basis for deriving the mean values of theallocation decisions for any task. However, the cluster of values expressing preferencefor automation was consistently much larger than that expressing preference forhuman allocation, thereby indicating an overall preference for automation.
Furthermore, Ss exhibited highly resolute preferences, for human allocation orautomation, despite the fact that the experimental tasks were selected so as to elicitweak preferences.
The intensities (magnitudes) of allocation decisions were calculated, defined by thedistance of allocation decisions from the centre of the scale and regardless of theirdirection of preference. For example, an allocation decision wij=5(expressing a strongpreference for human allocation, see table 1) shows an intensity of preference equal to
Table 1. Experimental scale. Adapted from Saaty (1980)
j + + + + + + + j + + + + + + + j1/9 1/7 1/5 1/3 1 3 5 7 9
Intensity of preference Definition
1 Equal preference btw. human allocation and automation3 Weak preference for human allocation5 Strong preference for human allocation7 Very strong preference for human allocation9 Highest preference for human allocation2, 4, 6, 8 Intermediate values between adjacent judgmentsReciprocals of the abovenumbers (fractional values) Indicate preference for automation
1533How system designers think
Dow
nloa
ded
by [
Flor
ida
Stat
e U
nive
rsity
] at
12:
08 1
2 N
ovem
ber
2014
Figure 1. Allocation decisions for Tasks 1, 2, and 3 on the experimental scale. Values greaterthan one indicate a preference for human control of the task; fractional values indicatepreference for automation. Adapted from Papantonopoulos and Salvendy (2004).
1534 S. Papantonopoulos
Dow
nloa
ded
by [
Flor
ida
Stat
e U
nive
rsity
] at
12:
08 1
2 N
ovem
ber
2014
4. An allocation decision wij=1/5 (strong preference for automation) shows also anequal intensity of preference equal to 4, being at an equal distance from the centre.
Allocation decisions exhibited statistically higher than strong intensities across allthree experimental tasks with mean intensities, jw.1j=5.0, jw.2j=5.2, jw.3j=5.5, forTask 1, 2, and 3 respectively (strong intensity of preference is equal to 4).
2.2.2. Design strategies: Verbal protocol analysis showed that Ss followed twomajor patterns. Given a task function, a small group of Ss further analysed thefunction of concern, identified the cognitive abilities involved in performing thefunction, selected suitable automation technologies and finally, compared humanand computer (H –C) abilities and limitations in performing of the function to beallocated and made a final allocation decision.
In most cases however the steps or phases of the design process were notdiscernible. Structuring the problem by further decomposing the function to beallocated, analysing the requirements involved, etc. was intertwined or preceded bythe choice of a suitable automation technology. In other words, most Ss performedcognitive task allocation as a problem of applying a certain technology selected forautomating the function to be allocated. For example, Subject 8 formulated thescheduling Task 2 by means of multi-attribute Decision Analysis in terms of anobjective function, utility, utility curves, minimisation of disutility, etc.
S08: (. . .) I would use some kind ofmulti-attribute utilitymodel inwhich somehowI have assessed utility functions which reflect the value of minimum set-upplus processing time and reliability and the value of prioritizing criteria forthe parts. So, I would have some overall utility function which combined theutilities used in prioritizing the parts and the utilities used for the machines.
(. . .)
How do we assess the overall utility of a bumped part? The overall utilityof a bumped part is how it meets the three criteria for prioritizing the partand how the machine it’s processed on meets the criteria for expediting thepart to be expedited. So the overall utility or disutility of a bumped part issome combined function of its utility with respect to the criteria forjudging the priority of a part and the utility of the machine that it isprocessed on. Now, you would ask how do I assess the different utilitiesfor those things and how I combine them into some overall measure ofutility. I think I would have to assess individual utility functions for eachof these criteria, you would have to present me with different levels oftime-to-retool and I’d say, if you have to compare two alternatives there, Ithink you should hold everything there constant but retooling timedifferent, let’s assess your value or utility function for that. And then let’sdo the same thing for reliability and fast processing time, OK? So, weassess these utility functions and then we have to aggregate them. That canbecome a very messy process, I am trying to discover this overall aggregateutility function. (Subject 8 on Task 2/Function 3)
The selection of a technology suitable for automating the experimental tasksshould be interpreted as the primary design choice. As the primary design choice, the
1535How system designers think
Dow
nloa
ded
by [
Flor
ida
Stat
e U
nive
rsity
] at
12:
08 1
2 N
ovem
ber
2014
choice of automation technology had the following implications for subsequentdesign choices. First, following the selection of automation technology, most Sstended to formulate the experimental tasks in terms of the selected technology,thereby reducing the scope of the task and rendering it suitable for automation whileexcluding aspects of the task not suitable for the selected technology. As a result ofthis reduction, subjects confounded the task (the goal) and the technology (themeans), formulating the task as a computer program. This design strategy cantherefore be characterized as technology-centred. Second, the formulation of thetask in terms of a computer program and in technical terms introduced a pro-automation bias in the system design process.The experimental results obtained deviated from expected patterns in two major
ways. First, allocation decisions tended to cluster on the two ends of the scale andexhibited statistically highly resolute preferences despite the fact that theexperimental tasks were selected so as to elicit weak preferences. Second, verbalprotocol analysis showed that Ss performed cognitive task allocation as a problem ofapplying a certain automation technology from their initial design deliberations.This design strategy stands in sharp contrast to the predominant view of systemdesign that stipulates that task/user/system requirements should be analysed in termsof a technology-independent conceptual framework prior to making any decisionsabout technology. An interpretation of the experimental results follows in the nextsection.
3. A design research/ontological design interpretation of the results
The ensuing discussion will attempt to interpret the results and observations of thestudy of design thinking summarised above by means of theoretical frameworksdeveloped by design research and ontological design. In particular, the discussionwill attempt to raise a number of issues important to the understanding of designthinking that are systematically overlooked by the rationalistic orientation to systemdesign.
3.1. Commutative nature of design practiceVerbal protocol analysis showed that most Ss were making assumptions aboutapplicable automation technologies as provisional design solutions prior to, orconcurrently with, task analysis. This observation is in agreement with the tenet thatdesign is commutative. Design problems are imperfectly understood problems asthey cannot be stated per se, ‘wicked problems’ in Rittel’s (Rittel and Weber 1973)phrase. Any partial solution generates ‘waves of consequences’ that interact amongthemselves and with other problems, changing the problem definition in irreversibleand unknown ways (Moran and Carroll 1996). Understanding the problem, theemerging requirements and foreseeable resources is part of the problem-solvingprocess. The designer therefore oscillates between requirement ideas and resourceideas, as s/he illuminates obscurity on both sides and reduces misfit among them.Archer (1979) claims that one of the features of design methods that disenchantpractising designers is their directionality and causality and separation of analysisand synthesis, all of which are perceived as being unnatural.The design problem of cognitive task allocation should therefore be considered
not as a directional process (cognitive task analysis, followed by cognitive taskallocation, followed by task integration) but rather as a multi-dimensional space ofmutually interacting, mutually informing subproblems. According to this formula-
1536 S. Papantonopoulos
Dow
nloa
ded
by [
Flor
ida
Stat
e U
nive
rsity
] at
12:
08 1
2 N
ovem
ber
2014
tion of problem-solving, lower-level considerations regarding the availability orrelative merit of the human resources or automation (e.g. operator competencies,organizational knowledge and expertise, suitable automation technologies) orhigher-level technology strategy goals (e.g. full automation) both affect how thetask is conceptualized and further analysed, how requirements are assessed, etc.,each time initiating a new wave of problem-solving activity. This was corroboratedby Fuld (1993: 21) who remarked that ‘it is the artifact [the system] that isengineered, and the development of the allocation is inseparable from extensivedetailing of the artifact’. In contrast to the well-established view in system designtheory that considers cognitive task analysis an input to cognitive task allocation,cognitive task analysis and cognitive task allocation shall be seen as mutuallyinteracting subproblems, undertaken jointly in the actual practice of system design.
This does not seem to be an easy point to settle, however.Traditional system design methods often clearly state that first of all one has to
perform a very careful analysis of the organization, the work situation, theinformation flow, etc., before entering the design of preliminary alternative solutions(De Marco 1979, Jeffrey and Lawrence 1984, Lucas 1985; see Stolterman 1991).Within this tradition, Vicente (1999) advocated that system designers should defermaking any assumptions about the technologies to be introduced in system designbefore work analysis and task analysis are completed. Vicente claimed that, if anyassumptions about technology (i.e. system interface and functionality) are madeduring task analysis, they will have to be re-evaluated during technology design ortask allocation, leading to a need to conduct task analysis again, under the revisedassumptions. This will lead to infinite regress. Vicente instead suggested that taskanalysis ought to be ‘device-independent’ and he developed a conceptual frameworkfor that purpose. Rasmussen (1986: 58) similarly proposed that ‘a decision tasknecessary to meet the control requirements is analysed in terms of a device-independent framework’.
On the other hand, Moran and Carroll (1996: 5) claimed that ‘[d]esigners arehistorically aware, they build on (i.e. borrow) other designs; designers cannot affordto start from scratch’. Assuming therefore that design is evolutionary, analysis isimbued with design assumptions from the onset and, as a result, device-independence is unattainable. Furthermore, evolutionary design is desirable forfostering reliability. Having equated evolutionary development to inherited success,Fuld (2000: 230) noted that ‘the importance of historical context for engineering ingeneral (. . .) is clear. This suggests the value of developing and retaining the bases orrationale for a design (. . .). Besides their eventual retrospective value, bases providean opportunity to project responsibility into future contexts for key considerations inthe original design’. Vicente too (1999), commenting on the actual practice of systemdesign, wrote that ‘the activities that analysts actually engage in while conducting ananalysis are very opportunistic, chaotic, and iterative’ (cf. Card 1996: 35). But thisseems to leave little ground for the orderly application of conceptual frameworksthat separate analysis and synthesis.
3.2. Conjecture-analysis model of the design processVerbal protocol analysis showed that provisional design solutions involved a choiceof a suitable automation technology. Given a cognitive task, most Ss initiallysearched for ways to automate the whole or parts of a task by suitable automationtechnologies and subsequently compared automation to human performance. The
1537How system designers think
Dow
nloa
ded
by [
Flor
ida
Stat
e U
nive
rsity
] at
12:
08 1
2 N
ovem
ber
2014
choice of a suitable automation technology can be considered the primary generator,i.e. a particular solution concept employed to develop a provisional solution to theproblem at hand. The role of the primary generator in design is well documented indesign research. Descriptive studies of design (Darke 1979, Guindon and Curtis1988, Lawson 1990) have shown that very early in the design process designersimpose a limited set of objectives or one particular solution concept as the ‘primarygenerator’ for developing a design conjecture (provisional solution). Designers relyon the formulation of the primary generator to reduce the variety of potentialsolutions to the as yet imperfectly understood problem to a small set of solutionsthat are cognitively manageable. Design conjectures (provisional solutions) are thentested against the requirements and constraints of the problem, thus contributing toa fuller understanding, or analysis, of the problem. This model of the design processis called the conjecture-analysis model. Similar observations on the use ofprovisional design solutions (‘first ideas’) very early in the system design processwere made in a study of design thinking in system design by Stolterman (1991). Theconjecture-analysis model is contrasted with the analysis-synthesis model outlinedpreviously.The development of design conjectures (provisional solutions) introduces a strong
orientation (bias) in the ensuing development of the design process by shaping thedesigners’ ontology. Yet, it is precisely by recognizing the role of conjectures indesign methodology that ways can be sought to balance this methodological bias,through the development of multiple solutions, by multiple representations of thedesign problem, etc.
3.3. Primacy of ontology in guiding interpretation. The role of pre-understandingSection 1.4 outlined the primacy of ontology in guiding the designer’s interpretationof the design problem. The solution concepts (primary generators) that designersemploy in developing conjectured solutions reveal their ontology, the particularcomposition of objects and properties comprising a certain interpretation andrepresentation of the system. As noted in Section 1.4, the ontology itself reflects botha horizon of pre-understanding that sets and restricts possibilities or options foraction and a pre-orientation that organizes the world and the system to be designedas part of a specific human project. In the case of the experimental study of thedesign of cognitive task allocation, Ss were graduate students and faculty ofIndustrial Engineering at Purdue University formally trained in production planningand control, simulation, operation research, or other sub-disciplines of IndustrialEngineering to formulate and solve scheduling problems. It is expected therefore thatthe subjects’ training helped shape their ontology and henceforth their selection ofthe specific automation technologies they employed as initial solution concepts(primary generators).For example, Ss trained in operation research viewed scheduling as an operation
research problem which could be programmed and solved by the computer. Subjectsindicated that all that seemed to be required was to formulate a scheduling task interms of an appropriate scheduling model or algorithm comprising entities such asorders, due dates, queues, penalties for lateness, etc. A due date in a schedulingproblem, when it is viewed as an engineering or operation research problem, isusually a constraint to be satisfied or otherwise a monetary penalty will be applied.As a result, these Ss confounded the scheduling task (the goal) and the schedulingmodel (the technology, the means), thereafter failing to make distinctions between
1538 S. Papantonopoulos
Dow
nloa
ded
by [
Flor
ida
Stat
e U
nive
rsity
] at
12:
08 1
2 N
ovem
ber
2014
the two. This ontology downgraded the human role in production scheduling (orreal-time rescheduling) as unnecessary or even, occasionally, as absurd. Consider, forexample, the way the expediting a late part (Task 2/Function 3) was conceptualisedby Subject 10:
S10: (. . .) I would say just do an optimization based on some cost criteria anduse the results of that optimization for your decision.
(. . .)
I think I’d allocate it to computer because it’d be easiest [inaudible] tocorrelate the inventory and the machines. (. . .) I mean you can calculateyour priorities based on some heuristics if you so desire, and then you canalso look at the due dates, you can consider a lot of things before makingdecisions. (. . .) I think you’d probably base most of your decisions oneither statistics or some optimizations you’d make and, if you couldn’tcome up with a decision that way, you try another set of rules basically.Plus after it found its decisions, it can update the part, update the systemalmost instantaneously after it makes the decision to put it in force.Whereas you’d need to have a lot of people running around making thesedecisions. Plus you can make them in the middle of the night too, insteadof [inaudible] the part. (Subject 10 on Task 2/Function 3)
A scheduling task can be formulated ontologically quite differently when viewed asa business problem involving the organization of production towards the attainmentof business objectives, i.e. the execution of orders made by customers. Customers maycome from outside the organization or may be another unit within the organization,e.g. the sales department. This ontology recognizes the need to understand not onlyhow a certain technology operates (such as a production unit or the associatedcomputer-aided production planning software) but what it does in a context ofbusiness and within the nexus of people, equipment, organization, and work practicesin which it is situated. A due date in a scheduling problem, when it is viewed as abusiness problem, is a commitment that arises as a result of human interaction withina business network of commitments and thus may be postponed, lifted, or furthernegotiated. Penalties for lateness are also negotiable although they may not be strictlymonetary but also intangible, e.g. customer dissatisfaction, loss of future business, etc.
A scheduling task can be formulated ontologically in another distinct, third way ifthe FMS cell operator or supervisor is given the discretionary power to makescheduling changes as appropriate to the operational and business environment.Recent approaches to system design provide operators the autonomy and support toengage in flexible, adaptive work (for a special treatment of this issue, see Vicente1999). Furthermore, FMS cells are also subject to operational disturbances thatquite frequently are not anticipated by system designers. For example, in a fieldstudy of FMS cells, Norros (1996) found that FMS cell operators had to cope withthree disturbances per hour. Vicente (1999, following Rasmussen and Goodstein1987) proposed giving operators the responsibility to tailor the technology (i.e.system interface and functionality) based on local information, knowledge, andexpertise through situated problem-solving. These ontologies of production planningand control, either as a business problem or as situated problem-solving, fail to
1539How system designers think
Dow
nloa
ded
by [
Flor
ida
Stat
e U
nive
rsity
] at
12:
08 1
2 N
ovem
ber
2014
emerge if scheduling is viewed as an operation research problem to be programmedand solved by the computer.By guiding the interpretation of the design problem and the development of
conjectured solutions early in the design process, the designer’s ontology introduces astrong orientation (bias) to system design. In the case of the experimental study ofcognitive task allocation, the technologies selected as provisional design solutionssuggested and obscured possibilities that shaped the Ss’ conceptualizations ofscheduling tasks. Most Ss tended to formulate the experimental tasks in terms of theselected automation technology thereby reducing the scope of each task and renderingit suitable for automation. Conversely, in a small number of instances, alternateconceptualizations tended to project those elements in the experimental tasks thatfavour human allocation. Ontological bias may help explain the highly resolutepreferences of allocation decisions. As shown in figure 1, in 18 instances out of a totalof 30 (3 tasks by 10 subjects) allocation decisions expressed strong or higher thanstrong preference for automation (wi,j4 1/5). In six instances, allocation decisionsexpressed strong or higher than strong preference for human allocation (wi,j5 5).Balanced ratings (1/54wi,j4 5) were received in the remaining six instances.Can this ontological bias be offset so that richer conceptualizations of system
design problems can be reached, and, if so, how?To resolve this problem one needs to examine the relationship between work and
technology, or between tasks and artefacts, in a system under development. Designsolutions initially emerge in response to perceived system requirements; by havingthe system prototyped and tested, new possibilities and new contexts of use emergethat redefine the task(s) for which the system was initially developed; in turn, theredefined tasks set new requirements for the development of new design solutions tosupport them. Carroll et al. (1991) called this dynamic and interactive relationshipbetween tasks and artefacts the ‘Task-Artifact Cycle’ (TAC). Iterating thereforethrough the ‘Task-Artifact Cycle’ numerous times will result in new contexts of useand new system requirements being revealed with each iteration. This will helpprogressively offset (or, at least, lessen) the ontological bias introduced initially bythe conjectured solutions. Carroll et al. (1991) suggested using TAC as a frameworkfor research and practice in HCI. According to Carroll et al. (1991), HCI practiceslike iterative prototyping and user testing and scenario-based design can beintegrated under the TAC framework to develop detailed descriptions of artefactsand their situations of use.Vicente (1999) however observed that the TAC framework suffers from device-
dependence because it is limited by the choice of prototypes being tested andsuggested that system design shall be based on Cognitive Work Analysis (CWA),work analysis and task analysis techniques that are device- as well as event-independent (independent of known work practices). This framework models workconstraints that are an inherent part of performing a task, i.e. independent of anyparticular technology. ‘The primary goal in doing so is to let work analysis suggesthow the device should be designed, rather than to make assumptions about thedevice before the analysis even begins’ (Vicente 1999: 106).This disagreement mirrors some of the major disputes in the Western
philosophical tradition over the role of pre-understanding in interpretation andcreativity.CWA aims to produce an objective interpretation of work and technology
requirements, untainted by the designer’s pre-understanding.
1540 S. Papantonopoulos
Dow
nloa
ded
by [
Flor
ida
Stat
e U
nive
rsity
] at
12:
08 1
2 N
ovem
ber
2014
If however we adopt the hermeneutic stance of interpretation underlyingontological design, we can see that interpretation depends on—and, in factnecessitates—a horizon of pre-understanding that we arrive at by nature of ourexistence. ‘[Pre-understanding] is not a condition in which the subject is led tointerpret the world falsely, but is the necessary condition of having a background forinterpretation’ (Winograd and Flores 1986: 31 – 32). By striving to develop anobjective interpretation untainted by the designer’s pre-understanding, CWAtherefore fails to take into consideration the implicit assumptions that designershave by the very way of their being.
Instead of striving for a means to getting away from our pre-understanding, weshould aim at making the beliefs and assumptions in our pre-understanding explicit(even though this cannot be fully accomplished) in order to understand the ways inwhich that pre-understanding affects our interpretation. In this vein, TAC shall beseen as a process of enhancing interpretation by making better understood howsystem design is being based on the co-evolution of tasks and artefacts. For example,the design of desktop publishing systems can be enhanced by examining how thedesigner’s pre-understanding of office systems is being shaped by the co-evolution ofoffice tasks and other office systems before them, like word processors. This is much inthe same way that, previously, word processors were shaped by office tasks of thattime and electric typewriters, or, initially, automobiles were shaped by the commutingneeds perceived at that time and by horse carriages. In this vein, the design ofscheduling systems is shaped by the system designers’ perception of automationtechnologies and production planning and control tasks (see also the discussion onthe formative role of technology and computer metaphors, Sections 3.4 and 3.5).
The way to offset the ontological bias of provisional design solutions is nottherefore to strive for an objective modelling of work practices (as it will unavoidablybe laden with implicit assumptions). Instead, the ontological bias of provisionaldesign solutions can be lessened by assisting system designers to gain a betterunderstanding of their own beliefs and implicit assumptions and, more importantly,an understanding gained by practice and experience. In this vein, the ‘Task-ArtifactCycle’ (and similar approaches that place emphasis on iterative prototyping andtesting) shall be seen as an instantiation of a hermeneutic circle of iterative learningby doing. The circularity of TAC and similar approaches is inevitable, asunderstanding can never be complete. As Heidegger (1962) says in ‘Being andTime’ (cf. Winograd and Flores 1986: 32), ‘If we see this circle as a vicious one andlook for ways to avoid it, even if we sense it as an inevitable imperfection, then theart of understanding has been misunderstood from the ground up’.
3.4. Formative role of automation technologiesAs discussed previously, most Ss tended to formulate the experimental tasks in termsof the selected automation technologies thereby reducing the scope of the task andconfounding the scheduling task (the goal) and the scheduling model (thetechnology, the means). This observation can be explained if one examines the roleof the selected automation technologies as mediating tools and, in general, theformative role of technology.
Technology was defined in Section 1.3 as the tools mediating human activities forthe achievement of practical purposes. Yet technology as mediating tools is no meremeans but has a formative impact on human activities themselves. According toActivity Theory (Nardi 1995), every conscious activity is always mediated by
1541How system designers think
Dow
nloa
ded
by [
Flor
ida
Stat
e U
nive
rsity
] at
12:
08 1
2 N
ovem
ber
2014
external tools as they extend psychomotor or cognitive processing beyond thebiological dimension. In a study of desktop publishing, for example, Black (1990)found that mediating tools systematically shaped graphic designers’ activities insignificant ways. With a pencil and paper, interaction was direct and the sketchesdrawn were limited only by imagination and manual dexterity, neither of which wasa problem with graphic designers. In contrast, with a computer-based system,graphic designs were strongly constrained by the commands available in thesoftware, frequently in unnatural and dysfunctional ways. Graphic designers oftenabandoned practices which were not directly supported by the computer butinvolved cumbersome ‘workaround activities’, i.e. concatenating together a set ofcommands in an improvised fashion. Furthermore, when they had at their disposalboth media, novice graphic designers spent much more time working with thecomputer-based medium, influenced by the ease with which they could producefinished-looking designs. As a result, novice graphic designers risked adoptingpractices that are easy rather than effective.Technologies as mediating tools have a formative impact on cognitive work
activities as well. Firstly, as in the case of graphic design, technologies shapecognitive work activities by the specific functionality they provide. Moreimportantly, however, technologies as mediating tools tend to impose onpractitioners recursive representations of the activities they mediate. By imposingrecursive representations of the mediated activities, technologies reveal certainontologies of the mediated activities while at the same time concealing others.‘Technology is no mere means. Technology is a way of revealing’ (Heidegger1977). Cognitive work activities therefore can be better understood only if weunderstand the tools that mediate them. For example, scheduling algorithmsshape our thinking about production scheduling by imposing certain representa-tions of the activity comprised by entities such as orders, due dates, queues,penalties for lateness, etc. In being applied recursively—and further legitimised asestablished professional practices—scheduling algorithms enframe system de-signers into particular ways of thinking about production scheduling. Thesetechnologies shall be better understood as revealing a certain ontology whileconcealing others. As noted, production scheduling can be formulated quitedifferently when viewed as a business problem or as situated problem-solving.This formative role of technology is overlooked by the rationalistic orientation tosystem design (Coyne 1995).
3.5. Formative role of computer metaphorsComputer metaphors have a formative impact on design thinking by shaping thedesigners’ conceptualizations of the tasks to be allocated, the operating context, andhuman cognition. The use of computer metaphors in the experimental study will bediscussed next, followed by a discussion of formative role of computer metaphors.
3.5.1. Computer metaphors of the experimental tasks and their operating con-text: The computer—information technology in its many guises—shall be seen inthe experimental study as acting as a metaphor for the experimental tasks and theiroperational context.Firstly, as shown in Section 2.2.2, most Ss tended to formulate the experimental
tasks in terms of the selected automation technologies. The computer can thereforebe understood here as acting as a metaphor for the experimental tasks.
1542 S. Papantonopoulos
Dow
nloa
ded
by [
Flor
ida
Stat
e U
nive
rsity
] at
12:
08 1
2 N
ovem
ber
2014
Furthermore, protocol analysis showed that Ss employed computer metaphors intheir conceptualizations of the operational context. Ss assumed that the FMS celland its operational context were, or could be designed to be fully automated. As aresult, activities which involved interfacing the experimental tasks with theiroperational context, e.g. assessing scheduling priorities or retrieving diagnostic data,were understood as being information processing or data interchange activities.Because the activities of interfacing with the operational context were understood asinformation-processing activities, the role of context-conditioned variability—andthe need for interpreting that variability—was easily obscured, as shown in thefollowing excerpts (Exp/r: Experimenter):
Exp/r: How would the computer assign utilities?
S06: OK. That’s a problem, because again the computer needs a supermodelin order to make the decisions about utilities. So, therefore, in a dynamicsituation the computer becomes less efficient, if you like, (. . .) because thefact we have us humans have to update the utility, we can either do thator we can give the computer some sort of higher knowledge of the systemand in some way deduce the need to change the utility functions. (Subject6 on Task 2/Function 3)
S01: Here again, we assumingly have all the numbers we need to compute thesethings and it’s a matter of putting in the time and effort to compute times,resources required, labor, whatever and come with a figure like say somany dollars to go from where the machine is right now, its current state,its set-up, its everything, to having the part completely finished. (. . .)
There’s got to be some metric that you can compute and you don’t haveto figure out what it is, it’s given, it’s an equation, and you have to plugin the numbers that are available into that equation and compute youranswer. (Subject 1 on Task 2/Function 3)
3.5.2. Computer metaphors of human cognition: More importantly, Ss employedcomputer metaphors in their conceptualizations of human cognition. In doing so,human cognitive performance and cognitive abilities and limitations were also under-stood as information processing activities. For example, a deductive reasoningprocess was understood as the application of the production (if-then) rules of a know-ledge base. Computer metaphors of human cognition permeate not only engineeringand technology—where they are expected nonetheless to be stronger—but con-temporary society at large. Bolter (1984) has argued that, in providing contemporarysociety with powerful metaphors for conceptualizing the human essence and humanbehaviour as a biological and cognitive entity, the computer is the defining technologyin our culture much as other technologies, such as the potter’s wheel in antiquity andthe mechanical clock in the eighteenth century, have been before.
3.5.3. Implication of the formative role of computer metaphors: As noted above,computer metaphors have a formative impact on design thinking by shaping thedesigners’ conceptualizations of the experimental tasks and their operating contextand human cognitive processes. The following implications can be made.
1543How system designers think
Dow
nloa
ded
by [
Flor
ida
Stat
e U
nive
rsity
] at
12:
08 1
2 N
ovem
ber
2014
Firstly, the use of the computer as a metaphor for the experimental tasks and theiroperational context further helped shape the Ss’ ontology in computer terms. Ssconfounded the tasks to be performed with the selected automation technologies,task analysis with engineering formulations. As noted in Section 2.2.2, theformulation of tasks in technical terms or technical language introduced a pro-automation bias in the system design process.In the same vein, the use of the computer as a metaphor for human cognition
concealed human traits that are not amenable to computerization, namely, learningand adaptability to context-conditioned variability. Learning and adaptability tocontext-conditioned variability are the principal human characteristics that advocatefor the presence of people in systems. In sum, in formulating the experimental tasksas computer programs while failing to identify human characteristics that advocatefor the presence of people in systems, Ss became biased toward machine allocation.This situation was also observed by Corbett et al. (1991: 51) who has remarked that‘thinking in terms of machines became the norm for the shaping of the work-technology relationship. (. . .), the machine usually proved to be superior in the workprocess. If one defines and organizes human abilities as mechanical, in so far ashumans are required to carry out robot-like tasks, then the ‘‘proof’’ that amechanical robot is superior to the ‘‘human robot’’ is usually close at hand’. In a likemanner, writing about the application of Fitts’ lists of abilities in task allocation,Hancock and Scallen (1996: 3 – 4) noted that ‘most lists use an information theoreticbased description, a product of the information processing era in which the list wasdeveloped. This inevitably leads to problems, since abilities are expressed in machinefavorable terms’.
3.6. Role of paradigmatic preferences concerning the human role in automated systemsDifferent assumptions—both manifested or tacit—concerning the nature of worklead to different forms of work analysis and task analysis and, in turn, to differentcognitive task allocation designs. If, on the one hand, system designers view peoplein systems as a source of error, then they tend to adopt instruction-based taskanalysis that leave very little for operators/users to do except to follow the resultingprocedure or work flow. Instruction-based tasks are more amenable to automation.If, on the other hand, system designers view people in systems as a source of learningand adaptability to context-conditioned variability, they may adopt task analysistechniques that provide workers more discretion to make decisions about how toperform a task (Vicente 1999). Paradigmatic preferences with respect to the humanrole in systems and automation play a major role in shaping allocation decisions.
4. Conclusions and implications
The preceding discussion of the design process of cognitive task allocation hashelped illustrate a number of aspects of design thinking in system design (Sections3.1 – 3.6) that are systematically overlooked by the rationalistic orientation to systemdesign. In summarising, these factors demonstrated two important aspects of designthinking in system design: the role of interpretation in design thinking and the role ofdesign practice in guiding interpretation.As stated in Section 1.2, human factors engineering involves a highly analytical
and normative orientation towards system design. According to the relevantformulation of the design process of cognitive task allocation, cognitive taskallocation is based on (and hence preceded by) task analysis and requirements
1544 S. Papantonopoulos
Dow
nloa
ded
by [
Flor
ida
Stat
e U
nive
rsity
] at
12:
08 1
2 N
ovem
ber
2014
analysis which are expected to identify the task/user requirements and the humanand computer abilities and limitations pertaining to these requirements. Conse-quently, provisional allocations are made to the controller, human or computer, bymatching the identified task/user requirements to the human and computer resourcesavailable for implementation. These provisional allocations are then integratedaccording to system-wide and contextual considerations. This formulation of thedesign process of cognitive task allocation retains a separation of (and thus fails toacknowledge the interaction) between analysis and synthesis, interpretation andpractice, means and ends (resources and requirements), current practice and the pre-understanding that is gained by practice over time. These interactions nonethelessshape the application and the outcome of the design process of cognitive taskallocation in very important ways.
The design process of cognitive task allocation may be better understood as amulti-dimensional space of mutually interacting, mutually informing subproblems.According to the conjecture-analysis model of the design process, system designersrely on the formulation of provisional solutions (design conjectures) to reduce thevariety of potential solutions to a small set of solutions which are cognitivelymanageable. Design conjectures are then tested against the emerging requirementsand resources that can be envisaged, thereby contributing to a fuller understandingof the design problem. This model of the design process acknowledges theunderstanding that can be gained by design practice, especially by practices likeiterative prototyping and user testing that involve fashioning and interacting withthe system under development under conditions of real use. On the other hand,design conjectures introduce a strong orientation (bias) in the ensuing developmentof the design process by shaping the designer’s ontology. Furthermore, the designer’sontology is influenced by a horizon of pre-understanding that sets and restrictspossibilities or options for action. This, as noted, is shaped by previous designs andthe co-evolution of the system being designed and its contexts of use; by theformative function of the tools, technologies, and conceptual models (representa-tions) the designer employs; by the formative role of computer metaphors; and bythe paradigmatic preferences designers hold regarding the human role in automatedsystems. The conjecture-analysis model therefore acknowledges the interactionbetween interpretation and practice, analysis and synthesis, means and ends, currentpractice and the historical co-evolution of the system of concern and its contexts ofuse.
At the same time, the conjecture-analysis model acknowledges the bias exerted onthe design process either by virtue of the diverse representations, beliefs and implicitassumptions in the designer’s pre-understanding or by the orientation given to designprocess by design conjectures. Rather than striving for an objective modelling ofsystem operation, this formulation of the design process aims to assist systemdesigners to gain a better understanding of the factors and mechanisms thatinfluence their practice and, more importantly, the explicit and tacit understandingthat can be gained by design practice itself.
It is precisely by identifying the sources and mechanisms of bias exerted on the designprocess that ways to balance their effect can be sought effectively.
It was shown, for example, that iterating through the ‘Task-Artifact Cycle’numerous times can help progressively offset (or, at least, lessen) the ontological biasintroduced by design conjectures by having new contexts of use and new systemrequirements revealed with each iteration. The ‘Task-Artifact Cycle’ can help extend
1545How system designers think
Dow
nloa
ded
by [
Flor
ida
Stat
e U
nive
rsity
] at
12:
08 1
2 N
ovem
ber
2014
our understanding of system design by showing the role that emulation of existingsystems and the co-evolution of tasks and artefacts play in system design. Forexample, the design of desktop publishing systems can be enhanced by showing howsuch systems are based on the emulation of existing office automation systems likeword processors and their contexts of use. Furthermore, Carroll et al. (1991: 83)suggested that the ‘Task-Artifact Cycle’ can help develop taxonomies of task andartefact domains that can help ‘articulate relationships among human activities sothat, . . ., we can anticipate how an understanding of human tasks and artifacts canbe generalized and extended’. In this case, a task formulation developed from oneapplication domain can be generalized and extended to related applications domains.Advances in ship navigation, for example, based on a training programme for bridgecrews which facilitate the interchange and management of task-relevant information,can help inform the design of monitoring tasks in aviation or process control.Likewise, the bias exerted by the diverse problem representations, beliefs, or
implicit assumptions can be counter-balanced by simultaneously developing multiplerepresentations and multiple solutions of the design problem as this providesmultiple perspectives in design. Multiple perspectives in all design work is a basictenet of design research (Cross 1984, Moran and Carroll 1996). Multiplerepresentations may serve to disclose the distinctive ontologies of a system, leadingto different ontological formulations of the design problem. It was shown, forexample, that a scheduling task can be formulated ontologically quite differentlywhen viewed as an operation research problem, a business problem, or situatedproblem-solving. In another example, it was also shown in the experimental studythat most Ss tended to formulate the experimental tasks in technical terms, i.e. as ifthe task were fully automated. To balance the ontological bias of this representation,Bohnhoff et al. (1992) suggested that an alternative representation can be developedin parallel, fostering a description of the problem and employing concepts wheretasks are performed by people. Bohnhoff and Henning (1990) call this approach theDual Design Approach indicating that ‘both the technology-based design and theworking-process design should be used in parallel to obtain an optimum’.Multiple solutions pursued concurrently also may help system designers reduce the
bias which comes from generating a single solution. Theoretical developments in set-based concurrent engineering have recently advanced the concurrent development ofmultiple solutions (Ward et al. 1995). Set-based concurrent engineering achieves thebetter mapping of the design space, the early exploration of design tradeoffs, and theeffective communication by communicating sets of design possibilities rather than asingle design possibility that accompany the iterative elaboration of a single bestsolution. Empirical findings suggest that set-based concurrent engineering improvesproduct development performance despite the additional time and cost of developingmultiple solutions (Sobek et al. 1999). Nevertheless the benefits of multiple solutionsand representations have to be continuously weighted against the cost for theirdevelopment until a satisfactory solution is reached.The practice of concurrently generating multiple representations and multiple
solutions leads to the view of system design as a concurrent and collaborative exercisepractised by cross-functional design teams (Wheelwright andClark 1992). This view ofsystem design as a concurrent and collaborative exercise emphasizes the organiza-tional aspects of system design (see definition in Section 1.2). The organizationalaspects of system design were not elaborated upon in the paper as the study of designthinking involved system designers working independently. They nonetheless need to
1546 S. Papantonopoulos
Dow
nloa
ded
by [
Flor
ida
Stat
e U
nive
rsity
] at
12:
08 1
2 N
ovem
ber
2014
be studied in conjunction with the methodological (design thinking) aspects raised inthe paper if a more informed understanding of system design is to be reached.
Notes
1. Organisational factors are another category of exogenous factors to the tasksthemselves that influence the design of task allocation.
ReferencesARCHER, B. 1979, Design as a discipline, Design Studies, 1(1), 17 – 20.BLACK, A. 1990, Visible planning on paper and on screen: the impact of working medium on
decision-making by novice graphic designers, Behaviour and Information Technology,9(4), 283 – 297.
BOHNHOFF, A. and HENNING, K. 1990, referenced in W. Wobbe 1990, AnthropocentricProduction Systems. Why Are They a Strategic Issue for Europe? (Luxembourg: Officefor Official Publications of the European Communities).
BOHNHOFF, A., BRANDT, D. and HENNING, K. 1992, The dual design approach as a tool for theinterdisciplinary discussion of human-centered systems, International Journal of HumanFactors in Manufacturing, 2, 289 – 301.
BOLTER, J. D. 1984, Turing’s Man (Chapel Hill, NC: The University of North Carolina Press).CARD, S. K. 1996, Pioneers and settlers: methods used in successful user interface design, in M.
Rudisill, C. Lewis, P. G. Polson and T. D. McKay (eds), Human-Computer InterfaceDesign: Success Stories, Emerging Methods, and Real-World Context (San Francisco:Morgan-Kaufmann), 122 – 169.
CARROLL, J. M., KELLOGG, W. A. and ROSSON, M. B. 1991, The task-artifact cycle, in J. M.Carroll (ed), Designing Interaction: Psychology at the Human-Computer Interface.(Cambridge: Cambridge University Press), 74 – 102.
CORBETT, J. M., RASMUSSEN, L. B. and RAUNER, F. 1991, Crossing the Border: The Social andEngineering Design of Computer Integrated Manufacturing Systems (London: Springer-Verlag).
COYNE, R. 1995, Designing Information Technology in the Postmodern Age: From Method toMetaphor (Cambridge, MA: MIT Press).
CROSS, N. 1984 (ed), Developments in Design Methodology. (New York: Wiley).CROSS, N., CHRISTIAANS, H. and DORST, K. (eds), 1996, Analysing Design Activity. (Chichester,
UK: Wiley).DARKE, J. 1979, The primary generator and the design process, Design Studies, 1(1), 36 – 44.DE GREENE, K. B. 1990, Contextual aspects of human factors: the case for paradigm shift,
Human Factors Society Bulletin, 33(9), 1 – 3.DE MARCO, T. 1979, Structured Analysis and System Specification. (Englewood Cliffs, NJ:
Prentice-Hall).FULD, R. B. 1993, The fiction of function allocation, Ergonomics in Design, 1, 20 – 24.FULD, R. B. 2000, The fiction of function allocation, revisited, International Journal of Human-
Computer Studies, 52, 217 – 233.GUINDON, R. and CURTIS, B. 1988, Control of cognitive processes during software design: what
tools are needed? Proceedings of ACM CHI’88 Conference on Human Factors incomputing Systems (New York: ACM Press), 263 – 268.
HANCOCK, P. A. and SCALLEN, S. F. 1996, The future of function allocation, Ergonomics inDesign, 4, 24 – 29.
HEIDEGGER, M. 1962, Being and Time (London: SCM Press).HEIDEGGER, M. 1977, The Question Concerning Technology and Other Essays (New York:
Harper & Row).JEFFREY, D. R. and LAWRENCE, M. J., 1984, Systems Analysis and Design (Brunswick, Victoria:
Prentice-Hall of Australia).KAPOR, M. 1996, A software design manifesto: time for a change. Dr. Dobb’s Journal 172
(January 1991), 62 – 68, reprinted in T. Winograd (ed), Bringing Design to Software(New York: Addison-Wesley), 2 – 9.
1547How system designers think
Dow
nloa
ded
by [
Flor
ida
Stat
e U
nive
rsity
] at
12:
08 1
2 N
ovem
ber
2014
LAWSON, B. 1990, How Designers Think: The Design Process Demystified (Cambridge:Cambridge University Press).
LUCAS, H. C. 1985, The Analysis, Design and Implementation of Information Systems (NewYork: McGraw-Hill).
MCGINN, R. E. 1990, What is technology? in L. Hickman (ed), Technology as a Human Affair(New York: McGraw-Hill), 1 – 9.
MORAN, T. P. and CARROLL, J. M. 1996, Overview of design rationale, in T. P. Moran and J. M.Carroll (eds), Design Rationale: Concepts, Techniques, and Use (Mahwah, NJ: LawrenceErlbaum Associates), 1 – 19.
NARDI, B. A. 1995, Studying context: a comparison of activity theory, situated action models,and distributed cognition, in B. A. Nardi (ed), Context and Consciousness: ActivityTheory and Human-Computer Interaction (Cambridge, MA: The MIT Press), 69 – 102.
NORROS, L. 1996, System disturbances as springboard for development of operator’s expertise,in Y. Engestrom and D. Middleton (eds), Cognition and Communication at Work(Cambridge: Cambridge University Press), 159 – 176.
PAPANTONOPOULOS, S. 2004, System design in normative and actual practice: a comparativestudy of cognitive task allocation in Advanced Manufacturing Systems, Human Factorsand Ergonomics in Manufacturing, 14(2), 181 – 196.
PAPANTONOPOULOS, S. and SALVENDY, G. 2004, Analytic Cognitive Task Allocation: A decisionmodel for cognitive task allocation, Theoretical Issues in Ergonomics Science, in press.
RASMUSSEN, J. 1986, Information Processing and Human-Machine Interaction (New York:Elsevier).
RASMUSSEN, J. and GOODSTEIN, L. P. 1987, Design support in supervisory control of high-riskindustrial systems, Automatica, 23, 663 – 671.
RITTEL, H. and WEBER, M. 1973, Dilemmas in a general theory of planning. Policy Science, 4,155 – 169.
SAATY, T. L. 1980, The Analytic Hierarchy Process (New York: McGraw-Hill).SHARIT, J. 1997, Allocation of functions, in G. Salvendy (ed),Handbook of Human Factors, 2nd
edn. (New York: Wiley), 301 – 339.SOBEK II, D. K., WARD, A. C. and LIKER, J. K. (1999), Toyota’s principles of set-based
concurrent engineering, Sloan Management Review, 40(2), 67 – 83.STOLTERMAN, E. 1991, How system designers think about design and methods, Scandinavian
Journal of Information Systems, 3, 137 – 150.SUCHMAN, L. 1987, Plans and Situated Actions (Cambridge: Cambridge University Press).VICENTE, K. J. 1999, Cognitive Work Analysis: Toward Safe, Productive, and Healthy
Computer-Based Work (Mahwah, NJ: Lawrence Erlbaum).WARD, A., LIKER, J. K., CRISTIANO, J. J. and SOBEK II, D. K. 1995, The second Toyota paradox:
How delaying decisions can make better cars faster, Sloan Management Review, 36(3),43 – 61.
WHEELWRIGHT, S. C. and CLARK, K. B. 1992, Revolutionizing Product Development (New York:The Free Press).
WINOGRAD, T. 1996 (ed), Bringing Design to Software (New York: Addison-Wesley).WINOGRAD, T. and FLORES, F. 1986, Understanding Computers and Cognition (Reading, MA:
Addison-Wesley).
1548 S. Papantonopoulos
Dow
nloa
ded
by [
Flor
ida
Stat
e U
nive
rsity
] at
12:
08 1
2 N
ovem
ber
2014
