Content uploaded by Philippe Rouchy
Author content
All content in this area was uploaded by Philippe Rouchy
Content may be subject to copyright.
© 2003 Schattauer GmbH
392
Methods Inf Med 4/2003
ies both within technology production and
between technology production and use
[7]. Sociotechnical systems are mutually
constitutive: implementing new systems not
only changes work practice but also im-
pacts back on the system itself.Accordingly,
co-realisation also calls for IT designers to
‘stick around’ and see how a new system is
actually used and respond to new require-
ments as they emerge. We begin by review-
ing current approaches to user-designer
relations in IT systems design and develop-
ment. We then set out what we mean by
co-realisation and, finally, we briefly sum-
marise our experiences so far of following
co-realisation through in practice.
2. User-Designer Relations I:
Ethnomethodology
Numerous researchers have wrestled with
the problems of how best to incorporate
ethnomethodological analyses of work and
technology into IT systems design process-
es [8]. However, while such analyses have
done much to explicate the social character
of work and to explain why new IT systems
have sometimes failed, using ethnometh-
odology as an input into design presents an
altogether different order of problem. At
its simplest, ethnomethodology provides an
informational input into the design process,
making visible the ‘real world’ aspects of a
workplace as it exists; focusing upon the
specific and detailed organisation of activ-
ities which designers are concerned to
understand, analyse and reconstruct. The
ethnomethodologist goes into the work-
Working IT Out in Medical Practice: IT Systems
Design and Development as Co-Realisation
M. J. Hartswood
1
, R. N. Procter
1
, P. Rouchy
2
, M. Rouncefield
3
, R. Slack
1
, A. Voss
1
1
Institute for Communicating and Collaborative Systems, School of Informatics,
University of Edinburgh, UK
2
Department of Human Work Science, Blekinge Institute of Technology, Sweden
3
CSCW Research Centre, Department of Computing, Lancaster University, UK
1. Introduction
In healthcare, as elsewhere, the challenges
facing IT designers and implementers have
grown as IT systems become steadily more
organisationally embedded. While claims
continue to be made of the benefits IT
holds for healthcare (e.g, [1]), many IT
projects have failed to deliver [2]. This
situation has led, somewhat belatedly, to
the recognition that the design and imple-
mentation of organisational technologies
calls for the adoption of a thoroughgoingly
sociotechnical approach.
Two of the most significant contribu-
tions to sociotechnical perspectives on IT
systems design and development in recent
years have come from ethnomethodology
and participatory design (PD). Ethno-
methodologically-informed ethnographic
studies of work practices, for example, have
been used to uncover the social character
of work (e.g. [3, 4]), the relationships
between work practices and technology
(e.g., [5]) and to inform IT systems design
[6]. PD, in contrast, has devised ways of
re-forming IT systems design practice so as
to increase opportunities for user involve-
ment.
In this paper, we argue for moving
beyond the use of ethnomethodology as a
form of ‘socially enriched’ requirements
capture for IT systems design, and PD’s
limited version of user involvement to a
radical re-thinking of user-designer rela-
tions in IT systems design and development
practice. Our proposal is that IT system
design and development should be re-
organised as a co-realisation by users and
IT professionals, breaking down boundar-
Summary
Objectives: The paper explores possibilities for
situating IT design and development work within the
context of use so as to support the co-realisation of
technology and ‘design in use’. The aim is to build a
new understanding between IT professionals and users
which is grounded upon what happens as the latter
grapple with the problems of applying IT, appropriat-
ing its functionalities and affordances into their work
practices and relations.
Methods: Following a discussion of participatory
design and ethnomethodology, a novel method called
co-realisation, which aims to provide a synthesis of
the preceding methods, is suggested as an alternative.
Through a discussion of findings from a case study of
IT systems design and development in healthcare we
show how the co-realisation approach might provide
work-affording systems and how user-designer rela-
tions might be reformulated. We suggest that work-
affording systems can be developed through the
deployment of an engaged facilitator who works with
the users to unpack the work site-specific potentialities
of technology.
Results: The case study shows how risk of non-adop-
tion might be minimised through the development of
partnerships, and how the presence of the facilitator
in the workplace capitalises on the mundane work
undertaken therein and how the facilitator might work
with the users to develop artefacts that support this
work as opposed to reconfiguring it.
Conclusions: The case study illustrates co-realisation
in action and how it might be seen to reconfigure
relations between users and designers in a way that
appears productive. Co-realisation can help address
the widely observed problem of IT systems failures in
healthcare.
Keywords
Ethnomethodology, IT systems design and
development, participatory design, design in use
Methods Inf Med 2003; 42: 392–7
IT Systems Design and Development
393
Methods Inf Med 4/2003
place and brings back descriptions of work
practices and their possible implications for
design. Instead of designers seeking to
establish a relationship with users, we have
the ethnomethodologist acting as a ‘proxy’
for users.
The use of ethnomethodological ana-
lysis as part of requirements capture is gen-
erally perceived as valuable in identifying
the exceptions, contradictions and con-
tingencies of work activities that do not
necessarily figure in formal representations
of work. At the same time, it exposes a
fundamental problem when the designer
attempts to link up with ethnomethodolo-
gist in this way.The designer wants to know
what these findings might mean for the
design of new systems and tools and the im-
plications of design decisions on work prac-
tices. The ethnomethodologist, however,
will insist that such questions can only be
answered in, and through, use of the new
system: to employ ethnomethodological ac-
counts as a tool for “inventing the future”
must inevitably fall foul of the paradox of
ethnomethodologically-informed design [8].
The need to increase the utility of eth-
nomethodology for design has directly
motivated a number of developments for
collecting, organising and presenting
ethnomethodological analyses [9]. In con-
trast to these initiatives, we argue that what
we should actually be doing is taking up
Button’s suggestion “... that ethnography
can be trailed into the world of design in
a harder fashion than our enthusiasm
currently permits” [6]. In particular, we
claim this calls for creating a shared prac-
tice between users and IT professionals
that is grounded in the lived experience
of users. It is time, as Grudin [10] has
observed, for IT system designers to move
beyond a narrowly conceived engineering
mentality to attend to the lived realities of
“being a user in an organisational setting”.
3. User-Designer Relations II:
Participatory Design
The other major innovation in sociotechni-
cal approaches to IT systems design that is
close to our concerns has been the explora-
tion of various forms of participatory
design (PD) [11, 12]. With their emphasis
on the importance of involving users in de-
sign, PD approaches attempt to address the
problems posed by the asymmetry that is
characteristic of user-designer relations.
Devised initially as a way of democratising
technological development in the work-
place, PD has gradually been re-shaped as a
partnership for IT systems design in which
users are seen as important sources of
information, but play a more passive role in
subsequent development.
In order to facilitate user-designer rela-
tions, PD has built up an impressive variety
of representations of the technology. Kyng
[13], for example, describes the use of
mock-ups and exploratory prototypes in
design work.Among other points, he stress-
es the value of ‘low tech’ representations
such as pencil and paper as ways of ensur-
ing that while they may be created initially
as ‘designers’ objects’ these representations
can genuinely become ‘users’ objects’. Kyng
goes on to acknowledge, however, that the
very properties of prototypes that encour-
age shared practice “... do not support the
end users in developing an understanding
of technical possibilities and limitations;
such understanding has to be developed by
other means” [13]. Building shared practice
is not only about designers getting to grips
with users’ needs, but also users grasping a
sense of what technical work is, including
what is, and what isn’t possible. “... end
users have difficulties in understanding
the space of possibilities and limitations
for changing the system being designed,
including difficulties in distinguishing the
simple, the complex, and the impossible”
[13].
PD also attempts to avoid the paradox
of ethnomethodology by envisioning how
the new system will actually be used in
practice. Here, a new form of representa-
tion is deployed, the scenario. “... a scenario
describes how the computer support being
developed may improve upon the relevant
work situations. Scenarios are intended to
set the stage for stimulating future use with
prototype(s) of the system(s) being devel-
oped” [13]. However, reliance on scenarios
raises problems, as Kyng acknowledges.
“Particularly when the prototyping envi-
ronment is the same as the implementation
environment ... maintaining a shared
understanding of what is representational,
what is coincidental, and what is actual
becomes difficult ... there is a tendency
to stick to the interface when making
mock-ups and prototypes.This is not due to
unsolved theoretical problems – good
examples of mock-ups going beyond the
interface do exist, but obviously making
such mock-ups and prototypes requires
more work ...” [13].
Our point is that representations and
scenarios are useful tools for design, but we
should recognise their limitations [14, 15].
The system itself is more valuable than any
representation – even prototypes – can be
for communicating its scope and behaviour,
and implementation – when users apply the
system in their work – is the only way to
find out how users actually make use of it.
The problem is the failure of PD – indeed
of any design methodology – to take an
interest in use, where “... the design practice
and the designed-for practice are not separ-
ated in time or space” [14]. With few excep-
tions, the focus within PD projects seldom
moves beyond the design phase or the con-
struction of early prototypes, onto imple-
mentation. “... many of the methods focus
implicitly or explicitly on the early phases
of development. The outcomes of the par-
ticipatory design phases are handed over to
software developers working in a more or
less traditional way” [16]. So, at the very
point where user expertise becomes most
valuable to design, and users have the
opportunity to be in control of the process,
the user-designer relationship terminates.
Consequently, we must conclude that,
despite declared intentions, PD approaches
continue to privilege the role and expertise
of IT professionals over that of users.
4. User-Designer Relations III:
Beyond Design
Despite the significant and much needed
benefits that ethnomethodology and PD
have brought to IT system design and
development practice, the fact is that user
requirements that can only be identified in
the context of – and through – use are lost
to the designer. The premature suspension
of user-designer relations in both cases, the
apparent inability to look ‘beyond design’,
leads to a failure to connect effectively with
grass roots, user-led change processes that
come into play once a system is implement-
ed [17]. Use is an important site of learning
and innovation as users experiment, adapt,
share and sometimes appropriate the adap-
tations of others, mobilising their collective
resources to evolve the system, to continue
design ‘in use’. It is in these ways that users
have been able to cope to some degree with
the shortcomings of conventional IT design
and development practice, fixing, or learn-
ing how to work around, the deficiencies
created through the reliance on prior
design. Similar user-led processes are ob-
served to play a significant role in initiating
the adoption of IT within organisations
(e.g. [18]). The problem is how to make
them more effective.
Studies of use have identified the emer-
gence of users to fill various quasi-technical
roles as being instrumental in initiating and
sustaining ‘design in use’. Those document-
ed include ‘tinkerers’, ‘tailorers’, ‘transla-
tors’, ‘handymen’ and ‘mediators’ [19].
Okamura et al. suggest that mediators are
more effective if they are users, sensitive to
user feedback and technically adept. “The
nature and efficacy of mediation is likely to
depend considerably on the type of individ-
uals involved. Where mediators are them-
selves users and thus have intimate knowl-
edge of the context of use as well as
credibility with the users, their actions will
be more locally appropriate and more like-
ly to be accepted by others ... Further, being
technically skilled clearly allows mediators
to make more extensive changes to the
system” [19]. Clearly, however, these user-
led processes will be limited in their scope
if they are unsupported, for example, if
users must rely entirely on their own tech-
nical skills. “The extent and effect of medi-
ation also depends on the authority granted
and resources made available to mediators.
Intervention occurs, with or without careful
deliberation and management. We would
suggest that where the role and influence of
intervenors is recognised, sanctioned, and
supported, such mediation can advance
particular kinds of innovative and locally
customised uses of technology, and allow
the evolution of its use over time” [19].
In practice, however, this support is
generally not forthcoming. Organisational
responses to the need to deploy IT exper-
tise within the workplace are generally
limited to ‘user support’ and the ‘help
desk’, if they exist at all. Both of these roles
tend to be regarded as relatively low in
prestige and so are usually filled by less
skilled and/or experienced IT staff. Such
support staff are usually well placed to
understand users’ work and issues that
arise in use, but they are seldom empow-
ered to act upon it in the way that users
need. In this, support staff must generally
defer to the next level in the IT manage-
ment hierarchy, system maintenance. One
of the duties of support or help desk staff,
then, is to act as user proxies, to collate and
feedback information about users’ prob-
lems to the maintenance team, where
they will be analysed, solutions formulated,
and their implementation prioritised and
planned.The effect is that the emergence of
new requirements from use tends not to be
perceived as being part of ongoing design,
but as a ‘maintenance issue’ and is still
considered of less importance than initial
design [20].“Maintenance has a poor image
among software engineers. It is seen as a
less skilled process than program
development and, in many organisations,
maintenance is allocated to inexperienced
staff” [20].
5. User-Designer Relations IV:
Co-realisation
We have argued that the key issue that an
ethnomethodologically-informed IT design
and development practice must address is
user-designer relations. We have also
argued that the focus of the user-designer
relation problem is not actually ‘design’,
but ‘use’. As IT systems and artefacts pene-
trate more and more into people’s working
lives, the ‘design problem’ is not so much
concerned with the creation of new tech-
nical artefacts as it is with their effective
configuration and integration with work
practices. Users need the opportunity that
only their work can offer to explore fully
the possibilities for adopting, and adapting
to, new systems and artefacts. Yet, as we
have seen, issues of how new systems are
placed in actual workplaces, and how feed-
back from these settings might influence
design, are accorded little importance in
current IT design and development prac-
tice.
Our goal is to look ‘beyond design’ [17]
as an activity identified with a specific
phase of the lifecycle to the means by which
design emerges and develops as part of the
ongoing struggle of making this particular
system work for these particular users, in
this particular workplace and at this particu-
lar time. As Trigg, Blomberg and Suchman
[21] write: “... co-development of CSCW
technologies ... means more than engaging
prospective users in the design of new
computer systems to support their work. It
requires that we as designers engage in the
unfolding performance of their work as
well, co-developing a complex alignment
among organisational concerns, unfolding
trajectories of action, and new technologi-
cal possibilities.”
Our proposal for re-specifying IT design
and development practice along ethno-
methodological principles is co-realisation,
a shared, situated practice involving users
and IT professionals that is grounded in the
lived experience of users as they grapple
with the problems of applying IT, appro-
priating its functionalities and affordances
into their work practices and relations.
Only in this way can designers truly get to
understand the users’ work and their
changing needs. In particular, co-realisation
involves: attending to the evaluation of
technologies; appreciating the benefit of
active worker participation in design;
adapting to a particular organisational set-
ting and the explicit connection of studies
of work and system design. It also accords
with Trigg, Blomberg and Suchman’s vision
of the project of cooperative design; “... an
approach to the creation of more useful
and useable computer artifacts ... the com-
bination of envisioning, building and use ...
Hartswood et al.
394
Methods Inf Med 4/2003
IT Systems Design and Development
395
Methods Inf Med 4/2003
as we work our way through successive
rounds of trial and discovery regarding all
of the ways in which the world is different
than we had imagined it to be” [21].
Specifically, we are exploring ways of
taking the technical work of IT design and
development into the users’ workplace.
Our approach is founded on the view that
the designer should be taken to the work
rather than representations of that work
brought to the designer. “To further this
process requires in turn that system devel-
opers become responsible for locating
themselves within the extended networks
of sociomaterial relations and forms of
work that constitute technical systems” [7].
In other words, we resolve the problem of
how to bring accounts of work back from
the field and make them useful to the
designer by, instead, taking the designer
into the field, to the user and to the work:
“Working practice is lived experience, only
partially representable” [22].
The changing technical landscape of IT
systems and artefacts makes our proposal
particularly timely. Many ‘user-level’ tech-
nologies are now available in the form
of generic components, opening up the
possibilities for solutions that can be
customised, configured and evolved on a
‘pick and mix’ basis without the need for
‘deep’ technical expertise. Given the right
choice of technologies, design and develop-
ment work can assume the characteristics
of ‘bricolage’ – i.e., the rapid assembly and
configuration of ‘bits and pieces’ of
software and hardware [23] – led by users
acting within their own workplaces. Our
proposal for IT design and development as
co-realisation acknowledges the relevance
of these user-led processes, but our aim is to
push their technical scope further by in-
volving IT expertise. “This requires cross-
ing boundaries both within technology pro-
duction and between technology produc-
tion and use ... If technologies are to be
made useful, practitioners of other forms of
work must take up the work of design
... that is appropriating the technology so as
to incorporate it into an existing material
environment and set of practices” [7].
6. Methodology
Practically, our approach is based upon
taking the technical work of design and
development into the users’ workplace.
Our aim is to achieve a situation where
users and IT professionals can spontane-
ously shift the focus of their attention
between the different phases of the
system/artefact lifecycle, even to the extent
that these cease to exist as distinct and
separable activities.We are seeking to bring
about a context for IT design and develop-
ment work where, as Buscher, Mogensen
and Shapiro have put it, “… effort shifts
fairly smoothly between implementing or
adjusting previously decided possibilities,
picking up on the host of small problems
that arise during work, coping with the
unanticipated consequences of previous
actions, talking to individuals …” The
emphasis throughout is on tightly coupled,
‘lightweight’ design, construction and eval-
uation techniques [23].
Technically, we make extensive use of
various off-the-shelf, configurable compo-
nents. These ‘information appliances’ can
be easily and rapidly customised to create
prototypes for evaluation, experimentation
and use. Co-realisation has implications for
the range of skills that IT professionals may
be required to display in order to cope
successfully with the different circumstanc-
es in which they must engage with users. In
effect, they are called upon to play the role
of ‘IT facilitator’ in the broadest sense of
the term: helping users to realise their
needs. Among other roles, this involves
acting as design consultant, developer,
technician, trouble-shooter and handyman.
7. Co-realisation: Summary
of Experiences So Far
We have been conducting a pilot study of
IT systems design and development as
co-realisation in a busy toxicology ward of
a large hospital, where we are working with
staff members to create improved tools for
the management of patient records and
information for the management of patient
care [24]. So far, our findings substantiate
both the premise of co-realisation and –
importantly – its feasibility.
Experience to date reveals the role
of the IT facilitator being shaped and
elaborated by the ongoing process of
dialogue with users. Thus far, it includes
aspects of ‘operational support’ and ‘system
maintenance’ as well as system design and
development. For example, a ward member
might ask if a particular resource is avail-
able rather than checking its availability
herself. (Note that the facilitator needs to
be alert to the multiple interpretations such
a remark might entail, including that it is
a tentative or disguised expression of a
requirement.) Through such interactions,
we see the facilitator’s role becoming rede-
fined to include aspects of using the system,
rather than simply developing it. Our
experience suggests that it is constructive
for users to enlist and appropriate the
facilitator’s skills in these diverse ways,
at least initially, or until users feel more
comfortable and are able to be more
self-sufficient.
The facilitator is required to reflect
on how his or her role within the setting
has evolved in relation to the goal of co-
realising the technology that members
need to become competent in using. Simi-
larly, there is an onus on the facilitator to
reflect on how expectations are produced
and dealt with, and how this process might
be managed to sustain users’ commitment
to participate [25] and to encourage, and
help resolve, debates and differences of
opinion about the system’s requirements.
Since many of the interactions between the
facilitator and ward members are struck up
spontaneously and opportunistically, there
is a danger of the facilitator finding him
or herself dealing with conflicts of opinion.
So far, instances of this have been few, but
we may expect this to change as members
come forward with more ideas. More for-
mal interactions such as review meetings
have a role to play here, but it must be
the facilitator’s responsibility at other times
to articulate and make understandable
the ‘status quo’, i.e., ‘how things have come
to be this way’ when alternatives are
proposed.
Hartswood et al.
396
Methods Inf Med 4/2003
The interactions between IT facilitator
and ward staff range over many topics
and serve multiple purposes; staff make
comments about the tools, talk about what
information they think should be in the pa-
tient record, how patient care information
should be organised and how it should be
accessed; the facilitator seeks clarifications
of remarks, informs staff about new fea-
tures and about features that are planned
for implementation. Sometimes, talk moves
onto issues of implementation as staff try to
gain an understanding of what is technical-
ly feasible, or the facilitator attempts to
manage staff’s expectations of what is
achievable in the short or longer term.
We are aware that the work of creating a
system only provides an opportunity for
building a shared practice between users
and IT specialists, but does not guarantee
that it will happen. Unlike the work of ward
staff, which is largely visible (or for reasons
of accountability is often rendered visible),
IT work retains significant opacities. This is
undesirable if we want users to gain an
understanding of the technology and of
technical work, and so be better able to
judge what is possible and what is not, what
is simple and what takes time. Thus, the IT
facilitator must explore ways and opportu-
nities to actively engage users – to explain
what it is he or she is doing – in order to
make his or her work understandable by,
and accountable to, others.
We find that the emergence of require-
ments extends beyond ‘formal’ user-design-
er meetings, and that there is a multiplicity
of ways in which new requirements can
emerge. We frequently observed that the
recognition of defects and deficiencies
arises from trying to use the system in the
context of doing the work. When a staff
member needs a piece of information ‘to
hand’ it is precisely then – when the options
are foregrounded – that consideration will
be given to the means of solving this prob-
lem, using these available resources. Par-
ticular artefacts and methods then become
relevant to the staff member that were
previously part of the unconsidered back-
ground of the workplace. The problem is
made concrete and the contingencies asso-
ciated with ‘solving the problem’ become
recognisable.
As staff gain familiarity with the system,
they begin to request modifications to, or
expansions of, the system to articulate more
closely with aspects of their work. Our
argument is that the competencies of users
need to be considered over time as they
develop and become more sophisticated
in system use. The point is not simply that
experienced users provide ‘better’ feed-
back, but that as users acquire certain com-
petencies in using a given system, a range of
design possibilities can emerge. As users
become ‘experienced’ they develop new
ways of using the system that in turn gener-
ate ideas for its further development and in
so doing move from ‘naive’ to ‘regular’
users. Rather than users simply adapting
themselves to the new system, our
approach stresses a change not only in the
user, but also their use of the system as a set
of work practices evolve through use.
The approach avoids the polarisation of
the outcome of technological interventions
into either ‘successes’ or ‘failures’.This may
in part be due to our lightweight approach
– but perhaps this is the way to go. Projects
that involve the deployment of large mono-
lithic systems from scratch inevitably
embody the terms of their own success or
failure. In contrast, we draw a picture of an
ongoing practical struggle to find utility in
technology where ambitions, work practic-
es and explorations of technological limita-
tions and affordances jostle together and
are reshaped in order to accommodate one
another.
8. Co-realisation:
Future Prospects
It seems that, both for ourselves and our
users, the pilot project has been a success
so far. We are continuing to explore the
prospects for co-realisation as the im-
plementation and deployment phases of
the project unfold. This provides us with an
opportunity to explore are a number of
issues that we have yet to encounter, but
which may be important for determining
the practical boundaries of co-realisation.
For example, we expect the demands made
upon the IT facilitator to escalate as the
different modes of facilitation: design
consultant, technician, trouble-shooter and
handyman are increasingly called into play.
This is a demanding combination of roles
and raises issues of skill repertoires and the
possibilities of over-loading.
The nature of the pilot project makes us
cautious about trying to generalise from
the lessons we learn so far. It is small scale,
with all the project benefits that this
implies: we are dealing with a small and
relatively cohesive group of users, there is
only a single workplace and the boundaries
of the system being co-realised are well de-
fined. It is important to test our approach
on a larger scale, i.e., large, but diverse, user
communities, multiple workplaces and
large scale, complex systems and this we are
now beginning to do within a hospital-wide
IT project. We believe, however, that it is in
such projects where the benefits of a co-
realisation approach will have the greatest
impact.
In healthcare, as elsewhere, there has
been a shift over the last ten years in organ-
isational acquisition strategies for large
scale systems towards commercial off-
the-shelf (COTS) software packages – e.g.,
enterprise resource planning (ERP), hos-
pital information systems (HIS) and elec-
tronic medical records (EMR) – created by
designers for “ ... unknown populations of
prospective users ...” [12]. Organisations
face new challenges to select, assemble and
configure solutions that are appropriate to
their needs [13] and to reconfigure them as
those needs change. COTS solutions are
merely indicative of design issues post-
poned, not resolved and which remain to be
addressed when the organisation ‘opens the
box’ and attempts to make the technology
work. It is no surprise that, in many cases,
the outcome of applying COTS solutions
in healthcare has been failure [2]. The
problem is to ensure that the generic
models of work embedded in COTS solu-
tions are evolved in locally meaningful
ways. “... computer-based systems intended
to serve as the primary tools for some
domain of work must eventually be
tailored to meet the specific requirements
of that domain. Whether the work is done
by vendors, systems integrators, third party
or local developers, ultimately the need for
customisation, and for the representational
resources and cooperative design practices
.... becomes relevant” [22]. We argue
that co-realisation provides the best way
forward in tackling the challenges of COTS
projects and particularly those stemming
from the need to ‘localise’ the ‘global’ [27].
Translating IT systems design and devel-
opment as co-realisation onto a larger
stage calls for an awareness of the wider
organisational context. Within many or-
ganisational settings, there exists a tension
between co-realisation for local practices
one the one hand and the pressures to use a
new system as an instrument of standard-
isation on the other. Also, there may be
future interoperability problems if co-
realisation proceeds ad-hoc. Inevitably, for
these and other reasons, it will be important
that user-led processes that we have advo-
cated here be maintained in alignment with
the broader, strategic concerns of IT
systems management.
We would argue that it is important for
IT professionals to capitalise on the afford-
ances of the mundane organisational
practices, tasks and routines – ‘the way we
do things around here’ – and to do so on a
longer timescale than has hitherto been
traditional. In other words, we would
suggest that co-realisation will take longer,
but that its payoffs will be greater in that
users will get the system that they need to
get their work done and IT professionals
will be able to deliver systems that are
‘uniquely adequate’ for such tasks. IT
professionals must ‘become users’ and
appreciate the manner in which artefacts
are embedded in workplace contexts – cru-
cially they must do this in a longitudinal
fashion, thereby offsetting the potential
for unanticipated consequences of system
operation to erode utility.
The role of IT professionals as interme-
diaries is important – the developing
system should support the work tasks of the
organisation and its members over time,
locating itself in the just-thisness of
work practice by virtue of its developers’
appreciation of those tasks (this is what,
following Garfinkel and Wieder [28], we
would call ‘hybridity’). It is simply not good
enough to hand over a black boxed system
and to walk away hoping that the users will
somehow cope with its exigencies and still
be able to do their work. IT professionals
must support the work of end users and be
able to do so because they have been
immersed in the work worlds of those end
users. Such skills are, we would contend,
essential for the IT professional in the
twenty-first century. It is up to that group
to live up to their promise and to deliver
systems that afford work practices as
opposed to systems that have to be worked
around.
Acknowledgments
We would like to thank staff from the toxicology
ward, Royal Infirmary of Edinburgh for their
help and participation.This work is funded by the
Engineering and Physical Sciences Research
Council, grant number GR/M52786.
References
1. NHS Executive. An information strategy for the
modern NHS 1998–2005. Leeds: Department of
Health: 1998.
2. Heeks R, Mundy D, Salazar A. Why healthcare
information systems succeed or fail. Institute for
Development Policy and Management Working
Paper Series No. 9. Manchester: University of
Manchester: 1999.
3. Hartswood M, Procter R, Rouncefield M, Sharpe
M. Making a case in medical work: implications for
the electronic medical record. Comput Supp Coop
Work, forthcoming.
4. Heath C, Luff P. Technology in action. Cambridge:
Cambridge University Press: 2000.
5. Berg M. Patient care information systems and
health care work: a sociotechnical approach. Int J
Med Inf 1999; 55: 87-101.
6. Button G. The ethnographic tradition and design.
Design Studies 2000; 21 (4): 319-32.
7. Suchman L. Located accountabilities in technology
production. In: Mackenzie D, Wajcman J, editors.
The social shaping of technology. 2nd ed. Bucking-
ham: Open University Press: 1999; pp. 258-65.
8. Dourish P, Button G. On “technomethodology”:
foundational relationships between ethnometh-
odology and system design. Human-Computer
Interaction 1998; 13: 395-432.
9. Hughes J, O’Brien J, Rodden T, Rouncefield M.
Ethnography, Communication and support for
design. In: Luff P, Hindmarsh J, Heath C, editors.
Workplace studies. Cambridge: Cambridge Univer-
sity Press; 2000.
10. Grudin J. The computer reaches out. In: Carrasco
Chew J, Whiteside J, editors. Proceedings of the
ACM conference on human factors in computing
systems. New York:ACM Press; 1990: pp. 261-8.
11. Blomberg J, Kensing F. editors. Special issue on par-
ticipatory design. Comp Supp Coop Work 1998; 7:
3-4.
12. Muller M, Wildman D, White E. Taxonomy of PD
practices:A practitioner’s guide. Comm ACM 1993;
36 (4): 26-8.
13. Kyng M. Making representations work. Comm
ACM 1995; 38 (9): 46-55.
14. Bowers J. The Janus faces of design. In: Bowers J,
Benford S, editors. Studies in Computer Supported
Work. Amsterdam: Elsevier Science; 1991: 333-49.
15. Suchman L. Representations of Work. Comm ACM
1995; 38 (9): 33-4.
16. Dittrich Y. Developing a language for participation.
Research Report 18/98, Karlskrona: Department of
Computer Science and Business Administration,
University of Karlskrona/Ronneby; 1998.
17. Procter R, Williams R. Beyond design: social learn-
ing and CSCW – some lessons from innovation
studies. In: Shapiro D, Tauber M, Traunmulller R,
editors. The design of CSCW and groupware
systems.Amsterdam: Elsevier Science; 1996: 445-63.
18. Jakobs K, Procter R, Williams R. A study of user
participation in standards setting. In: Muller M,
Tschegli M, editors. Companion proceedings of the
ACM conference on human factors in computing
systems. New York:ACM Press; 1996, pp. 109-10.
19. Okamura K, Orlikowski WJ, Fujimoto M, Yates J.
Helping CSCW applications succeed: the role of
mediators in the context of use. In: Furuta R, Neu-
wirth C, editors. Proceedings of the ACM Confer-
ence on Computer-Supported Cooperative Work;
1994, pp. 55-65.
20. Sommerville I. Software engineering. 6th ed. Lon-
don: Addison-Wesley; 2001.
21. Trigg R, Blomberg J, Suchman, L. Moving
document collections online: The evolution of
a shared repository. In: Bødker S, Kyng M, Schmidt
K, editors. Proceedings of the Euro-pean Confer-
ence on Computer-Supported Cooperative Work.
Dordrecht: Kluwer; 1999, pp. 331-50.
22. Suchman L. Making Work Visible. Comm ACM
1995; 38 (9): 56-64.
23. Buscher M, Mogensen P, Shapiro D. Bricolage as a
software culture. In: Proceedings of the COSTA4
workshop on software cultures. Vienna: Technical
University of Vienna; 1996.
24. Hartswood M, Procter R, Rouncefield M, Slack R.
Being there and doing IT in the workplace: a case
Study of a co-development approach in healthcare.
In: Cherkasky T, Greenbaum J, Mambery P, Pors J,
editors. Proceedings of the CPSR/IFIP WG 9.1
Participatory Design Conference. CPSR; 2000, pp.
96-105.
25. Buscher M, Hartswood M, Mogensen P, Procter R
Shapiro D, Slack R, Voss A. Promises, premises and
risks: sharing responsibilities, working up trust and
sustaining commitment in participatory design proj-
ects. In: Binder T, Gregory J, editors. Proceedings of
the Participatory Design Conference, CPSR; 2002.
26. Procter R, Williams R, Cashin L. Social learning
and innovations in multimedia-based CSCW. ACM
SIGOIS Bull 1996; 17 (3): 73-6.
27. Timmermans S, Berg M. Standardization in action:
achieving universalism and localization in medical
protocols. Social Studies of Science 1997; 27: 273–
305.
28. Garfinkel H, Wieder, L. Two incommensurable,
asymmetrically alternate technologies of social
analysis. In:Watson G, Seiler R, editors.Text in con-
text: studies in ethnomethodolo
gy. Newbury Park:
Sage; 1992: 175-206.
Correspondence to:
Rob Procter PhD
Institute for Communicating and Collaborative Systems
School of Informatics
University of Edinburgh
Edinburgh EH8 9LW
UK
E-mail: r.procter@ed.ac.uk
IT Systems Design and Development
397
Methods Inf Med 4/2003
