Draft chapter for the book: "Reframing Humans in Information Systems De-
To be published by: Springer (2010/2011).
Editors: Hannakaisa Isomäki & Samuli Pekkola
Keld Bødker, Finn Kensing and Jesper Simonsen
Participatory Design in Information Systems Development
This chapter deals with IT design in an organizational setting - be it a medium
sized service company, a large industrial company, a small entrepreneurial
knowledge company, or a public company or institution. In such work set-
tings we often find a complex organizational structure, including several
management levels, diverse professional groups, workplace cultures, and es-
tablished working relations where new IT projects challenge the established
ways-of-working. This is also the domain of ‘classic’ information systems de-
velopment (ISD) approaches. This chapter presents the principles, key ideas,
and experiences from using the participatory design method known as the
, developed by the authors (Bødker et al., 2004).
Iivari et al. (2009) identify three fields where system development has been
the topic of research: Software Engineering (SE), Information Systems (IS),
and Human Computer Interaction (HCI). User involvement has not been the
topic of research in SE, but the topic is well researched in IS and HCI. Howev-
er, Iiavari et al. (2009) note as an important aspect that the literature is not
clear on how user involvement should be integrated with current approaches
to system development: While agile methods include ways of incorporating
customer requirements, Ballejos and Montagna (2008) demonstrate that they
fail to support stakeholder identification; DeMichelis et al. (1998) show limita-
tions towards the design and management of organizational change; and
Coughlan and Macredie (2002) illustrate insufficiencies in negotiations of re-
quirements between different stakeholder and user groups.
In this chapter, we describe the participatory design approach, presented by
Bødker et al. 2004, illustrating how to engage which users in what type of de-
The MUST method is a ‘meta-method’ providing resources that has to be ap-
plied specifically to a situated IT design project. The method provides four
types of resources: Concepts for the designer to understand and frame the sit-
MUST is a Danish acronym for initial participatory design activities
uation, principles forming the backbone of the method, suggestions for how to
organize the design project, and finally, a toolbox of techniques and presenta-
tion tools to support the various activities, see figure 1.
Figure 1: Four types of resources for IT design using the MUST method
In the remaining part of the introductory section our interpretation of the
concept of design is discussed. Section two discusses the most central concept -
the user. Who is the user, and how can we identify and include them in design
activities? Section three describes the four principles that form the backbone of
the MUST method – illustrated by small vignettes from industrial projects.
We use the vignettes to illustrate condensed experience describing typical sit-
uations or challenges faced in specific situations. Each vignette is identified by
a number. Space does not allow for a thorough description of how to organize
the design project according to clearly identified decision points, let alone the
techniques and tools. For further details please see Bødker et al. (2004). Sec-
tion four compares the MUST method to other methods and approaches. Sec-
tion five concludes the chapter by discussing implications for industry, educa-
tion, and research.
What Is IT Design?
Our understanding of IT design and design activities in relation to an overall
IT project is inspired by better established design traditions, such as architec-
ture. In architecture architects analyze clients’ wishes and needs, designing a
building’s form and function over several iterations taking an appreciation of
the context into account. At first they design at a general and conceptual level,
then in greater detail – in order to develop design ideas and prepare the con-
In the construction industry, traditions and experience have developed over
centuries, stipulating how the construction process is conducted and how ar-
chitects cooperate with the client and the many trade groups that, at one time
or another, are drawn into a construction project. Over many years, a wealth
of experiences has been gained and overall standards have been established
in many areas of the construction process for example regarding division of
work, as well as in terms of the content and detail of various specifications
developed in the process. No such tradition exists in the IT world. A marked
difference is the construction industry’s established interfaces between phas-
es, enabling calls for tenders to be issued at several different points and with
varying scope. For example, many large projects start by pre-qualifying a
small number of architects who then for a small budget is asked to develop
their design for an architectural competition. The winner is then awarded the
project, and more detailed design is carried out. At a later stage another call
for tenders is opened based on a detailed design for the construction, and the
winner is awarded the contract for the construction of the building. There is
currently no such tradition in IT projects. So far, IT projects do not involve
tenders similar to architectural competitions, in which a series of pre-qualified
firms – for a fee – are invited to submit bids for possible solutions based on
the client’s designated needs.
We understand IT design as similar to the activities of architects in the con-
struction industry: Initial activities of analysis and design that outline visions
for future IT usage and support decisions about which visions best meet
business goals and user needs for IT support in their work. An IT design pro-
ject thus constitutes an important element in an organizational clarification
process leading to visions for one or more sustainable uses of IT. An explicit
upfront design component of an IT project is important. This can be realized
in many ways. In most projects, it is necessary to divide an IT project into a
design project and an implementation project, separated by a call for tenders,
see figure 2. In fact, this is the case with all large public IT projects in Europe
according to the European Union rules for invitations to tender and award
contracts. This model is used as a reference for identifying the IT design pro-
ject throughout this chapter. The MUST method, including its techniques and
presentation tools, may be used in other contexts as well. For example, prod-
uct development companies may use the method when they prepare pro-
posals for implementation of their generic IT products for potential custom-
The IT designer is defined as the professional actor responsible for the IT de-
sign project, underscoring the importance of the element of design in such
projects and, in turn, the analogy to the function of the architect in construc-
tion. The MUST method provides a perspective on IT design that takes a
broad view of IT usage. This involves situating IT systems within the work
organization context of which they will be part, and considering also what
new qualifications will be required for users to contribute to desired changes.
An important characteristic is the extensive participation of humans – that is,
the management and the future users of new IT systems, along with any in-
ternal IT designers who will be participating in the implementation.
IT design project
Design project report
mmm mmmm mmmmmm
m mmm mmmmmmm mm
mm m mmmm
mm mmmmmm mmmm
mm mmm mmmmm mm
mm mmmmmm mmm
mm mmm mm
Figure 2: Model of an IT project
An IT design project, or design project for short, will produce a foundation for
deciding how to undertake implementation projects. An IT design project is
defined as a project identifying problems, clarifying goals, and outlining solutions.
• Analyzing the company’s business and IT strategies, as well as its pre-
sent goals, needs, and potentials as seen by the management and the
future users of new IT systems.
• Designing one or more visions for overall change.
• Aligning the design visions in relation to the company’s business and
• Setting down a strategy and plan for technical and organizational im-
plementation, including cost estimates.
• Guaranteeing continued feedback from all relevant stakeholders.
The result of an IT design project is a report outlining one or more coherent
visions for change in terms of technology, work organization, and required
employee qualifications. The report may be supplemented by prototypes or
(foam) mock-ups of any digital gadgets (Halse, 2008). Moreover, the report
includes an evaluation of the effects of implementing the visions, a cost esti-
mate, along with a strategy and plan for implementing the visions. The report
is the basis for a decision about implementation projects. This decision is typi-
cally followed by a call for tender and contract negotiations with the chosen
supplier(s) that will be implementing the changes, including the IT systems.
Goals, needs, potentials
and proposed solutions
Figure 3: The role of visions in a company’s IT projects
One or several implementation projects can then be conducted in cooperation
with the chosen supplier. The goal of the implementation projects is to per-
form the technical and organizational implementation of the chosen visions
based on the design project. This will typically be done in a series of itera-
tions, see figure 3. A vision outlines guidelines for the implementation
through the documentation of goals, needs and potentials as well as through
the proposed solutions. After an implementation project, or at other points in
time, it is possible to evaluate achieved results in relation to the listed visions.
Due to for example new solutions or problems emerging in the implementa-
tion project, parts of a vision may be revised as the result of an evaluation
leading to a new foundation for succeeding implementation projects. Or an
evaluation may result in a decision that a goal that was not met in the first
implementation project is reformulated and set up for the next implementa-
2. The Concept of ‘User’ in Participatory Design.
A central contribution from the Scandinavian approaches to Participatory De-
sign and Information System Development is the elaborate understanding of
the user. Contrary to well known approaches like for example Contextual De-
sign (Beyer and Holtzblatt, 1998) that only talks about the ‘customer’, it is rel-
evant to make several distinctions focusing not only on the relation between
humans and the technology, but also to differentiate between:
• The user, who applies the technology for certain purposes versus the
customer who orders and pays for it. In projects for very small compa-
nies they may be the same, but typically they are not - having some-
times very different sets of needs and goals for it support for their
• Employees and management. IT design is also a political process involv-
ing conflicts and dilemmas. The resources offered by a method in
terms of general principles, tools, and techniques etc. need to reflect
• People having first-, second- and third-hand knowledge of use-processes.
This entails consequences for the tools and techniques that are helpful
and relevant to apply in bringing that knowledge to bear.
The premise of our participatory design method is that all types of users of a
new system must be involved in different ways in the design of the relevant
parts of a system.
User versus Customer
Beyer and Holtzblatt (1998) present Contextual Design in which the
´customer’ is defined as “anyone who uses or depends on a system.” Custom-
er is considered more inclusive than user, “which we'll use only for those who
interact with the system directly” (ibid, p. 2). We may endorse the latter defi-
nition of users, while we do not talk about 'customer'. If we did, it would
most likely refer to management, as customers in Beyer and Holtzblatt’s vo-
cabulary are those who pay for the system to be delivered.
When designing for workplace settings, users should explicitly be distin-
guished from the customer. They have different roles and competencies in or-
ganizational life in general and more specifically in IT design projects. Blur-
ring such a distinction makes it harder for the IT designers to figure out who
should be involved in which activities, how, and for what purpose (Kensing
et al, 1998b, p.175; Bødker, Kensing and Simonsen, 2004, p. 75-79). In many
projects in larger companies, users from different organizational units, or
from different professional groups, will also have diverging sets of needs and
requirements for it support. In such circumstances the designer needs to be
able to identify the different groups and their needs, and further to see that
conflicts are dealt with and negotiated in a professional and transparent man-
ner. Further, in larger companies it is often useful to consider also the needs
of the company’s external suppliers and customers, who may or may not “in-
teract with the system directly”. If they do, we would treat them as user
groups. If they do not, we would treat them as important stakeholders, which
again leads to other considerations about who should be involved in which
activities, and for what purposes.
Employees versus Management
With the distinction between employees and management the MUST method
stresses the differences in terms of power and other resources available to the
two groups respectively. Participatory Design (PD) have argued for user par-
ticipation and suggested concrete techniques for this (as discussed in Kensing
and Blomberg (1998), while IS researchers and IS methodologies traditionally
have been more concerned with finding ways for IT specialists to produce ba-
sis for decisions relevant for managers.
Clement and Van den Besselaar (1993), in a review of ten PD projects, reiter-
ate three basic requirements for participation outlined by Kensing (1983): (1)
access to relevant information, (2) the possibility for taking an independent
position on the problems, and (3) participation in decision making adding
two additional requirements: (4) the availability of appropriate participatory
development methods and (5) room for alternative technical and/or organiza-
tional arrangements. The participation of the intended users in IT design is
seen as one of the preconditions for good design. Making room for the skills,
experiences, and interests of employees in system design is thought to in-
crease the likelihood that the systems will be useful and well integrated into
the work practices of the organization. Of central importance is the develop-
ment of meaningful and productive relations between those charged with
technology design and those who, as users, must live with its consequences.
PD researchers hold that design professionals need knowledge of the actual
use context, and the employees need knowledge of possible technological op-
tions. The epistemological stand of PD is that these types of knowledge are
developed most effectively through active cooperation between the different
user groups and designers within specific design projects.
The appraisal of which organizational members should be involved in IT de-
sign and implementation has changed over time. In the early days of PD, the
central concern was to increase the participation of workers and their unions
or those with little say over technological and organizational design issues
affecting the workplace. Managers rarely participated in these projects. Even
today the role of management in PD projects is sometimes intentionally re-
stricted. Some have worried that management’s participation would silence
the voices of employees and undermine the goal of their influence in working
conditions. Bødker (1996) reports that while managers participated in some
seminars and meetings during the course of an IT project, they were asked
not to take part in a future workshop because their presence would make em-
ployees reluctant to express their views honestly.
Increasingly, however, people positioned throughout the organizational hier-
archy (including management) and with various relations to the IT design ef-
fort are included in PD projects. Kensing et al. (1998a) report on a project in
which the participation of managers, internal design professionals, and users
was considered a core condition for the success of the project. Korpela et al.
(1998) argue for the need to involve community members who will be served
by the system under development and not solely end users. In a discussion of
PD in consulting, Gärtner (1998) reports: “Customers [those funding the pro-
ject] will support and pay [for the project] only if they consider risks involved
to be acceptable with respect to expected outcome.” In this case the involve-
ment of the funding managers was required to secure the resources needed
for the project to move forward.
First versus Second and Third Hand Knowledge
First hand knowledge of a given work practice is obtained by actually per-
forming or experiencing it. Second hand knowledge is the result of being in-
formed of the work practice for example by interviewing the employee per-
forming the work. Third hand knowledge is the result of for example inter-
viewing the manager of a work group, who knows about the work from in-
teractions with his employees. The point with this distinction is that all too
often the designers, who are concerned with “getting the requirements right”
or “developing a proper understanding of users’ needs and concerns”, rely
primarily on second or third hand knowledge of the work context and daily
practices that an IT system is designed to support, reorganize, substitute, or
create. The reason is that it is often considered too costly or too cumbersome
to become involved with the employees who actually perform the job. They
may have different or even conflicting needs or interests. This is exactly why
it is important to get to know what these are and why. Because needs and in-
terests do not disappear – people will relate to new IT systems based on such
needs and interests.
“Not getting the requirements right” is among the primary reasons for unsuc-
cessful it projects (Schmidt et al., 2001). Our position is that it is - in this light -
less costly and cumbersome to have IT designers experience users’ work prac-
tices first hand when dealt with by proper tools and techniques, and with an
open attitude towards how to deal with conflicts. As described below, the
principle of firsthand experiences with work practices prescribes observations
of users in as genuine situations as possible. This should be viewed not in
contrast to, but rather as supplement to the conventional data gathering ap-
3. Four General Principles for Human Participation in IT Design
This section outlines four general principles for human participation in IT de-
sign that are indispensable for all participatory approaches. The principles
express an overall perspective built into the MUST method and into the par-
ticipatory design projects where the method is used. Applying the four prin-
ciples implies a reframing of humans as compared to contemporary ISD ap-
proaches. The principles concern (1) the development of a coherent vision; (2)
ensuring genuine user participation; (3) experiencing work practices first-
hand; and (4) anchoring the visions with different users and stakeholders. The
principles, and how they have been implemented in real-life projects, are il-
lustrated by giving small vignettes from a number of practical cases and expe-
riences from industry. For each principle we state the basic critical factors for
achieving the principle based upon our experience.
The Principle of Coherent Vision for Change
A design project is carried out in a company with the aim of designing sus-
tainable IT usage that accommodates the company’s current goals and needs,
enabling growth without jeopardizing its future development potential. Ac-
cordingly, IT usage should contribute to a balance of a company’s resources -
staff members, with their qualifications and experiences, its financial founda-
tion and technology (including IT). For instance, the information systems
should enable staff members to utilize and continue to develop their qualifica-
tions when handling their tasks. The design project should thus strive for sus-
tainable visions, in the sense that the applications should contribute to obtain-
ing a balance between the development, utilization, and protection of the re-
sources of the organization.
The result of any design project is one or more coherent visions for change in
the company in question and in relation to its environment. The proposed
change should meet the company's revealed goals, needs, and opportunities
within its business and IT strategy – which may itself need revisions as part of
the project. With coherent we mean that the following three elements of an IT
application are designed so that they each and in combination support the vi-
sion: (1) IT systems, (2) work organization, and (3) the qualifications users
need to perform their job with the help of the proposed IT systems in the pro-
posed work organization, see figure 4.
A basic, but critical, factor for this is that the customer, the person(s) commis-
sioning the design project, accept that these issues are dealt with in the pro-
Figure 4: Three elements of a coherent vision.
A large-scale design project was conducted in order to change the production technology at a
national radio station from analogue to digital technologies (Kensing et al., 1998a). Three
activites had a particularly relevance to the principle of coherent vision of change: Visiting
other radio stations, developing scenarios and developing and testing prototypes. Early in the
project two radio stations in Europe were visited where they used state-of-the-art digital
technologies for radio production. The project group observed the radio production throughout
one day and made video recordings. The video recordings documented the organization of work
using the digital technologies. For example the traditional division of work between journalists
and technicians was changed; journalists’ selection of music was automated by using selection-
programs, and parts of the program to be broadcasted during the night was prerecorded during
daytime. The design visions were presented with prototypes and scenarios. The scenarios were
written by the journalists who participated in the design project. In these scenarios they
emphasized how management might use the new technologies to direct requests for coverage of
specific events directly to the journalists and subsequently monitor the production right up to
broadcasting – by having access to the material during the entire production process. Prototypes
were developed with “make public” buttons illustrating how the journalists could allow
management access to the material. Prototypes were distibuted to all 140 employees and
management at the radio station where they could interact with the proposed user interface for
the envisioned systems. This way journalists and other groups could envision and to some
degree experience the technology and how it might be used.
The Principle of Genuine User Participation
In many IT projects, the aim and focus of user participation are unclear. As a
result, participation may be handled in ways that do not afford users oppor-
tunities to develop and express their needs, ideas, and visions for IT usage. If
users’ participation is limited to serving as informants, for instance, in inter-
views about their work and IT needs, or to taking part in systems testing, or if
participation is limited to middle managers or executives, who may excel at
representing the company’s overarching goals for the project there is little
chance that the resulting systems cover the users’ actual needs. Such projects
lacks the insight into day-to-day routines, including what factors may be
complicating the work or what useful alternatives could be.
The principle of genuine user participation calls for the active participation of
user representatives influencing the process of design as well as the visions it
results in. There are two rationales for this, a pragmatic and a political. The
pragmatic arguments rest on the need for mutual learning between users and
IT designers: IT designers need knowledge about the work environment that
is the domain of the design project, and users need knowledge about techno-
logical options. That end is most effectively attained by organizing activities
that enable the two groups to learn from each other. Users can contribute in-
novative and constructive suggestions for change when they have the right
conditions for doing so. The political arguments revolve around the users’
right to influence their own working conditions, which are often significantly
affected by IT projects. Modern companies rely on professionals, i.e. highly
skilled, autonomous, and knowledgeable employees. Consequently, it is a
core HR strategy to ensure staff members’ influence on their own working
conditions and working environment in order to keep (and attract) competent
and ambitious staff members.
One should also note that in most real-life projects the user community is so
large and diverse that the IT designer must rely on representatives of users to
be involved in a design project. Thus, the selection of representatives becomes
a crucial element in the design project, where compromises have to be made.
Often there is a wish to include experienced persons capable of thinking out-
of-the-box who are also well respected by their colleagues. However, in the
daily business these people are busy and in short demand.
Genuine user participation increases the potential of visions produced by a
design project to reflect the users’ true situation and needs. And it further in-
creases the potentials of the systems to be used according to their intentions.
A basic critical factor is that sufficient time and resources are set aside for this
(Clements and Van den Besselaar, 1993).
A design project was conducted by a large IT vendor to improve clinicians’ overview of patients
at intensive care units. A series of workshops were conducted where nurses and physicians from
three intensive care units participated in designing the system. During these workshops, the
physicians repeatedly stressed the importance of having graphical representations of results
from the ongoing samples and measurements (blood pressure, oxygen levels, temperature, pulse
rate, etc.). Much effort was directed to the design of different types of graphs, their colors,
forms, configurability, etc. These representations constituted a major resource of developing the
system. When the system was implemented and evaluated it was observed that the graphical
representations were almost never used. It turned out, that the practical measurements and on-
going monitoring of the patients’ vital parameters was conducted by the nurses – and they did
not use or appreciate graphical representations. In stead they measured and recorded the actual
measurements and used the actual figures on the forms and charts to maintain the status of their
overview of the patients. The physicians’ statements represented second-hand knowledge of the
work processes conducted by nurses. Due to their different ranks in the hierarchy, the nurses did
not object to the design requirements voiced by the physicians. From this project the vendor
learned that they had to claim an influence on who the customer put at the disposal for the
design workshops and to insist on having users with first-hand knowledge of the work processes
in question present – without they are compromised by second-hand or third-hand users with
higher rank or management-like status.
The Principle of Firsthand Experience with Work Practices
There are three different ways, basically, of obtaining new insight into subject
matters relevant to a design project. You can read up on the subject, you can
ask knowledgeable people to tell you about it and, finally, you can put your-
self in a situation where you experience the subject firsthand. The first two
ways are most commonly used in ISD methods in general, and they reflect
second-hand or third-hand knowledge. This implies descriptions of work in
terms of processes and procedures reflecting an ideal work flow. This is dif-
ferent from how the work is actually carried out as pointed out by Suchman:
Users act in a situation and do not follow plans and procedures in any narrow
sense (Suchman, 1983; Suchman, 1987). Thus, there is a need to also include
firsthand experiences. A major tenet of this principle is that work is a socially
organized activity where the actual behavior differs from how it is described,
prescribed, or envisioned.
Ethnographically inspired observations are the primary means to realize the
principle. In a design context the aim of ethnography is to develop a thorough
understanding of work practices as a basis for the design of IT systems (Si-
monsen and Kensing, 1997; Simonsen and Kensing, 1998; Simonsen 2009). Us-
ing ethnography in design has been acknowledged especially within the
fields of Participatory Design, e.g. (Greenbaum and Kyng, 1991; Schuler and
Namioka, 1993; Bødker et al., 2004) and Computer Supported Cooperative
Work (CSCW), e.g. (Sommerville et al., 1992; Hughes et al., 1993; Luff et al.,
The principle of firsthand experience implies that studies of work practices
must include observations, and possibly supported by video analyses. The
work practices include existing work practices (users performing their regular
business prior to system implementation) or new envisioned work practices
(users trying out prototypes in situations as realistic as possible, or visits to
other companies where similar technologies are in use). An obvious critical
factor for this principle is to get access to the relevant work practices. Often
this includes negotiations with management and/or the work groups to es-
tablish the conditions. In some design projects however, there is no current
work practice, i.e. in projects dealing with radical new products or in new
domains. In such projects we may have to “create the work practice” by simu-
lating work and IT tools by prototyping and enacting scenarios.
A design project included the design of IT support for the production manager and for the
editors from the Danish Film Institute (Simonsen and Kensing, 1997). From the beginning, it
was voiced that “everybody should be able to see all information in the system.” After we had
observed the editors for some time, they became confidential with us and suddenly – at a follow
up interview – one of them entrusted in us that there was a (legitimate but manifest) conflict
between the production manager and the editors who all had a budget for their area: complete
openness of all information in the system would favor the production manager and weaken the
editor’s influence in the organization. For example, financial support of productions considered
by the editors should be strictly confidential. None of the editors' personal calculations (about
which productions they were considering to fund and with how much) should be public unless
made so by the editor managing the production. If this part of the system was open to all, the
editors simply would not use it for this complex task. We had to carefully contemplate how to
bring up this issue without taking part in the conflict. We decided to present two alternative
design proposals: One implicitly in favor of the production manager and one explicitly
supporting the editors, who had confided in us. At a steering committee meeting the proposal
supporting the editors was chosen – though not without controversies.
The Principle of Anchoring Visions
The anchoring principle means ensuring that stakeholders understand and
support the design project’s goals, visions, and plans. Involving and inform-
ing relevant stakeholders is a key issue in ISD, especially with regard to top
management and the staff of involved sections. Top management involve-
ment and the development of strong relationships with top management con-
tinue to be reported as the uttermost important challenge within IS, see for
example (Xia and Lee, 2004) and (Schmidt et al., 2001).
In a design project, the project group develops various representations of the
existing situation and visions of desired changes. Such representations are
perceived and interpreted individually and differently by the people to whom
they are presented. An important means of anchoring is to communicate rep-
resentations that provide the most coherent image, as interpreted by the pro-
ject group, to other relevant stakeholders that are not directly involved in the
project. The principle of anchoring visions focuses on three stakeholder
groups: (1) (top) management, who has the power to decide whether or not
the proposed visions will be implemented, (2) employees and other interested
parties, who will either use the IT systems in question or be effected by them,
and (3) internal and external groups that at a later stage become involved in
the technical and organizational implementation of the proposed visions.
Anchoring visions encompasses informing about and promoting understand-
ing and backing for the relevance of the design project and its goals and vi-
sions. This includes inviting stakeholders to discuss, review, challenge, and
reformulate the project groups’ arguments for how a specific IT-based pro-
posal solves an experienced problem or supports an important business need.
The principle prescribes that stakeholders must be informed and involved in
various ways to be able to evaluate the consequences of the proposed chang-
es, as seen from each of their perspectives. This needs to occur in time for the
project group to incorporate their reactions into the final design proposals.
To achieve the envisioned changes, continuity is a critical factor. This is why
it is important to anchor the visions with the staff of involved departments
and sections as well as with (top-) management. This is also why it is im-
portant to have central actors from the design project take part in the imple-
mentation and/or have central persons from the implementation team in-
volved in the anchoring activities of the design project.
A large international vendor of an enterprise system conducted a design project with a potential
customer in order to clarify if the customer was in a situation where he could benefit from
implementing (major parts of) the system (Simonsen, 2007). 13 selected employees representing
different areas of the customer’s organization and business processes were interviewed. The
vendor’s IT designers were very experienced within the business domain of the customer. Based
on the interviews they were able to develop a convincing generalization of the situation, which
identified and characterized relevant problem domains. Their image of the situation were tied
together by a string of assumptions and hypotheses generalizing the information gathered from
the interviews. The IT designers presented the results of their interviews at a full day workshop
for the customer’s top-management including the CEO, CFO, and CIO. They systematically
went through each argument chain relating identified problems or needs with proposed IT
solutions specifying each problem or need, identifying its causes, the (undesirable)
consequences it led to, and the ideas for its solution. The workshop acquainted the management
group with the IT designer’s analysis and diagnosis of the current state of affairs and involved
them in a structured discussion of each line of argument related to an identified problem or
need, and invited them to challenge central suppositions, assumptions, and hypotheses related to
the causal relation between problems and solutions. The workshop disclosed the IT designer’s
experience and knowledge within the business domain as well as the customer’s specific context
and situation. In this way, it provided the customer management confidence in the vendor’s
competence and in the relevance of the proposed IT solutions, and hereby it anchored the
4. Comparison with Other Methods
The issues and concerns dealt with by the MUST method are also addressed
by other contemporary ISD approaches. This section outlines significant simi-
larities and differences with regard to agile methods, RUP, Contextual De-
sign, BPR, and Lean.
Keld retter efter aftaleRapid Application Development, or “agile” methods
like Extreme Programming, focuses on fast deliveries of potentially operative
systems and incremental development, relying on project models with strong
iterative elements controlled along the time dimension by time boxes. These
approaches differ in various ways, but they share a strong focus on pro-
gramming and implementation aspects. A basic assumption for a project fol-
lowing these approaches is that a decision to build a system of a particular
kind has already been made. These methods are not intended for larger pro-
jects involving multiple systems, some of which are customized systems inte-
grated within an existing system portfolio. Methods like modern object-
oriented software engineering methods such as Rational Unified Process
(RUP), focus on building systems from scratch. RUP, in turn, does incorporate
early design activities – in the inception and elaboration phases. These activi-
ties are integrated into a software engineering method with a strong focus on
modeling, specifications, and implementation, striving for the classic virtues
of robustness and maintainability.
Contextual Design (CD), as formulated by Beyer and Holtzblatt (1998) and
Holtzblatt et al. (2004), has a scope similar to MUST referred to as front-end
design, requirement engineering, or systems analysis. However, CD does not
distinguish between the users – those that will interact directly with the sys-
tems – and the customers – those that order and pay. In addition, the method
does not suggest ways of handling potential conflicting interests. An IT de-
sign project may involve politics and we must be explicit about the different
roles and competencies in organizational life in general and in IT design pro-
jects in particular. While a CD process aims at specifications meant for devel-
opers or coders, including detailed object oriented models of the system func-
tionality and structure, the MUST method involves a separate design project
where such specifications are deferred until a decision has been made on
what to build or buy. In this way, MUST is inscribed in an overall project
model where it is assumed that not all IT systems are built from scratch and
where the implementation of customized systems will most likely be out-
sourced. The rationale of CD seems to be that the same group of people pro-
ceeds all the way to implementation, in which case this type of detailed de-
scription is valuable. But detailed technical descriptions are superfluous for
those systems that the company in question decides to buy as standard sys-
tems, those that are outsourced for a vendor to deliver, and those that are de-
cided not to be pursued any further.
Business Process Reengineering (BPR), in its original form as proposed by
Hammer and Champy (1993), has the same scope as the MUST method. Both
address the early analysis and design activities in an IT design project as well
as project management. Both aim at formulating one or more visions for the
future use of IT, while the technical and organizational implementation is
considered outside the scope of these methods. BPR and MUST consider the
relations between a design project and an organization’s business and IT
strategies, which are either neglected or considered outside the scope of many
current methods – with potentially damaging results. While radical change,
including downsizing, is a major part of the rationale of BPR, it does not deal
with ethical or practical issues in relation to users. MUST states explicitly that
if management aims at job cuts or other drastic changes, this should be an-
nounced up front. If users know and accept these objectives, we still recom-
mends a participatory approach. Instead BPR suggests an expert strategy, ne-
glecting the knowledge, experience, and interests of users, thereby risking
that the visions developed do not meet real needs. BPR orients its deliverables
primarily toward management, offering no help in understanding, develop-
ing, or presenting relations between IT and users’ work practices. The content
and the form of the reports and prototypes resulting from a MUST process are
meant for management to prioritize further directions for the subsequent im-
plementation activities. They also allow users to understand the consequences
– as to their work practices – of the proposed coherent visions for change.
Lean represents an approach partly associated with BRP. Lean is a manage-
ment philosophy originally developed at the Toyota Corporation and Lean is
sometimes referred to as the “Toyota Way”. The method’s application area is
thus by origin manufacture, but according to Womack and Jones (1996) the
method is generally applicable to organizational innovation and change pro-
cesses. As the name implies, the idea is to make processes ‘lean’ by removing
or reducing all activities that are not producing value for the customer. Even
though the objective of design is to create something new, MUST incorporates
‘lean-thinking’ by establishing the objective of the design project in relation to
the context of the company as well as other ongoing projects early in the pro-
ject. MUST does not stipulate how and where to lean the processes; in stead
the aim of the general principles for example on how to involve the human
actors, the methodological guidelines and the techniques and tools is to create
This concluding section discusses implications and potential further direc-
tions when participatory design is taken out of the “research lab” and is ap-
plied in real life settings. First some of the lessons learned from assisting IT
practitioners integrating PD into their work practice, and from teaching PD to
students, are reflected upon. Then we conclude by briefly outlining some di-
rections from our current research related to the MUST method, where it is
applied in new contexts.
The MUST method, of which the four general principles and some of its main
ideas have been described in this chapter, has been developed as part of a re-
search program organized around 14 projects in Denmark and the US. Over
more than 10 years we have cooperated with private and public organizations
in the development of the method. Further, as the method was developed in
an explorative and incremental way, our undergraduate and graduate stu-
dents tried out various elements of the method in their course work and mas-
ter thesis projects – some of which were also carried out in cooperation with
external partners. Thus, dissemination activities were conducted hand in
hand with the explorative and incremental development of the method.
Bringing PD to IT practitioners.
Integrating new methods in established work practices is difficult and there-
fore the introduction of new methods often fails (Bansler and Bødker, 1993).
However, it is indeed possible for IT practitioners to change their work prac-
tice and start using the MUST method (Kensing 1999; 2003), (Bødker et al.,
2002; 2004). A short introduction (one or two days) may work as a kick-off
workshop for starting using the method – but this has to be supplemented.
An approach to method dissemination must be based on two basic premises:
1. Introduction of a new method should be coupled with a joint apprecia-
tion of actual challenges in real design projects.
2. Traditional teaching cannot stand alone in method dissemination.
These premises have emerged from numerous projects in collaboration with
IT practitioners. A successful dissemination process should comprise a com-
bination of lectures, reflections on current and emerging practices, appren-
ticeship relations, and supervision of technical skills as well as personal com-
petences. The central point is to get beyond a mode of detached reflection in
the interaction between the IT practitioners and the person responsible for the
dissemination endeavor (in our case, us as researchers).
Practitioners who are simply given a general presentation of a new technique
are left on their own when trying to integrate the technique into their work
practices. And a disseminator who is simply told about events and changes in
a recent project is left with the question about what really happened.
So, to get beyond this problem (of second- and third-hand knowledge), the
disseminator must get involved in the work of the IT practitioners through
observations or ultimately through working together on a project. This makes
it possible for the disseminator to relate to problems in the practitioners’ cur-
rent practices when presenting a new technique or proposing changes in their
Bringing PD to students
The Danish version (Bødker et al., 2000; 2008) and English version (Bødker et
al., 2004) of the MUST book has been used as the primary textbook in intro-
ductory design courses for graduate students in IS. The general format of the-
se courses is designed based on the premise that students need to practice and
develop these skills in order to learn to master the elements of participatory
design. Half of the course is traditional lectures by the professor, whereas the
other half is devoted to a project assignment. Here students work in groups of
2 to 4 persons on a project where they have to solve a real world IT design
task. The students are asked to engage with a small company, a public institu-
tion, a non-profit organization, or a department or section within a larger cor-
poration. Below, two lessons are presented: the first related to the structure of
the course, the second related to what is learned by the project work.
Students enter the course with prerequisites in programming and require-
ments modeling from SE courses. In an introductory course, students need
some kind of ‘structure’ to guide their learning process from reading about
the method to start practicing a situation-specific combination of the re-
sources provided, as depicted in Figure 1. The guiding structure that has
proven most efficient is the organization of a design project into separate ac-
The first part of the lectures is organized as a step by step walkthrough of a
design project. The lectures highlight which techniques were chosen in order
to follow each of the four principles and to help meet the requirements set for
the results of each of the phases. This structure is also recommended to guide
the students’ first PD-project. However, when supervising subsequent PD-
projects, students should be advised to also include their appreciation of the
design situation at hand to inform the ways in which they combine the re-
sources provided by the method. Even though the method includes guide-
lines for how and when for example to reduce a phase into an activity in the
preceding phase, it takes more experience to master these types of decisions.
Research in relation to PD and the MUST method is still ongoing. These years
we investigate, elaborate, and expand our approach within two directions: (1)
How to manage participatory approaches applied throughout the design and
organizational implementation of especially large-scale systems, referred to as
a ’sustained’ participatory design (Simonsen and Hertzum, 2008), and (2)
supporting communication and collaboration across organizational bounda-
ries and between organizational members and individuals (patients),
(www.cith.dk). We conduct experiments in an explorative and experimental
way working with (close to) real life projects, and we expect this to lead to
modifications and clarifications of various elements of the method and an
evaluation of how it fares in the new contexts.
Ballejos, L. C. & Montagna, J.M. (2008) Method for stakeholder identification
in interorganisational environments. Requirements engineering 13, 281-297.
Bansler, J and Bødker, K. (1993) A Reappraisal of Structured Analysis: Design
in an Organizational Context. ACM Transactions on Information Systems, vol.
11, no. 2, pp. 165-193.
Beyer, H. & Holtzblatt, K. (1998) Contextual Design. Defining Customer-Centered
Systems. Morgan Kaufmann Publishers, Inc, San Francisco, California.
Bødker, S. (1996) Creating Conditions for Participation: Conflicts and Resour-
ces in in Systems Development. Human-Coomputer Interaction, vol. 11, no. 3,
Bødker, K., Kensing, F. & Simonsen, J. (2000) Professionel IT-forundersøgelse -
grundlaget for bæredygtige IT-anvendelser. Samfundslitteratur
Bødker, K., Kensing, F. & Simonsen, J. (2002) Changing Work Practices in De-
sign. In Social Thinking - Software Practice, (Eds, Dittrich, Y., Floyd, C. & Kli-
schewski, R.) MIT Press, Cambrigde, Massachusetts, pp. 267-285.
Bødker, K., Kensing, F. & Simonsen, J. (2004) Participatory IT Design. Designing
for Business and Workplace Realities. MIT press, Cambridge, Massachusetts.
Bødker, K., Kensing, F. & Simonsen, J. (2008) Professionel IT-forundersøgelse -
grundlag for brugerdrevet innovation (2 udg.). Samfundslitteratur
Clement, A. & Besselaar, P.V.d. (1993) A Retrospective Look at PD Projects.
Communications of the ACM, 36, 29-37.
Coughlan, J. & Macredie, R.D. (2002) Effective Communication in Require-
ments Elicitation: A Comparison of Methodologies. Requirements Engineering
DeMichelis, G., Dubois, E., Jarke, M., Matthes, F., Mylopoulos, J., Schmidt, J.
W., Woo, C. & Yu, E. (1998) A three-faceted view of information systems,
Communications of the ACM, vol. 41, no. 12, 64-70.
Greenbaum, J. & Kyng, M. (Eds.) (1991) Design at Work: Cooperative Design of
Computer Systems Lawrence Erlbaum Associates, Chichester, UK.
Gärtner, J. (1998) Participatory Design in Consulting, Computer Supported Co-
operative Work - A Journal of Collaborative Computing, Kluwer Academic Publi-
shers, vol. 7, nos. 3-4, 273-289.
Halse, J. (2008) Design Anthropology: Borderland Experiments with Participation,
Performance and Situated Intervention. Ph.d. dissertation. IT University of Co-
Hammer, M. & Champy, J. (1993) Reengineering the Corporation. A Manifesto for
Business Revolution. HaperBusiness/HaperCollins Publishers, New York, N.Y.
Holtblatt, K., BurnsWendell, J. & Wood, S. (2004) Rapid Contextual Design: A
How-to Guide to Key Techniques for User-Centered Design. Morgan Kaufmann
Publishers Inc, San Francisco.
Hughes, J.A., Randall, D. & Shapiro, D. (1993) From Ethnographic Record to
System Design: Some Experiences From the Field. Computer Supported Coope-
rative Work (CSCW): An International Journal, 1, 123-141.
Iiavari, J., Isomäki, H., and Pekkola, S., 2009. The User - the Great Unknown
of Systems Development: reasons, forms, challenges and intellectual contribu-
tions of user involvement, ISJ special issue introduction, to be published.
Kensing, F. (1983). The Trade Unions Influence on Technological Change. In
Systems Design For, With and By the Users. U. Briefs et al. (eds.), North Holland
Kensing, F. and J. Blomberg (1998) PD meets CSCW – Issues and Concerns.
Computer Supported Cooperative Work, 7, pp. 167-185
Kensing, F., Simonsen, J. & Bødker, K. (1998a) Participatory Design at a Radio
Station. Computer Supported Cooperative Work, 7, 243-271.
Kensing, F., Simonsen, J. & Bødker, K. (1998b) MUST – a Method for Partici-
patory Design. Human-Computer Interaction, vol. 13, no. 2, pp. 167-198
Korpela, M., H.A., Soriyan, K.C. Olufokunbi, A.A. Onayade, Anita Davies-
Adetugbo & Duro Adesanmi (1998): Community Participation in Health In-
formatics in Africa: An Experiment in Tripartite Partnership in Ile-Ife, Nige-
ria, Computer Supported Cooperative Work - A Journal of Collaborative Computing,
Kluwer Academic Publishers, vol. 7, nos. 3-4, 339-358.
Luff, P., Hindmarsh, J. & Heath, C.C. (2000) Workplace studies: recovering work
practice and informing system design. Cambrigde University Press, Cambridge.
Schmidt, R., Lyytinen, K., Keil, M. & Cule, P. (2001) Identifying software pro-
ject risks: An international Delphi study. Journal of Management Information Sy-
stems, 17, 5-36.
Schuler, D. & Namioka, A. (Eds.) (1993) Participatory Design: Principles and
Practices Lawrence Erlbaum Associates, London, UK.
Simonsen, J. (2007) Involving Top Management in IT Projects: Aligning Busi-
ness Needs and IT Solutions with the Problem Mapping Technique. Commu-
nications of the ACM, 50, 53-58.
Simonsen, J. & Hertzum, M. (2008) Participatory Design and the Challenges of
Large-Scale Systems: Extending the Iterative PD Approach. Proceedings of the
10th anniversary conference on Participatory Design: Experiences and Challenges,
September 30 – October 4, 2008, Bloomington, Indiana, USA, 1-10.
Simonsen, J. & Kensing, F. (1997) Using Ethnography in Contextual Design.
Communications of the ACM, 40, 82-88.
Simonsen, J. & Kensing, F. (1998) Make Room for Ethnography in Design! The
Journal of Computer Documentation, 22, 20-30.
Simonsen, J. (2009) The Role of Ethnography in the Design and Implementati-
on of IT Systems. Design Principles and Practices, an International Journal, 3(3),
Sommerville, I., Rodden, T., Bentley, R. & Sawyer, P. (1992) Sociologists can
be surprisingly useful in interactive systems design. Proceedings of HCI’92,
York University, September 1992, People and Computers, VII, 341-353.
Suchman, L.A. (1983) Office Procedure as Practical Action: Models of Work
and System Design. ACM Transactions on Office Information Systems, 1, 320-328.
Suchman, L.A. (1987) Plans and Situated Actions: The Problem of Human-Machine
Communication. Cambridge University Press, Cambridge, New York.
Michelis, G.D., E. Dubois, M. Jarke, F. Matthes, J. Mylopoulos, J.W. Schmidt,
C. Woo, and E. Yu (1998) Three-faceted View of Information Systems. Com-
munications of the ACM 41 12, 64-70.
Womack, J.P. & Jones, D.T. (1996) Lean Thinking: Banish Waste and Create We-
alth in Your Corporation. Simon and Schuster, London.
Xia, W. & Lee, G. (2004) Grasping the Complexity of IS Development Projects.
Communication of the ACM, 47, 69-74.