HCI: Whose Problem Is IT Anyway?

advertisement
HCI: Whose Problem Is IT Anyway?
R. N. Proctera and R. A. Williamsb
a
b
Department of Computer Science, Edinburgh University, Scotland, EH9 3JZ
Research Centre for Social Sciences, Edinburgh University, Scotland, EH8 9JU
Abstract
This paper reviews the current state of HCI. We argue that HCI lacks a sucient understanding of the issues that eect the usability both of computer systems, and of HCI
practices in real situations of system design and implementation. In this paper, we explore
these issues from the perspective of `problem ownership'. Internally, various constituencies
of expertise compete to dene and address the fundamental problems; externally, there is
uncertainty and ambiguity as to the identity of the `user' that the HCI community claims
it is attempting to serve.
Keyword Codes: H.5.2; D.2.2; D.2.9
Keywords: User Interfaces; Software Engineering, Tools and Techniques; Software Engineering, Management
1. INTRODUCTION
The current state of HCI suggests an urgent need for the HCI community reassess its
goals, internal composition, and relationship with the `user'. We address these issues
from the perspective of `problem ownership', which we believe is central to understanding
the scope and future prospects of HCI.
Internally, questions of problem ownership are apparent in the claims advanced by
competing constituencies of expertise to dene and address the fundamental problems.
The scope of HCI's problem denitions have become broadened as the character and goals
of IT applications have developed; as perceptions have shifted about the causes of the gulf
between expectations and experience of IT; and as a wider range of expertise has been
brought to bear. This raises dilemmas for the HCI community's intellectual programme
regarding the knowledge claims it can articulate, and the respective contributions of
dierent bodies of knowledge germane to understanding HCI. Progress in constructing
a synthesis has been slow, and research often seems more driven by fashion than by a
coherent vision of the issues.
The notion of problem ownership is also relevant to exploring the diculties apparent
in the HCI community's conceptualisation of, and relationship with, the `user' it is trying
to serve. This is especially evident when HCI practice is placed within an organisational
context. Is the user the `end user', the person who directly interacts with the computer,
or the `client', the person who commissions the system? There is insucient acknowledgement of the complexities of organisational life, and that the requirements of various
interested parties might conict. The HCI community seems unprepared to grapple with
the realities of the workplace, and organisational politics [1]. A topical example of the
consequences can be seen in the failure of computer-supported cooperative work tools to
transfer successfully from the research laboratory into commercial environments [1, 2].
We argue that HCI practice needs to pay greater attention to organisational theory in
general, and to concepts of power in particular.
2. HCI AS THEORY
The HCI community has always sought to portray its inter-disciplinary character as a
source of strength [3], but instead of being enriched by the emergence of a coherent and
convincing synthesis of concepts, the community has become increasingly split. Rather
than entering into a protable and complementary dialogue, ergonomics, psychology, cognitive science (`mainstream' HCI) on the one hand, and the more sociological approaches
on the other, now vie for ownership of the problem | HCI is disputed territory.
2.1. Evolution of the Discipline
HCI's inter-disciplinary character is an inheritance of its rapid development; the changing
nature of computer applications, and of the user population, have forced a continual
reassessment of priorities [4]. The focus of attention, and the denition of the `HCI
problem', has gradually shifted from the individual user, to the user as a member of a
group, working within an organisational setting. From its roots in physical and perceptual
ergonomics, HCI has been subsequently claimed rst by cognitive science | and most
recently | by the sociology of work and organisations. These disciplines compete for
the supremacy of their own particular problem domains, denitions and solutions; a key
question is whether and how these dierent perspectives can be integrated.
The contribution of psychology to HCI theory remains mired in the low level mechanics
of human performance. Carroll [5] is dismissive even of this contribution; information
processing psychology he says, has had \ no discernible impact on design practice." The
debate between Newell and Card [6], and Carroll and Campbell [7], as to the prospects
(and desirability) of an HCI dominated and driven by a `hard' science base of psychological
theory, has been overtaken by events. The focus of concern in HCI has been shifting
progressively into realms and time scales of human activity which are beyond the remit
of psychological theory. What needs to be debated now is not the relation of HCI theory
to design, so much as the relationship of design to the circumstances of its practice [8].
With few exceptions, reviews of the development of HCI convey little sense of the
continuity of computer development and application with earlier forms of information
and manufacturing technologies, and with the history of innovation in general. As a consequence, HCI's own emergence out of ergonomics, and the latter's own roots in Taylorism,
is generally overlooked. These roots brought with them an approach that was based on the
:::
formal representation of certain physical aspects of the work process (e.g. measurement of
worker movements, response times etc.), which in turn enabled the construction of standards for design of certain elements of the work environment. Formal representation has
had important advantages; it has given HCI a `scientic' approach, and allowed the development of `universal' solutions | that can then be applied in a wide range of contexts
without reference to particular users, work processes and organisations. The `success' of
this approach is reected in the detailed prescriptions available for the physical design
and ergonomics of interface hardware.
Experimental Psychology extended its remit to the elementary cognitive issues of
interface design (where the Taylorist legacy is clearly evident in the emphasis of techniques
such as GOMS on timing and optimum performance as the main criteria for behaviour
and design). In this guise, human factors arguably had a certain coherence | a welldelineated problem area, grounded in empirical science. But there are limits to how far
this approach can be extended. For example, it is impossible to establish comparable
standard criteria for a satisfying and well-designed job. These can only be dened in
relation to particular organisations and groups of workers. Here, social psychology has
deployed its methodological strengths | for example in relating elements of task design
to indices of job satisfaction. The value of such detailed empirical approaches may be
reduced, however, by uncertainties about the extent to which ndings can be generalised
to other contexts. In particular, social science suggests that people's evaluation of their
work and changes to it are strongly inuenced by the broader context, including the
`politics' of the workplace.
2.2. Evolution of the Domain
The eclectic way in which the term `usability' is now employed in the literature implies
a growing acceptance within the HCI community of the need to be concerned with the
totality of the design problem. It has become generally recognised that it is hard to
separate interface design from the broader aspects of systems design and functionality
[9]. Complex areas of social behaviour must be addressed, but the inherited tools and
approaches are problematic in their ability to handle such issues. Human behaviour in
organisations is complex and subject to a broad range of inuences, is often poorly dened,
hard to predict, and highly contingent. As such it is impossible to capture and represent
human social behaviour formally by the kinds of quantitative methods of mainstream HCI.
It arises in interaction with others | and cannot be derived simply by scaling up from
individual responses. Behaviour within organisations is characterised by the existence of
diverging and conicting interpretations by dierent individuals and groups. Criteria for
the social organisation of work are thus contested and contingent on particular groups and
contexts, and as a result, it is no longer possible to dene universal standards. Against
this context, HCI practitioners need to examine their role in the process of change in
organisations | who owns the HCI problem | is it the organisation, top management
or the variety of functional groups within the organisation? And how do HCI specialists
respond to institutionalised power dierentials between groups? As we shall see, HCI and
related approaches have tended to try to sidestep these issues by recourse to a normative
pluralist position. It is less clear, however, how conicts are handled in practice.
The diculties of developing an adequate understanding of organisations have been
exacerbated by the changing nature of computer applications. Early computer systems
were frequently concerned with the automation of standard organisational tasks (such
as book-keeping) which could readily be appropriated (e.g. by conventional work study
techniques), and reduced to an algorithm. The technology has become more elaborate,
however, and has taken over an increasing range of functions within (and between) organisations. For business users, one of the major challenges now lies in the development of
`integrated' systems | that allow information to be shared across organisations, and used
in new ways [10]. Systems must be seen as `organisational technologies' [11], directed at
improving the overall performance of the rm, rather than specic tasks. Hence design
must be situated within an analysis of organisational processes.
Mainstream HCI is ill-equipped to deal with the complex terrain of the social organisation of work. The search for `objective', generally-applicable design solutions comes
into conict with the existence of diverse perceptions, expectations and responses within
the organisation. Other disciplines | notably industrial sociology and organisational behaviour, which emphasise structural divisions within the organisation and conicts and
cleavages between dierent groups | possess a range of concepts for analysing such collective phenomena. These disciplines take as their central concerns the division of labour
and control within the organisation. They oer a rich account of organisational life |
showing the need to go beyond the unitary formal account of the organisation, its objectives, culture and practices and to examine the diversity of local cultures, goals and actions
of groups. Control is contested, and activities are negotiated within the organisation |
through complex political processes including the articulation and accommodation of sectional interests. These frameworks seek to identify generalised features of organisational
behaviour, while at the same time pointing to the complexity of organisational responses
| a complexity that can be described qualitatively, but which can not readily be quantitatively modelled with sucient simplicity and predictability to determine appropriate
design responses. In recognising the complexity of organisational behaviour, sociology and
organisational studies have moved away from seeking simple correlations (e.g. between
structure and performance) that could be used to create `cook-book' approaches to success. Instead recent work has stressed the need for organisations to develop processes for
the management of change that are appropriate to their particular context and traditions
[12].
For the most part, sociology has not sought to climb on board the HCI bandwagon; it
has tended to ght shy of adopting a prescriptive approach, particularly at the detailed
micro-level of the organisation and jobs | a level with which systems design must grapple.
Two closely related sociological disciplines, socio-technical systems | and more recently
| ethnography have sought to ll the vacuum, and are gaining currency within the HCI
community.
3. HCI AS PRACTICE
In this section we review some of the problems in applying particular approaches to HCI:
the mainstream scientic model of HCI as design (of tasks and artifacts), ethnographic
approaches, socio-technical systems design, participative design and industrial sociological
perspectives. Each involves profound diculties in terms of the utility of the information
they generate for designers; the applicability of their techniques in practical systems
design; and their ability to deal with diversity of requirements and perspectives of dierent
user groups within the organisation.
3.1. HCI as the Science of Design
The benets that HCI practice derives from its science base continues to fall below expectations. As Carroll has remarked, practice has generally outpaced theory [5]. It might
be argued that psychology's contribution to HCI practice is at least evident in the profusion of design guidelines. For all their apparent scientic credentials, however, far too
many guidelines seem to be little more than common sense dressed up as psychological
theory [13]. When closely examined, even apparently simple guidelines turn into a mass
of qualications. Even the notion of consistency is extremely sensitive to context [14].
Inevitably, this calls into question whether even the simplest of design decisions can be
made without reference to the circumstances of use.
Probably the most useful guideline for the HCI practitioner is to nd an interface
style of proven worth, and copy it | i.e. `design by emulation' [5]. Much of the real
progress in usability has come about in this way, and the opportunity it aords of making
improvements through small scale, incremental changes. Like most people when they are
faced with complex decisions, and uncertain outcomes, interface designers tend to repeat
examples of what they believe to be good and successful. To do otherwise may often be
simply impractical; as Grudin [4] has observed \The methods for arriving at informed
choices are often too time-consuming and imprecise."
In Carroll's view, the failure of HCI's science base to feed productively into practice
is a problem of information ow, and the solution lies in a more eective framework for
translating between the two. He argues that this framework already exists in tasks and
artifacts:
\A task implicitly sets requirements for the development of artifacts, and the
use of an artifact often redenes the task for which the artifact was originally
developed This dynamic relation, the task-artifact cycle, circumscribes the
research and development activities of human-computer interaction." [5]
Others have argued that HCI is failing to deliver eective systems because \ traditional,
predictive research techniques have fallen short of delivering timely and relevant design
information" [15]. From this perspective, the problem lies not in the translation process,
but in the content of the science base, which is intended to support the construction
of theories of human performance, not predictions about the usability of artifacts. The
scientic credentials necessarily rest upon the reproducibility of empirical data, which in
turn rests upon controlled (i.e. articial) conditions of experimentation. The identication
of the generic behavioural characteristics of perceptual and motor systems was important
when design goals were dened solely in terms of optimal performance. Now, however,
it is not the generic characteristics of users that set design benchmarks, but those which
dierentiate users and their working environments. Usability is not a property of the
:::
:::
technology, but a relation between system and users, which can only be determined in
context [16]. Power and control are not conferred by technology per se, but arise out of
the social relationships within which the technology is designed, implemented, and used.
A variety of methodologies have been devised as a means to operationalise HCI design
principles and objectives. Unfortunately, it seems that many fail the crucial test of being
usable in the real world. In a recent survey of HCI design and evaluation techniques,
Bellotti concluded that too many
\ make little attempt to account for the nature of design practice and how
they might integrate with the other necessary activities which have to take
place in order to produce a complete system." [17]
Failing to grasp the situatedness of HCI practice can only have detrimental results. Grudin
has examined some of the organisational factors that militate against the adoption of
HCI design principles and methodologies [18]. He notes numerous practical problems, for
example, in carrying out user participation. HCI methodologies make assumptions about
the nature of organisations. In espousing user participation, they presume that users enjoy
a management culture of `responsible autonomy', and that the workplace is fundamentally
a democratic institution. These assumptions are far-removed from the reality of most
commercial organisations, and proceeding on the basis of such naive models of the setting
and role of participation is likely to run into diculties. For example, it may simply create
expectations that cannot be sustained, or be perceived by management as a threat to its
authority. Indeed, the whole relationship between technical expertise and management
is potentially problematic. Citing Taylorism and the behavioural sciences as examples,
Fischer [19] accuses management of employing technical experts \ to legitimate and
rationalise its own authority and control to serve its own interests." Managerial theory
and practice have evolved in signicant part to block the participation of a wider range
of organisational interests, even, he argues, to the extent of sacricing eciency and
innovation.
:::
:::
:::
3.2. Task Analysis
In many respects, task analysis exemplies the failure of HCI methodologies. There is a
profusion of notations, methodologies and toolkits documented in the literature, but the
eort required to generate task descriptions is out of all proportion to the perceivable
benets [20]. Task analysis leads to the generation of spurious detail, and encourages
a misplaced condence in its validity. Underlying this basic usability problem are more
fundamental issues: the very relevance of the concept of tasks to the determination of
interface requirements is open to question. According to Randall et al., a design strategy
based upon tasks
\ leads the researcher to be powerfully drawn into idealisations of task processes which are a feature of the perspectives s/he brings to the study, and
which govern the way in which activities are ruled `pertinent' or `peripheral'
for the particular task in hand aspects of work do not come conveniently
labelled as adhering to one or another task, and in practice activities spill
:::
:::
out promiscuously into each other and fan out into an unending succession
of elements which relate more or less vaguely with ramied sets of tasks and
subtasks. Such analyses are therefore bound to address themselves to preconceived notions of the `task'. Since these are inevitably limited designing
on the basis of these judgements will in the event prove disruptive rather than
supportive of work activity." [21]
Doubts about the validity of putting tasks at the centre of the HCI design process pose
a problem for Carroll's task-artifact framework. Carroll's objective is to rescue HCI from
some of the diculties inherent in `situated' approaches to design [5]. As we shall see,
there is a strong case for some form of `lter' in order to prevent the designer from being
overwhelmed by detail. The question is why it should (only) be tasks. Noble's analysis
of the history of the development of numerically controlled machine tools shows us that a
`power-artifact' framework may be just as important within organisational contexts [22].
The key point is that when working in an organisational context, the HCI practitioner
may need to draw upon multiple perspectives of the design problem.
:::
3.3. Ethnographic Approaches
The work of Suchman provides the foundations of the case for the adoption of a design
practice based upon the principles of sociological | and specically ethnographic |
enquiry [23]. Her argument is that
\ where technologies are designed at a distance from the situation of their
use (as most are) there is an inevitable gap between scenarios of design and
circumstances of use. Inevitable, because to some extent technologies have
to be designed for unknown users, in unknown circumstances. To get o the
ground, designers need to project a scenario of use, the adequacy of which
will depend on the adequacy of their understanding of the actual situation of
use. In every case, however adequate the designer's understanding, the gap
will exist and will have to be lled by the user as the technology is interpreted
and appropriated to local concerns and circumstances." [24]
The solution calls for an \ethnography of work in context", with designers undergoing a
prolonged period of immersion and absorption within the users' environment [21]. This is
in sharp contrast with methodologies based around the conventional cycle of design, with
prototyping and evaluation conducted within the connes of a limited partnership with
users. Ethnographic approaches reverse the concept of user participation, emphasising
instead that it must be designers who enter into participation with users, and on their
terms. Conventional user participation \ is a poor substitute for understanding what
kind of thing it is that caused the problems in the rst place. Without this it is quite
dicult even to know how to do `evaluation' or how to act on its ndings " [21].
Ethnographic data is typically rich, but informal, poorly-bounded and perennially
pointing to the provisional, partial and incomplete nature of any account of a social situation, and it is precisely this problem | referred to by Carroll as the \Innite Detail
requirement" | that the task-artifact framework seeks to overcome [5]. In contrast, Randall et al. stress the usability problems of ethnographic data in context, in particular that
:::
:::
:::
it is ill-matched to software engineers' design agendas, which tend to be focused around
nding solutions to well-dened problems. They acknowledge, therefore, that it is unrealistic to expect software engineers to take on an unmodied ethnographic perspective, but
do not give any concrete suggestions as to what kind of changes would be appropriate.
\In our view, ethnography and its concern for the particular should be understood as a powerful tool for systems and software engineers, though | at rst
| perhaps more as a problem-generating than a problem-solving tool." [21]
As a design methodology, ethnography is intensive (though potentially uneven in its coverage of dierent groups). Nor is it clear about how its ndings are to be utilised, and by
whom. If ethnography simply taps workforce knowledge and avoids responsibility about
how this information is to be used, and the outcomes of its involvement, then it will lay
itself open to criticism of being manipulative. Ethnographic approaches must come to
terms with the realities of system design and implementation, including power dierentials in organisations. Ethnographers remain divided about their willingness to address
these issues. Some (see for example Greenbaum [25], Cockburn [26]) start from a desire
to confront hierarchical divisions within the organisation, while others maintain a strictly
relativist position and give little attention to how respond to conicts of interest and
perception.
3.4. Socio-Technical Systems
Socio-technical systems (STS) design has its roots in action research into the relationship
between the technical/economic design of production systems and the social, and psychological context of work. It notes that traditional approaches (e.g. Taylorism), which
sought to maximise productivity and eciency, were often self-defeating because of their
negative eects on employee motivation. Instead, it argues that an optimum compromise
should be sought between these requirements. To this end, STS has developed a set of
principles for the design of `good work': in the main these are job design principles for
maintaining the quality of working life | such as broadening, rather than fragmenting,
and routinising roles. STS also suggests that the individual should be aorded some
measure of control over their work and how it develops. STS has been one of the currents
behind ideas of participative design.
Taking up the STS agenda raises a number of diculties. At one level its design
principles are extremely generalised, and it is often dicult to detect how the outcome
of STS-inspired initiatives are dierent from conventional development processes. STS
also faces uncertainties about its relationship to diverse groups and interests within the
organisation. It is clearly `anti-expert' | in that it derives from a critique of Taylorism
and other technocratic positions (e.g. conventional systems development techniques) |
but it is ambiguous in dening its relationship to the array of interests around which it
intervenes. Its insistence on the validity of the views of a wide range of players sits uneasily
with its role as a management tool. STS tends to shy away from detailed discussion of
how to handle conicts of interest | though these have been a recurrent feature of STS
experiments [27]. Above all, STS approaches | though widely discussed | are rarely
adopted in practice in the UK [28].
3.5. Participative Design
STS approaches have been an important inuence in the development of the concept of
user participation in systems design [29]. This has a double motivation | on the one
hand to democratise systems development, and on the other to tap the skills and experience of the workforce and win their commitment to change [30]. These two concerns have
an uneasy relationship with each other. In the UK, the democratic dimension has been
poorly developed. In the absence of strong institutions for industrial democracy, user
participation has been conducted in a manner that aords the end user very little opportunity to inuence the overall objectives of technological change. Participation has often
been late and weak, and has tended to focus on operational aspects of systems. Participation of this sort runs the risk of becoming little more than a manipulative managerial
technique | aording the end user some control over the details of the interface, but
leaving the broader features of system design under the control of managers or technical
specialists. In Scandinavia, the pattern has been more promising [31]. Well-developed
institutions of workplace industrial democracy are supported by the broader context of
legislation, and a culture of democracy. End user interests have found expression through
these structures and have been given appropriate resources (including, importantly access
to sympathetic technical specialists, and the development of alternative, `human-centred'
models for technological development) [32]. Even here, however, it is not altogether clear
that the outputs of such participative design processes dier radically from the products
of `good' conventional design.
3.6. Industrial Sociology and Organisational Behaviour
Although technological and organisational change have been a major concern of many
studies in industrial sociology and organisational behaviour over the last decade, this work
has often been at a level too generalised to be of practical assistance for HCI. Detailed
studies of job content and design (and in particular of the design of technological artifacts)
remain relatively rare. There is a growing body of work, however, which addresses the
social construction and shaping of IT systems (see for example Coombs et al. [33]).
This work has highlighted the diverse concepts surrounding system development held by
dierent groups, which derives from their particular occupational expertise, culture and
ideology, and their strategies and interests within the organisational structure. These
may pose profound problems for eective systems design. For example, in one nancial
organisation we studied, that was attempting to computerise its customer information in
an integrated system, we found ten dierent denitions of the `customer' held by various
functional departments | dierences that could not be resolved by system designers, but
which were eventually resolved by branch managers on the basis of their local business
knowledge [34].
4. THE WAY FORWARD?
As computer applications have developed, HCI has begun to move beyond the arena of
task and interface design, into the broader terrain of the organisational use of technologies.
The question of problem ownership has become central to understanding the scope and
future prospects of HCI. The community must resolve the tension between the quantitative
approaches and `scientic' claims it inherits from Taylorism, ergonomics and experimental
psychology on the one hand, and the qualitative analyses of the organisational context
oered by the sociological disciplines. The danger lies in attempting inappropriately
to subsume one approach within another. Rather than jettisoning wholesale existing
methodologies and tools, the challenge is to gain a better understanding of when and how
to apply them.
It would be wrong to assume that there exists a simple hierarchy of design problems
| from the detailed level e.g. of screen design, to the general level of the organisational
use of IT systems | for which dierent techniques and approaches to HCI are most relevant. What approaches will `work' depends on the context in which the system will
be used. Even `low-level' concerns, such as screen layouts, may need to be informed by
understanding of the expectations and culture of dierent kinds of user. Dierent approaches may oer complementary (or even competing) solutions. For example, problems
of Repetitive Strain Injury (RSI) may be addressed through physical ergonomics (keyboard design, posture etc.), but also tackled at the level of task allocation and job design
and reward systems, and the broader organisational strategies for information capture.
Understanding of the social context is therefore necessary for eective HCI practice at all
levels (though its signicance may vary depending upon the problems being addressed).
Hirschheim & Klein have mapped paradigms of system development according to assumptions concerning knowledge (i.e. objective vs subjective), and assumptions about the
world (i.e. order vs conict) [35]. Adopting their framework, we can classify mainstream
HCI design in the category of objective-order, more overtly ethnographic approaches and
user-centred design initiatives as subjective-order, and socio-technical systems design as
objective-conict. As we have seen, all of these approaches are limited in their ability to
recognise the diversity of perceptions and knowledges amongst the workforce (subjective),
and/or the implications of diering power and interests (conict). Dealing with the latter,
in particular, requires the HCI community to develop a more detailed understanding of
the organisational context and to be more reective about its role and relationship with
the dierent groups within the workplace. It must confront the questions of problem
ownership that result from conicts of power and divergent perceptions in the workplace.
Here, we argue, social and political analysis has a distinctive contribution to make.
The role of the HCI community will remain contradictory and ambiguous | we cannot
remain above the complexities and conicts of the real world of organisational politics.
Our view is that the dierent strands of HCI need to be informed by `sociological' perspectives | and that attempts to overlook the issues they raise (or reduce them to an
individual physiological or psychological level) will be unsuccessful. At the conceptual
level, HCI needs a clearer statement about the dierent contributions of its constituent
bodies of expertise and the relationships between them. This could also have important
practical benets in encouraging HCI practitioners to highlight the diversity of interests
within organisations, and the range of perspectives that can be applied. In this way, a
major contribution of HCI might be to open up questions of problem ownership in IT for
fresh examination.
The HCI community faces a choice. It can cling to the apparent security of a restricted
denition of the problem domain, and the techniques and expertise required. Alternatively
it can lay claim to a broader vision of its role and competence, embracing the wide range of
expertises that are relevant to addressing the complex issues in the design of organisational
IT applications. The latter course would, in turn, open up new questions of problem
ownership, with HCI converging [9] | or possibly colliding | with the established domain
of software engineering.
5. REFERENCES
1 R. Kling, Cooperation and Control in Computer Supported Work, Communications
of the ACM 34(12) (1991).
2 J. Grudin, Why CSCW applications fail: problems in the design and evaluation of
organisational interfaces, in Proc. CSCW'88 Computer Supported Cooperative Work
(Portland, September 26-28, 1988), ACM Press, New York, 85-93.
3 D. Diaper, The Discipline of HCI, Interacting with Computers, 1(1) (1989) 3-5.
4 J. Grudin, The Computer Reaches Out: The Historical Continuity of Interface Design,
in Proc. CHI'90 Human Factors and Computing Systems (1990), ACM Press, New
York, 261-268.
5 J. Carroll, Innite Detail and Emulation in an Ontologically Minimized HCI, in Proc.
CHI'90 Human Factors and Computing Systems (1990), ACM Press, New York, 321327.
6 A. Newell & S. Card, The Prospects for Psychological Science in Human-Computer
Interaction, Human-Computer Interaction 1 (1985) 209-242.
7 J. Carroll & R. Campbell, Softening Up Hard Science: Reply to Newell and Card,
Human-Computer Interaction 2 (1986) 227-249.
8 L. Bannon, From Human Factors to Human Actors: The Role of Psychology and
Human-Computer Interaction Studies in System Design, in [25].
9 J. Grudin, Utility and usability: research issues and development contexts, Interacting
with Computers, 4(2) (1992) 209-217.
10 J. Fleck, The Development of Information-Integration: Beyond CIM?, Edinburgh
PICT Working Paper No. 9, Edinburgh, 1988.
11 S. Smith & D. Wield, New Technology and Bank Work: Banking on IT as an `Organisational Technology', in L. Harris et al. (eds.), New Perspectives on the Financial
System, Croom Helm, London, 1988.
12 P. Clark & N. Staunton, Innovation in Technology and Organisation, Routledge, London, 1989.
13 J. O'Hare, Review of The Human Factor: Designing Computer Systems for People,
Human Factors Society Bulletin, 28(9) (1985).
14 J. Grudin, The Case Against User Interface Consistency, Communications of the ACM,
32(10) (1989) 1164-1173.
15 D. Wixon, K. Holtzblatt & S. Knox, Contextual Design: An Emergent View of System
Design, in Proc. CHI'90 Human Factors and Computing Systems (1990), ACM Press,
New York, 329-336.
16 B. Goransson, M. Lind, E. Petterson, B. Sandblad & P. Schwalbe, The Interface is
Often Not the Problem, in J. Carroll & P. Tanner (eds.), Proc. CHI + GI'87 Human
Factors in Computing Systems and Graphics Interface (1987), ACM Press, New York,
133-36.
17 V. Bellotti, A Framework for Assessing the Applicability of HCI Techniques, in Proc.
INTERACT'90 (Cambridge, August 1990), North-Holland, Amsterdam, 213-218.
18 J. Grudin, Systematic Sources of Suboptimal Interface Design in Large Product Development Organisations, Human-Computer Interaction 6 (1991) 147-96.
19 F. Fischer, Technocracy and the Politics of Expertise, Sage, London, 1990.
20 D. Benyon, The Role of Task Analysis in Systems Design, Interacting with Computers,
4(1) (1992) 102-123.
21 D. Randall, J. Hughes & D. Shapiro, Systems Development | The Fourth Dimension:
Perspectives on the Social Organisation of Work, SPRU/PICT Workshop on Policy
Issues in Systems and Software Development (Brighton, July 18-19, 1991).
22 D. Noble, Social Choice in Machine Design: The Case of Automatically Controlled
Machine Tools, in A. Zimbalist (ed.), Case Studies on the Labour Process, Monthly
Review Press, London, 1979.
23 L. Suchman, Plans and Situated Actions, Cambridge University Press, 1987.
24 L. Suchman, Understanding Practice: An Alternative Perspective For Design, American Educational Research Association (New Orleans, April, 1988).
25 J. Greenbaum & M. Kyng (eds.), Design at Work: Cooperative Design of Computer
Systems, Lawrence Erlbaum Associates Inc, New Jersey, 1991.
26 C. Cockburn, Brothers: male dominance and technological change, Pluto Press, London, 1983.
27 E. Mumford, A participative approach to computer systems design: a case-study of
the introduction of a new computer system, Associated Business Press, London, 1979.
28 L. Willcocks & D. Mason, Computerising Work: people, systems design and workplace
relations, Paradigm, London, 1987.
29 U. Briefs, C. Siborra & L. Schneider, (eds.) Systems Design For, With, and By the
Users, North-Holland, Amsterdam, 1983.
30 P. Cressey & R. Williams, Participation in Change, European Foundation for the
Improvement of Living and Working Conditions, Dublin, 1990.
31 G. Bjerknes, P. Ehn & M. Kyng (eds.), Computers and Democracy, Avebury, Aldershot, 1987.
32 P. Ehn, Work-Oriented Design of Computer Artifacts, Arbetslivscentrum, Stockholm,
1988.
33 R. Coombs & D. Cooper, Accounting for Patients? Information Technology and the
Implementation of the NHS White Paper, PICT Policy Paper no. 10, Economic and
Social Research Council, Oxford, 1990.
34 M. Tierney & R. Williams, Issues in the black-boxing of technologies: What happens
when the black-box meets 40 shades of grey?, Edinburgh PICT Working Paper No.
22, Edinburgh, 1990.
35 R. Hirschheim & H. Klein, Four Paradigms of Information Systems Development,
Communications of the ACM, 32(10) (1989) 1199-1216.
Download