Lightweight Design Methods
in Integrated Practices
Liv Karen Johannessen,
Gunnar El ingsen
1 Kent Beck, Extreme Programming
Introduction
Explained: Embrace Change, Second
The relevance of engaging users in the development of information
edition (Boston: Addison-Wesley, 2004).
systems is wel recognized. On the one hand, users are expected to
2 Jeff Howard, “Toward Participatory
provide designers with valuable insight into the users’ work prac-
Ecological Design of Technological
tice. On the other, users need an understanding of the technical
Systems,” Design Issues 20, no. 3 (2004):
40-53, at 41.
possibilities and limitations of a new system. This col aboration is
3 Finn Kensing and Jeanette Blomberg,
facilitated through a range of techniques, spanning from tradi-
“Participatory Design: Issues and
tional requirement specifications to state-of-the-art, agile meth-
Concerns,” Computer Supported
ods.1 Agile methods are seen as “lightweight” methods
Cooperative Work 7, no. 3-4 (1998):
characterized by short development cycles and by continuous
167-85, at 179 and Anne-Marie Oostveen
releases of working software. This method enables users to regu-
and Peter van den Besselaar, “From Small
Scale to Large Scale User Participation: A
larly assess and give feedback on the quality of the information
Case Study of Participatory Design in
systems throughout the whole development process.
E-Government Systems,” in Proceedings

As a branch of design studies, the Participatory Design field
of the Eight Conference on Participatory
has been particularly concerned with giving users a direct role in
Design: Artful Integration: Interweaving
decision making about the development of new systems. Participa-
Media, Materials, and Practices, 1 (New
York: ACM Press, 2004), 173-82, at 174.
tory Design generally adheres to “bottom-up” approaches to
For concrete examples on small-scale
ensure “empowered” and satisfied users, on the basis of a general
projects, see Erling Björgvinsson and
belief that this approach leads to better systems.2 This paper is
Per-Anders Hillgren, “On the Spot
positioned in this tradition, and, in accordance with the theme of
Experiments Within Healthcare” in
the 2008 Participatory Design conference, ”Experiences and Chal-
Proceedings of the Eight Conference on
lenges,” we call for the Participatory Design field to broaden its
Participatory Design: Artful Integration,
93-101; Magnus Irestig, Henrik Eriksson,
range of interest and intensify its research efforts on large-scale
and Toomas Timpka, “The Impact of
integrated systems in complex organizational settings.
Participation in Information System

The rationale for this call is that the general tendency in the
Design: A Comparison of Contextual
Participatory Design community has been to report on smal -scale
Placements,” in Proceedings of the Eight
experimental and prototype-based projects of limited scope and
Conference on Participatory Design:
Artful Integration, 102-11; Thomas
duration.3 We acknowledge the value of these contributions while
Riisgaard Hansen, “Strings of
also suggesting that they do not reflect the chal enges that many
Experiments: Looking at the Design
current organizations face when implementing new information
Process as a Set of Socio-Technical
systems. First, many new information systems presuppose integra-
Experiments,” in Proceedings of the
tion with a large portfolio of existing systems. Second, smal -scale
Ninth Conference on Participatory
Participatory Design projects ignore the full organizational com-
Design: Expanding Boundaries in Design,
1 (New York: ACM Press, 2006), 1-10;
plexity of establishing robust and sustainable systems.4 Because
and Jesper Simonsen, “Reconfiguring
Participatory Design researchers are not active in this arena, their
Cooperative Work by Visualizing EPR
on Large Projected Screens,” paper
© 2012 Massachusetts Institute of Technology
22
DesignIssues: Volume 28, Number 3 Summer 2012

---

valuable insights have less effect. Dan Shapiro argues along simi-
lar lines, suggesting that the Participatory Design community
establish a program of action to achieve more influence in this
more complex area.5 In addition, because of the narrow, smal -scale
nature of many Participatory Design projects, the political dimen-
sion of design and implementation is increasingly neglected. This

presented at the PDC 2006 Workshop
lack of attention marginalizes one of the key foundations of the
on Reconfiguring Healthcare: Issues
Participatory Design field: its political heritage.6
in Computer-Supported Cooperative

The aim of this paper is to contribute to an understanding of
Work in Healthcare Environments,
Trento, Italy, 2006.
how Participatory Design plays out in emerging, large-scale infor-
4 Finn Kensing and Jeanette Blomberg,
mation systems projects. We argue that even if many of these proj-
“Participatory Design: Issues and
ects start out on a wel -founded, smal -step methodological basis,
Concerns,” 179.
such as agile methods, complex organizational issues inevitably
5 Dan Shapiro, “Participatory Design:
become part of the process, especial y as the scope and size of the
The Will to Succeed,” in Proceedings
of the 4th Decennial Conference on
system increase. More specifically, we discuss this implicated
Critical Computing: Between Sense
infrastructural complexity as the system scales up, recognizing the
and Sensibility (New York: ACM Press,
challenge of mobilizing participation in an integrated environ-
2005), 29-38, at 33.
ment. We also critically examine the traditional neutral vendor
6 See, e.g., Gro Bjerknes and Tone
role, which is an assumption of agile engineering methods.
Bratteteig, “User Participation and

Empirical y, we focus on the design and implementation of
Democracy: A Discussion of Scandinavian
Research on System Development,”
the DIPS Interactor—a system that makes it possible for general
Scandinavian Journal of Information
practitioners (GPs) to electronical y order analyses from hospital
Systems 7, no. 1 (1995): 73-98, at 74;
laboratories. The system was developed by the vendor DIPS, in
Eevi E. Beck, “P for Political: Participation
close collaboration with GPs in the North Norwegian health
Is Not Enough,” Scandinavian Journal of
region and the University Hospital of North Norway (UNN).
Information Systems 14, no. 1 (2002):
77-92, at 79; and Jørgen Bansler,
We elaborate on the conditions for user involvement in the project
“Systems Development Research in
as the DIPS Interactor evolved from a local, small-scale system
Scandinavia: Three Theoretical Schools,”
with a few GPs and one laboratory to include many GPs, laborato-
Scandinavian Journal of Information
ries, and hospitals.
Systems 1, no. 9 (1989): 3–20, at 13.
7 For examples, see Geoffrey C. Bowker
Information Systems Development and Participatory Design
and Susan Leigh Star, Sorting Things Out:
Classification and Its Consequences
The social character of the design of technical systems is empha-
(Cambridge, MA: MIT Press, 1999); Ina
sized in several studies.7 On the one hand, social processes shape
Wagner, “A Web of Fuzzy Problems:
the designers’ assumptions about future use, leading to technical
Confronting the Ethical Issues,”
design decisions. On the other, they shape how users perceive, use,
Communications of the ACM 36, no. 6
and potential y reject a new technology. Hence, the relationship
(1993): 94-101; Jeff Howard, “Toward
Participatory Ecological Design of
between designers and users embodies deep assumptions about
Technological Systems,” Design Issues
the relationship between the technical and the social.8 Not surpris-
20, no. 3 (Summer 2004): 40-53; and
ingly, then, a recurrent concern in many projects for information
Esko Kurvinen, Ilpo Koskinen, and Katja
systems development has been to determine a strategy for interact-
Battarbee, “Prototyping Social
ing with the users. Traditionally, the waterfall model has been
Interaction,” Design Issues 24, no. 3
applied to the process of developing information systems,9 unfor-
(Summer 2008): 46-57.
8 Jeff Howard, “Toward Participatory
tunately leaving a less influential role for users. Here, customers
Ecological Design of Technological
specify in advance what they need, and then the designers develop
Systems,” 40.
the system according to what is specified. User involvement is lim-
9 Kalle Lyytinen, “Different Perspectives on
ited to providing input to the initial requirement specification. An
Information Systems: Problems and
Solutions,” ACM Computing Surveys 19,
no 1 (1987), 13.
DesignIssues: Volume 28, Number 3 Summer 2012
23

---

obvious disadvantage with this method is therefore that it al ows
little flexibility for changing the course along the way, based on
design suggestions from users.

In contrast, agile methodology is a conceptual framework
for software development that has evolved as a reaction against
“heavyweight” methods like the waterfall model.10 While tradi-
tional waterfall methods are seen as bureaucratic and slow, agile
methods are seen as the opposite. The idea is that short iterations
make the methods receptive to changes in the environment. An
agile approach implies that the developer gives high priority to
satisfying the users’ needs through early and continuous delivery
of valuable software, where changes of requirements are wel-
comed. The method shares some features with prototyping, such
as sketching ideas for user interfaces on paper or computer
screens. However, a crucial difference is that, while prototyping
general y involves representations of a design made before final
artifacts exist,11 agile methods aim to create working software
already from the first delivery. Two major agile methods are Scrum
and Extreme Programming (XP). Scrum focuses on project man-
agement in situations where it is difficult to plan ahead. XP
focuses on best practices for development—for instance, by being
responsive to changes in the environment and developing only
10 Kent Beck, Extreme Programming
what is needed at that time. The planning and design process
Explained, 1.
consists of small releases and iterations that take from one to
11 Kurvinen et al., “Prototyping Social
four weeks. This process is informed by so-called user stories,
Interaction,” 47.
12 Markus Rittenbruch, Gregor McEwan,
which are informal descriptions of feature requests written and
Nigel Ward, Tim Mansfield, and Dominik
prioritized by the customer. As in Participatory Design, involving
Bartenstein, “Extreme Participation –
users in agile methods is considered very important for obtaining
Moving Extreme Programming Towards
good functionality.12
Participatory Design” in Proceeding of

However, health organizations today increasingly have to
Participatory Design Conference PDC
deal with a complex, integrated portfolio of information systems
2002: Inquiring Into the Politics, Contexts
and Practices of Collaborative Design
that support many different cross-organizational practices and
Work (Palo Alto, USA: Computer
thus a heterogeneous array of users. The notion of information
Professionals for Social Responsibility,
infrastructure is a promising framework for analyzing these large-
2002): 29-41, at 29.
scale systems, which are deeply embedded in different practices.13
13 See Susan Leigh Star and Karen
An infrastructure has reach beyond a single event or on-site practice.14
Ruhleder, “Steps toward an Ecology of
Infrastructure: Design and Access for
Accordingly, practices are interconnected with each other to a high
Large Information Spaces,” Information
degree, through both manual procedures and various information
Systems Research 7, no. 1 (1996):
systems. This interconnectedness makes it nearly impossible to
111-34, at 113; and Ole Hanseth and
focus on only one of these systems in (Participatory) Design
Kalle Lyytinen, “Theorizing About the
phases. Another important aspect of information infrastructures is
Design of Information Infrastructures:
that an existing portfolio of information systems (the installed
Design Kernel Theories and Principles,”
Sprouts: Working Papers on Information
base) heavily influences how a new infrastructure can be designed.15
Environments, Systems and Organizations
Many of these systems have different vendors and users, who
4, no. 12 (2004): 207-41, at 208.
14 Bowker and Star, Sorting Things Out, 35.
15 Hanseth and Lyytinen, “Theorizing
about the Design of Information
Infrastructures,” 210.
24
DesignIssues: Volume 28, Number 3 Summer 2012

---

potential y have varied agendas that may diverge from the overall
goal in new design projects. In total, this may influence the extent
to which Participatory Design is possible.

This perspective also chal enges the traditional and rela-
tively homogeneous user role—a key characteristic of the Scandi-
navian Participatory Design tradition. Historical y, this approach
has considered participation a political instrument in the working
class struggle between management and workers, often referred to
as the Scandinavian or critical tradition.16 User participation is
therefore seen as an instrument for maintaining and increasing
workplace democracy.17 Presumptions for this approach included
relatively homogenous workforces, a high level of unionization,
and strong national trade union federations that could play an
active role.18 Instead of considering Participatory Design as a two-
sided struggle between a homogeneous user group and managers,
users should instead be recognized as having specific goals that
reflect the different practices they come from,19 especial y because
different users are expected to work together across organizational
boundaries using infrastructural systems. Bowker and Star remind
us that users from different practices need to negotiate and com-
promise to reach an agreement on the use of certain technologies.20
Method
Our research was mainly carried out at both Well Diagnostics,
later renamed DIPS, and the University Hospital of North Norway
16 Jørgen Bansler, “Systems development
(UNN). Well Diagnostics, a small company with 14 employees, spe-
research in Scandinavia: Three
cialized in systems for communicating and interaction across orga-
theoretical schools,” Scandinavian
nizational boundaries in Norwegian healthcare. During the course
Journal of Information Systems 1 (1989):
of this study, the company was bought by the larger vendor, DIPS,
3–20, at 13.
and the name DIPS is used for both the company and the product
17 Enid Mumford, “Participation—
throughout this paper. UNN is the largest hospital in the northern
from Aristotle to Today” in Beyond
Productivity: Information Systems
region of Norway, with approximately 5,000 employees and 600
Development for Organizational
beds. The hospital has seven laboratories that conduct approxi-
Effectiveness, T. M. A. Bemelmans, ed.,
mately 3 mil ion analyses a year.
(North-Holland, 1984): 95-104.

The study adheres to an interpretive research approach.21
18 Pelle Ehn, “Scandinavian Design: On
Data were gathered from December 2007 to March 2008 and con-
Participation and Skill” in Participatory
Design: Principles and Practices, Douglas
sist of participant observations (work settings and project meet-
Schuler and Aki Namioka, eds. (Hillsdale,
ings), interviews, and informal discussions. The authors conducted
New Jersey; Lawrence Erlbaum
eight in-depth semi-structured and unstructured interviews with
Associates, Inc., 1993): 41-78, at 43.
members of the development team, as well as with pilot users in
19 Bruno Latour, Pandora’s Hope: Essays on
the hospital and in general practice. The first author had an office
the Reality of Science Studies
in DIPS, al owing her to participate in informal discussions (e.g.,
(Cambridge, MA: Harvard University
Press, 1999).
on lunch breaks), which facilitated awareness of emerging situa-
20 Bowker and Star, Sorting Things Out.
tions and issues.
21 Heinz K. Klein and Michael D. Myers,
“A Set of Principles for Conducting and
Evaluating Interpretive Field Studies in
Information Systems,” MIS Quarterly 23,
no. 1 (1999): 67-94, at 70.
DesignIssues: Volume 28, Number 3 Summer 2012
25

---

Establishing Electronic Laboratory Requisitions from
GPs to Hospital Laboratories
The DIPS Interactor project
An internal investigation at UNN, completed in 2002, revealed that
the paper-based laboratory requisitions from GPs in the North
Norwegian health region often contained errors or lacked clinical
information about the particular case. A mismatch often arose
between the content of the paper-based requisition and that of the
sample tube. In addition, manual and repetitive work in receiving
the samples was considered a waste of resources. Because there
were 180 GP practices in total, often with many GPs in each prac-
tice, UNN saw great potential in receiving the requisitions elec-
tronical y. Accordingly in 2006, UNN initiated a two-year project
with the vendor DIPS, with the aim of designing a system for elec-
tronic requisition of laboratory requests. The system was cal ed
DIPS Interactor and enabled GPs to choose and order laboratory
services directly from their computer. An essential part of the
design strategy was to integrate DIPS Interactor with the portfolio
of laboratory systems in the hospital, as well as with the GPs’ elec-
tronic patient records. In the process of laboratory ordering in the
GP practice, the system printed labels with a barcode to be glued
onto the sample tube. The GPs sent the sample tubes using the reg-
ular postal mail or a delivery service, and when the tubes were
received at the laboratory, the barcodes on the sample tubes were
scanned, enabling access to the electronic requisition.

In the following sections, we focus on how user involve-
ment evolved in the three different phases of the development of
DIPS Interactor. Initial y, the project was fairly smal , comprising
only a few manageable user groups. Later, as the vendor experi-
enced increasing success with DIPS Interactor in the healthcare
market, new levels of complexity emerged, resulting in new levels
of chal enges regarding the users’ influence.
First Phase: Starting from Scratch
In their agile development approach, DIPS worked in three-week
iterations, and new versions were downloaded to the users every
three weeks. The first step in an iteration was to col ect user stories
and estimate the work involved in making the features that the
user stories described. According to agile methodologies, user sto-
ries are to be written and prioritized by the customer and serve as
a communication channel between developers and customer. In
the agile methodology, the “customer” general y is understood to
be the actual user of the system. DIPS produces user stories in a
slightly different manner, basing them on requests or feedback
from the users, but letting the development team formulate them.
26
DesignIssues: Volume 28, Number 3 Summer 2012

---

On the hospital side, a user group consisting of physicians
and bioengineers from the Medical Biochemistry laboratory
worked closely with the vendor. On the primary care side, the user
group included GPs, their secretaries, and local laboratory person-
nel. The GPs in particular were identified as key participants
because the success of the project depended on their daily use of
the system. A complicating factor in creating the new system,
however, was that most GPs in Norway are private businesses,
and new technology that does not benefit the GPs directly is
more likely to be rejected. Accordingly, the GPs had to be recruited
careful y, based on both their previous interest in such projects
and their proximity to the vendor and the hospital. In total, 4 GP
practices with a total of 26 ordering physicians in the area around
UNN, were recruited to pilot the system from an early stage of
the development.

With the development of the DIPS Interactor, the vendor
could for the first time implement ful -scale use of agile methods
from the start of the design process. After a short initiation period
of four months, DIPS started to make the very first version of the
DIPS Interactor. The choices about the first functionalities and user
interface were made after discussions among the members of the
project group, and the solution was very simple, satisfying the
minimum requirements for sending an electronic requisition:
Make it as simple as possible to il ustrate the intentions.
When the users start using it, they will see how this
suits their daily work, and they will correct us and give
feedback on how it should be. (Designer, DIPS)
For the GPs, features such as data security, resemblance to paper-
based requisitions, easy access to electronic patient records, elec-
tronic receipt of sent requisitions, status messaging, and access for
all user groups proved to be important. In an iterative way, new
functionalities and user interfaces were added or changed, based
on the feedback stemming from the actual use; gradually, the
resulting product was fully integrated with the GPs’ electronic
patient record, so that only a few extra clicks were needed to pro-
duce and send laboratory requisitions. Although time consuming,
this part of the design process was relatively straightforward. This
progress was auspicious, in that one of the key problems DIPS
encountered when involving users from general practice was their
limited availability for participation in the design process. Because
GPs’ earnings depended on patient consultations, participation in
design projects resulted in a loss of income for them. DIPS there-
fore decided to pay the GPs on an hourly basis to participate in the
first phase of the design project. Subsequent involvement has been
based on GPs’ interest in the product and wil ingness to leave their
workplace for short periods.
DesignIssues: Volume 28, Number 3 Summer 2012
27

---

Second Phase: Encountering a New Level of Complexity in
the Laboratories
After the initial phase, the designers encountered a much more
complex situation in the hospital laboratories. The different labora-
tories at UNN had different laboratory information systems, mak-
ing it necessary for DIPS to col aborate with the vendors of these
systems to establish a wel -functioning integration for the DIPS
Interactor. Basical y, DIPS depended on the adaptation by the other
vendors of their systems, and this adaptation was not always given
priority. For instance, when the microbiology laboratory was to be
integrated with the DIPS Interactor, the vendor of the microbiology
system encountered delays in receiving the parts of the systems
that were needed for using electronic requisitions. Another vendor
had shifted its priority to upgrading other parts of the system. This
reprioritizing and delays caused some frustration among the DIPS
designers. One of them complained:
…they [the other vendors] have their own agendas and
their own products. And we, who have to make it work
together, are often dependent on their priorities. That
is the problem: to get a reaction from the vendors.
(Designer, DIPS)
After the microbiology laboratory was included, another complex
issue emerged. Managers of the laboratory saw the potential for
using the DIPS Interactor to control the volume of requisitions
from the GPs. In Norway, GPs have a reimbursement system that
provides incentives for ordering more laboratory tests; hence, these
users wanted a system that would make it as easy as possible for
them to order laboratory tests. In contrast, the hospital laboratories
are financed mainly through a general grant, and an increase in
laboratory orders from the GPs increases the costs to the laborato-
ries but not their income. As a result, the hospital wanted to
receive fewer orders from the GPs, and the laboratory staff wanted
to incorporate a message showing the hospital’s cost for each anal-
ysis that the GP ordered in the system. The intent was to encourage
GPs to think twice before ordering particularly costly analyses.
The laboratory staff’s goal generated much resistance among the
GPs, and ultimately the vendor sided with the GPs, which effec-
tively terminated the idea. One of the designers commented:
If we use two months to enforce some functionality
requested by the laboratory, but that we know will meet
resistance out there [in primary care], then it is wasted.
(Designer, DIPS)
Moreover, the different practices in the medical biochemistry and
microbiology laboratories resulted in different requirements for
the design of the requisition forms. These design schemes contain
28
DesignIssues: Volume 28, Number 3 Summer 2012

---

the analyses offered by the laboratories and appear in the GPs’
user interface in the ordering process. While the medical biochem-
istry laboratory required a minimum of clinical information from
the ordering physicians, the microbiology laboratory required
extensive clinical information. The different requirements, in turn,
required that the requisition schemes and the presentation on the
GPs’ screens could be tailored to each laboratory’s need. The medi-
cal biochemistry laboratory started out as the first laboratory, and
the vendor edited the requisition schemes manually. However,
when the microbiology laboratory was about to start, the vendor
realized the need for a more flexible editing tool—one that would
al ow each laboratory to design the requisition schemes and pre-
sentation on the screen to suit its specific needs. The vendor there-
fore devoted considerable resources to developing such a tool.
Nevertheless, the users in the laboratories faced some core chal-
lenges in the design of the requisition schemes. They had to define
the content of the requisition schemes, but they did not know how
this information could best be presented to match the GPs’ work
process. However, because the GPs were not a homogenous user
group, they had different ideas about how the offered services
should be organized. Some GPs preferred a structure correspond-
ing to the former paper-based ordering forms; others preferred a
layout based on organs of the body, while others suggested a com-
pletely new structure enabled by the new technology.
Third Phase: Commercialization and Increased Distance from the Users
The number of users has been increasing, and 13 offices in the
northern health region presently use the DIPS Interactor to order
laboratory services electronical y at UNN. In addition, nine other
Norwegian hospitals, including each hospital’s associated GPs,
have started to use the system.

The escalation of the product scope required extensive
cooperation between the vendor and several general practices, hos-
pitals, and other vendors. It also required cooperation among the
different actors in the healthcare organizations. The new custom-
ers (the nine other hospitals) bought what had been developed at
the time of purchase, and from then on, they were part of the fur-
ther design of the system. This larger market imposed new chal-
lenges for the vendor because there were several new customers to
relate to and a much larger number of users. Faced with a system
that included many different user groups, each with different ways
of using the system and limited time to spend on design, the devel-
opment team needed to find ways to enable all users’ voices to be
heard. More people at DIPS needed to get involved, especial y in
the marketing group. For each customer, DIPS appointed an inter-
nal project leader for the adjustments and implementation phase.
The project leaders stayed in close contact with their customers
DesignIssues: Volume 28, Number 3 Summer 2012
29

---

and took care of technical problems, as well as acting as the cus-
tomer proxy in the development team. This process was chal eng-
ing, as the person responsible for marketing of DIPS recal ed:
When we started out at the University Hospital of
Akershus, I had a hotline to the designer 24 hours a
day because I did not know the product. There were so
many errors that we did not foresee, but we learned.
Now I feel that I can manage much more on my own.
Stil , the marketing people did not have detailed technical knowl-
edge of the system and encountered chal enges in responding to
users’ problems. The long-term consequences were that the users
increasingly lost contact with the developers, which diminished
the users’ ability to influence the process.

The large number of users resulted in an increasing number
of new user stories. Some stories were of general interest while
others were based on the specific needs of one particular user. The
designers also had to make choices between user stories that
entailed new functionalities the customers would pay to get, and
improvement of old ones with no incoming cash flow. Although
the users thus far have been able to contact the designers or mar-
keting people directly with feedback or needs, the need might
soon arise for a system that al ows user proxies (e.g., marketing
personnel) to col ect and refine user stories before they go to the
design team for development. This change would increase the dis-
tance between users and designers even more.
Discussion
Complex Organizational Issues: Limitations for Participatory Design
In many organizations, new information systems are supposed to
be integrated and able to play along with the organizations’ exist-
ing information systems portfolios. This need for compatibility
implies that existing technological and organizational constraints
might shape the design flexibility of the new system—and conse-
quently, the degree to which Participatory Design is possible.22 In
this project, as the scope of the DIPS Interactor project grew, such
consequences became apparent. Over several years, the laborato-
ries at UNN had built up a wel -functioning laboratory infrastruc-
ture with a high degree of integration and mutual dependencies
among different laboratory systems, analysis machines, proce-
dures, and more. This complexity made it nearly impossible for
single user groups to have a ful overview of the possibilities, the
constraints, and not least, the consequences of user requests. Con-
sequently, because of the inter-organizational scope of the project,
maintaining this overview was very much up to the vendor, DIPS,
22 Bowker and Star, Sorting Things Out, 35
and not up to the users. Also hampering user participation was
and Hanseth and Lyytinen, “Theorizing
about the Design of Information
Infrastructures,” 214.
30
DesignIssues: Volume 28, Number 3 Summer 2012

---

that a wel -functioning DIPS Interactor depended on integration
with different systems delivered by other vendors. These vendors
did not share the interest of DIPS in attending to the DIPS Interac-
tor users; instead, they were primarily concerned about their own
market segments and completely different user groups. The extent
to which these vendors implemented anything resulted not from
the requests of the users of the DIPS Interactor, but rather from
their col aboration with the product’s vendor. In addition, because
several user groups were involved, that users in these different
groups would be granted the influence they wanted was far from a
given. Sometimes the interests of these different users were
directly opposed to each other, including when the many user
groups in the GP practices had different preferences for the layout
of the requisition schemes designed by the laboratory users. A
final point is that on the way to commercialization of the DIPS
Interactor, many new hospitals and practices have been involved,
thus building a larger user mass. This growth has increased the
pressure on the vendor to handle a larger number of user requests.
The vendor has responded to this demand by building up an orga-
nization and an infrastructure to receive and coordinate these
requests. This capability obviously is necessary, but at the same
time, it creates greater distance between the vendor and the users,
making the vendor’s agile approach more difficult.
The Chal enge of Mobilizing Participation in an Integrated Environment
A cornerstone of Participatory Design is to include users in the
decision-making for the design of new systems.23 However, this
goal presupposes that the users are interested in taking part in the
process, which basical y reflects the extent to which users find the
new system beneficial. When a system is developed for a single
work practice, the benefits for users might be quite clear. In con-
trast, in an inter-organizational setting with many stakeholders,
the benefits may not be evenly distributed, inducing some user
groups to question whether participation is worthwhile.

In this project, the users in the laboratories were easy to
engage because they saw the potential for quality and efficiency
improvement. This interest was also reflected in the fact that the
hospital staff had initiated the project, together with the vendor. In
contrast, the vendor experienced greater difficulty in involving the
GPs—not because the GPs did not find the DIPS Interactor useful,
but simply because they did not find it useful enough. Norwegian
GPs are self-employed, and time spent participating in the project
meant lost income. To handle this situation, the vendor chose to
pay out of its own pocket to compensate them for participating.
Although this approach ensured that knowledge about the GPs’
23 Bjerknes and Bratteteig, “User
practice was conveyed to the designers, it simultaneously raised
Participation and Democracy, 73 and
Bansler, “Systems Development
Research in Scandinavia.
DesignIssues: Volume 28, Number 3 Summer 2012
31

---

some critical issues about the degree of user influence: If users
are paid to participate, how much influence do they real y have?
Because of both the compensation and the fact that the hospital
was the actual customer, the conclusion might be that GPs had
little real influence. Consider an observation from one of the
designers in DIPS, who clearly ascribes the central power to the
hospital:It is business, of course. If the hospital is very strict on
what they want, and has paid for the solution, then we
have to yield. (Designer, DIPS)
Stil , the situation is more complex than this observation suggests.
Although the laboratory staff ostensibly exercised greater influ-
ence over the design of the DIPS Interactor than the GPs, the hospi-
tal still depended on the GPs to use the system. In this sense, the
GPs exercised substantial influence in relation to the laboratories
because they could send their laboratory requests to other hospi-
tals if they were dissatisfied with the services the hospital pro-
vided through the DIPS client. Accordingly, the laboratory staff
had to design the requisition schemes in line with what the GPs
wanted. In this way, the user and designer roles were not explicitly
given but entailed more of a relational approach.24 For instance, the
laboratory staff had both a user role and a designer role, depend-
ing on the ones with whom they were interacting.
The Vendor Role: Taking a Stand on Organizational Consequences
According to agile development methods, the customer is the one
making and prioritizing user stories, leaving vendors in a neutral
position in which they design what the customer or users want,
within the range of what is technological y possible. This position
is chal enged in many science and technology studies, as well as in
the Participatory Design research community.25 We believe that the
political aspects come to the fore as the design projects grow in
size and scope and that these political aspects also become more
apparent in the case of the vendor role:
There are examples where the hospital has made an
organizational change and we [the designers] find
ourselves in the middle of debates about personnel in
the hospital. (Designer, DIPS)
Accordingly, different and potential y conflicting issues force ven-
dors to take a stand and side with specific user perspectives. One
il ustration of such a situation is when the microbiology laboratory
wanted to include a feature in the system presenting the costs of
expensive analysis to the GPs before the GPs could order the anal-
ysis. Although this feature made perfect sense for the laboratory
24 Latour,
Pandora’s Hope.
carrying the financial burden, the GPs felt that it represented a
25 Wagner, “A Web of Fuzzy Problems,”
100.
32
DesignIssues: Volume 28, Number 3 Summer 2012

---

kind of monitoring of their work that they did not want. In this
case, the vendor sided with the GPs and convinced the laboratory
not to insist on this feature. One of the designers at DIPS elabo-
rated on what he perceived the vendor’s role to be in such matters:
We are not impartial; we listen to the arguments and
decide what sounds reasonable. Then one may lobby for
one or the other [. .] Then it becomes our role as mediator in
the middle to try to tell them what is the most convenient
thing to do.
Consequently, vendors have to maneuver careful y among differ-
ent user groups, sometimes serving as a go-between and some-
times siding with one of the groups. This mediation role imposes a
particular responsibility on vendors to understand the different
perspectives and to try to find a middle way. Of course, vendors
also must recognize an issue of self-interest. They know that
ensuring that all user groups in an integrated setting are satisfied
is important for them to keep their product in the market. If one of
the groups (e.g., the GPs) refuses to play its part in an integrated
environment, the value for the other participant is at risk, clearly
highlighting that a networked environment is not stronger than its
weakest link.26
Conclusion
The aim of this paper has been to elaborate on some of the chal-
lenges of involving users in the design of evolving information
systems, including chal enges for vendors committing themselves
to agile methods. We have shown that mobilizing the users in the
design process can be a chal enge in itself, particularly when a sys-
tem spans several organizations and when only one of these orga-
nizations is the actual customer of the system. We have also shown
that Participatory Design can be a chal enge when the system in
question has to be integrated with other systems. In addition, as
development projects and systems increase in size and scope, we
also believe that the neutral vendor role ascribed in agile methods
vanishes. Throughout the design process, vendors sometimes have
to deal with problematic organizational issues and consequences.
On this basis, we promote design as an activity that is col ectively
negotiated among many stakeholders. Here, the roles between
designers and users are not automatically given or fixed but
depend on the mutuality of the relationships among the stakehold-
ers. In turn, the nature of the roles can vary, depending on the
26 Bruno Latour, Science in Action (Harvard
phase of the design process, possibly resulting in greater influence
University Press, 1987), 124.
given to users in the early stages and less in later ones.
DesignIssues: Volume 28, Number 3 Summer 2012
33

---