Community-Driven Development:
Approaching Participatory Design
in the Online World
Jan Hess, Volkmar Pipek
Introduction
Along various lines, design has always dealt with user participa-
tion as one of the possible ways to reach a design goal. When Dorst
revisited Simon’s perspectives on ill-structured problems and
design,1 he suggested the notion of a “design paradoxon” as a
design goal statement that potential y contains conflicting sub-
goals (belonging to different “discourses,” along a Foucaultian
notion) as the core concept of design; he described design itself
as the “resolution of paradoxes between discourses in a design sit-
uation.” Swann pointed out the relations between design and
action research with its strong consideration of user activities and
encouraged designers and action researchers to learn from each
other’s practices.2
Participatory Design methods already have fol owed these
lines since the 1980s. However, it has always been far from obvious
what participation exactly means when it comes to information
technology design. In the early days of “personal computing,” the
lines of conflict at the workplace (i.e., employers’ interest in effi-
ciency/rationalization vs. employees’ interest in good working con-
ditions/ergonomics) provided some orientation concerning
different levels of participation and how certain types of processes
or user–developer interaction arenas (i.e., Participatory Design
methods) influence them.3 Today, arenas of IT design look differ-
ent. IT has conquered more and more areas of our everyday life,
and it is hidden in more and more devices and technological infra-
structures. General computer literacy has increased among IT
users, and the Internet as well as the open source movement offer
1 Kees Dorst, “Design Problems and
Design Paradoxes,” Design Issues 22, no.
new ways of articulation related to the usage and the development
3 (2006): 5.
(e.g., support forums and user wish lists). These articulations also
2 Cal Swann, “Action Research and the
might have become more qualified regarding the potentials and
Practice of Design,” Design Issues 18, no.
limitations of IT. New technologies, products, or uses encounter an
2 (2002): 61.
existing base of technologies and uses they have to match, and
3 Gro Bjerknes and Tone Bratteteig, “User
they often face competing socio-technical arrangements. IT devel-
Participation and Democracy: A
Discussion of Scandinavian Research on
opment strategies adapted to these market dynamics by becoming
System Development,” Scandinavian
Journal of Information Systems 7, no. 1
(1995): 73–98.
© 2012 Massachusetts Institute of Technology
62
DesignIssues: Volume 28, Number 3 Summer 2012
user-oriented, maybe even user-centered, but not necessarily partici-
patory. The user was given a voice in these design processes, but to
what extent the feedback is considered is not clear.
Taking these developments into account, Participatory
Design researchers are faced with new chal enges and opportu-
nities. The two stereotypes of the user-unaware developer and the
computer-il iterate user are replaced by more gradual mixtures of
competencies. When suggesting Participatory Design arenas, we
have to consider these various mixtures, as well as the ongoing
learning processes that accompany a design interaction. While
home and leisure settings complement traditional work environ-
ments as domains for Participatory Design, different degrees of
motivation for, involvement in, and dedication to the Participatory
Design interaction have to be considered. Design-time and use-
time cannot be separated anymore because IT artifacts have
become more flexible and adaptable, and they mutual y influence
each other’s use and, indirectly, each other’s further development
(e.g., through debates on feasible technology potentials). As a
result, it may always be design-time for dissatisfied users or users
who choose a different socio-technical arrangement (i.e., a differ-
ent product). As suggested by Pipek and Syrjänen,4 Participatory
Design research might react to this development by focusing
on developing infrastructures-in-use rather than on developing
IT artifacts.
The framing conditions for technology development offer
new potentials for Participatory Design research, as wel . The IT
infrastructures we have today provide more ways to articulate and
exchange needs, ideas, and opinions and offer participation oppor-
tunities beyond traditional views of technology design (e.g., with
regard to political issues like standardization). Practical experi-
ences and the competition with the open source movement might
encourage more and more professional IT developers to take the
step from “user-centered” to “Participatory” Design, giving the
Participatory Design research more practical relevance and result-
ing in more opportunities for practice-oriented research.
In this paper, we explore an approach to Participatory
Design in practice that demonstrates many aspects of the develop-
ments mentioned. A software manufacturer (Omega) for home
entertainment software wanted to develop new media center soft-
ware with the help of an existing online community. For about
18 months, we observed and supported the practice of developer–
user relations and the initiative to redesign the product. Focusing
4 Volkmar Pipek and Anna-Liisa Syrjänen,
on community-driven software development, we conceptualized
“Infrastructuring as Capturing In-Situ
and gradually improved a Participatory Design arena in order
Design,” 7th Mediterranean Conference
to explore the dynamics of the perceived and actual values of par-
on Information Systems (Venice, Italy:
ticipation, as well as the associated expectations and fears of the
Association of Information Systems,
2006). Proceedings, eds. G. Jacucci et
al. I, (2006): 134-46.
DesignIssues: Volume 28, Number 3 Summer 2012
63
participating stakeholders. Our experiences can thus inform
other Participatory Design approaches that operate with virtual
user communities.
5 See, e.g., Gro Bjerknes and Tone
Bratteteig, “User Participation and
We now briefly address related work that focuses on in-use
Democracy, and M. J. Muller, D. M.
Participatory Design concepts and community-driven concepts. We
Wildman, and E. A. White, “Taxonomy of
then describe our case setting and concept in more detail. We sum-
Participatory Design Practices,” Posters
marize significant effects in which we were able to observe and
and Short Talks of the 1992 SIGCHI
discuss the course that the Participatory Design interaction took,
Conference on Human Factors in
relating our findings to other Participatory Design approaches to
Computing Systems (Monterey, CA:
1992), 34.
delineate different understandings and practices of participation.
6 Bashar Nuseibeh and Steve Easterbrook,
“Requirements Engineering: A Roadmap,”
Participation in Use
in A. C. W. Finkelstein, ed., “The Future
Several studies on Participatory Design research already account
of Software Engineering,” (Companion
for different modes and levels of participation,5 but they merely
volume to the proceedings of the 22nd
International Conference on Software
reflect the historical context of participation in workplace design.
Engineering, ICSE”00), (IEEE Computer
One can find the normative, emancipatory direction (i.e., users
Society Press).
should be an active part in the design of their workplace), as wel
7 Volkmar Pipek and Volker Wulf,
as the pragmatic, production-oriented description (users have to be
“Infrastructuring: Towards an Integrated
integrated into existing design practices, for example, by using eth-
Perspective on the Design and Use of
nographic methods),6 but in most approaches the design process
Information Technology,” Journal of the
Association of Information System 10,
(and the user participation) precedes the actual use of the product.
no. 5 (2009): 21.
Traditional design methods are focused on the professional
8 Kerl Bødker, Finn Kensing, and Jesper
designer with his or her (re-)design competencies: “Although
Simonsen, Participatory IT Design:
design methods in IS have improved with regard to the ‘technol-
Designing for Business and Workplace
ogy fit’ with users’ needs, they are stil inherently based on a per-
Realities (Cambridge MA: MIT Press,
2004).
spective which focuses on the designers to be the main actor in
9 Austin Henderson and Morten Kyng,
developing IT infrastructures.”7 Bødker et al. underline the impor-
“There’s No Place Like Home: Continuing
tance of user involvement in the design process.8 They define par-
Design in Use” in Design at Work:
ticipation in the context of Participatory Design as mutual learning
Cooperative Design of Computer
processes between designers and users. Instead of involving users
Systems, J. Greenbaum and M. Kyng,
only as informants, genuine participation requires a continuous
eds., (Hillsdale, NJ: Lawrence Erlbaum
Associates, 1991), 223.
user involvement to obtain a shared understanding of the prob-
10 Pelle Ehn, “Participation in Design
lems and needs.
Things,” in Proceedings of the Tenth
Based on Henderson and Kyng’s idea of “Continuing Design
Anniversary Conference on Participatory
in Use,”9 a second approach to user involvement evolved that post-
Design 2008 (Indianapolis, IN: Indiana
pones design activities into the use phase of an IT product. Ehn
University, 2008), 92
11 Volkmar Pipek and Volker Wulf,
distinguishes the two approaches as “design for use before use”
“Infrastructuring: Towards an Integrated
and “design for design after design” and discusses strategies for
Perspective on the Design and Use of
professional designers in order to participate in both arenas.10 Sim-
Information Technology,” Journal of the
ilarly, Pipek and Wulf, Stevens et al., and Fischer and Scharff dis-
Association of Information System 10,
tinguish the “when” of design between “design-time” and
no. 5 (2009): 447-73; Gunnar Stevens,
“use-time.”11 In their approaches of “infrastructuring” and “meta-
Volkmar Pipek, and Volker Wulf,
“Appropriation Infrastructure: Supporting
design,” they point out that problems in the subsequent use cannot
the Design of Usages” in Lecture Notes
be completely anticipated while designing a product. Users wil
in Computer Science 5435 (Berlin:
discover mismatches when they actual y use the product. As a Par-
Springer, 2009): 50-69; Gerhard Fischer
ticipatory Design-centered approach, Hertzum and Simonsen ref-
and Eric Scharff, “Meta-Design: Design
erence an “Effects-Driven IT Development.”12 In an empirical study
for Designers,” in Proceedings of the
Third International Conference on
64
DesignIssues: Volume 28, Number 3 Summer 2012
related to an electronic patient record system, they show that four
types of changes need to be considered for (re-)designing a system:
planned, emergent, opportunity-based, and curtailed ones.
Designing Interactive Systems:
Processes, Practices, Methods, and
Because the latter three occur only during use, they highlight the
Techniques, D. Boyarski and W. Kellogg,
relevance of pilot implementations. Research on “End-User Devel-
eds., (New York: ACM Press, 2000):
opment” (EUD) also is bridging the gap between design- and use-
396-405.
time. Participation in the sense of EUD “empowers end-users to
12 Morten Hertzum and Jesper Simonsen,
develop and adapt systems themselves.”13 These adaptations on a
“Effects-Driven IT Development: An
run-time level can only be realized with highly flexible software
Instrument for Supporting Sustained
Participatory Design,” in Proceedings of
architectures.14 Pipek and Wulf introduce the concept of “infra-
the 11th Biennial Participatory Design
structuring” for a “design in use” that involves all stakeholders
Conference (New York: ACM Press,
over a longer period of time and provides support beyond devel-
2010), 61-70.
opment and adaptation: “We describe the methodological
13 Henry Lieberman, Fabio Paternò, Marcus
approach of infrastructuring to develop methodological and tool
Klann, and Volker Wulf, End-User
Development, HCIS Vol. 9 (Dordrecht,
support for al stakeholders’ activities that contribute to the success-
The Netherlands: Springer, 2006), 1.
ful establishment of an information system usage” (emphasis
14 Volker Wulf, Volkmar Pipek, and Marcus
added).15
Won, “Component-Based Tailorability:
Muller et al. classify participative techniques along two
Towards Highly Flexible Software
dimensions.16 The first is the level of user involvement: A user
Applications,” International Journal on
either can be observed or can actively participate in discussions;
Human-Computer Studies 66, no. 1
(2008): 1-22.
the second is the temporal position of the user’s participation in
15 Volkmar Pipek and Volker Wulf,
the development process. A company can employ different tech-
“Infrastructuring: Towards an Integrated
niques to encourage the exchange of information between users
Perspective on the Design and Use of
and developers, including interviews, surveys, questionnaires, or
Information Technology,” Journal of the
observation. Keil and Carmel reference “customer–developer
Association of Information System 10,
no. 5 (2009): 447.
links” that include support hotlines, bulletin boards, or trade
16 Michael J. Muller, Daniel M. Wildman,
shows.17 In comparing different projects, they found that more suc-
and Ellen A. White, “Taxonomy of
cessful projects employed more customer–developer links then
Participatory Design Practices,” in
less successful ones. S. Visser and Visser emphasize that the same
Posters and Short Talks of the 1992
users should participate not only at a single stage of the design
SIGCHI Conference on Human Factors in
process, but also at later ones.18 Such “returning participants” pro-
Computing Systems (New York: ACM,
1992), 34.
vide more effective feedback because they already have a relatively
17 Mark Keil, and Erran Carmel, “Customer–
deep knowledge of the application’s concepts.
Developer Links in Software
As a result of globalization and the spread of new techno-
Development,” Communications of the
logical facilities, development processes can be managed in more
ACM 38, no. 5 (1995): 33-44.
distributed settings.19 The development in distributed projects dif-
18 Froukje Sleeswijk Visser, and Victor
Visser, “Re-using Users: Co-create and
fers from traditional ones and requires a rethinking by different
Co-evaluate,” Personal and Ubiquitous
stakeholders. On the one hand, the process of implementation can
Computing 10, no. 2-3 (2006): 148.
be distributed. On the other hand, user involvement can be stimu-
19 Anandasivam Gopal, Tridas
lated by the use of Internet tools. Farshchian reported on a case
Mukhopadhyay, and Mayuram S.
study in which users participated in an international software
Krishnan, “Virtual Extension: The Role of
development project via email and the Internet.20 Because informal
Software Processes and Communication
in Offshore Software Development,”
communication mainly took place asynchronously through the use
Communications of the ACM 45, no. 4
of mailing lists, prototypes were the main formal reference for
(2002): 193-200.
stimulating discussions and improvements. Such cases underline
20 Babak A. Farshchian and Monica Diyitini,
the importance of new forms of online articulation related to the
“Using Email and WWW in a Distributed
design artifact.
Participatory Design Project,” ACM
SIGGROUP Bulletin 20, No. 1 (1999): 11.
DesignIssues: Volume 28, Number 3 Summer 2012
65
Stevens and Wiedenhoefer present an interesting approach
to minimize the gap between use-time and design-time.21 With
their “Community Help in Context” (CHiC) concept, they provide
21 Gunnar Stevens and Torben Wiedenhöfer,
“CHIC: A Pluggable Solution for
a wiki-based help system that empowers users to extend and mod-
Community Help in Context,” in
ify help descriptions related to the current context. This and other
Proceedings of the 4th Nordic Conference
similar concepts can support in-situ design activities on the user-
on Human–Computer Interaction:
side, e.g. resulting in contextualized feedback that can be consid-
Changing Roles, Anders Morch, Konrad
ered in later redevelopment stages. More generally, Hagen and
Morgan, Tone Bratteteig, Gautam Ghosh,
and Dag Svanaes, eds., (New York:
Robertson describe evolving practices of “Participatory Design in
ACM Press, 2006), 212-221.
the wild” that are made possible by social technologies.22 Such
22 Penny Hagen, and Toni Robertson,
technologies create new opportunities for user participation early
“Social Technologies: Challenges and
in the design phase and become an opportunity for “socialising
Opportunities for Participation,” in
the research, bridging existing and future practices, and develop-
Proceedings of the 11th Biennial
ing seed content.”
Participatory Design Conference,
(New York: ACM Press, 2010), 31.
Virtual Communities and Participation
23 Howard Rheingold, The Virtual
Community: Homesteading on the
Many Participatory Design approaches have focused on stimulat-
Electronic Frontier (Reading, MA:
ing local discourses in the workplace. With the availability of the
Addison Wesley, 1993), 20.
Internet, existing or future users of a product can connect to each
24 Jonathan Lazar and Jennifer Preece,
other in a virtual/online community. Spatial limitations lose some
“Social Considerations in Online
of their importance, and the motivation for being part of such a
Communities: Usability, Sociability, and
Success Factors,” in Cognition in a
community very often is a shared interest. Howard Rheingold
Digital World, H. Van Oostendorp, ed.,
characterizes virtual communities as “social aggregations that
(Mahwah, NJ: Lawrence Erlbaum Assoc.,
emerge from the Net when enough people carry on those public
2003), 119.
discussions long enough, with sufficient human feeling, to form
25 Arthur Armstrong and John Hagel III,
webs of personal relationships in cyberspace.”23 However, everyone
“The Real Value of On-Line
has their own interpretation of what connectivity in such social
Communities,” in Creating Value
in the Network Economy, Don Tapscott,
aggregations means: “We all have our own notion of what an
ed., (Boston, MA: Harvard Business
online community is. It isn’t hard to understand, but it is slippery
School Publishing, 1999), 173-85.
to define and tricky to measure,” note Lazar and Preece.24
26 Barry Wellman, “Virtual Community:
Communities can be classified according to different
Introducing a New SIGGROUP Focus
aspects, e.g. as done by the classification from Armstrong and
Area,” ACM SIGGROUP Bulletin 19
no. 1 (1998): 19.
Hagel.25 They distinguish between four different types of commu-
27 Johann Füller, Michael Bartl, Holger
nities: transaction oriented, interest oriented, fantasy oriented, and
Ernst, and Hans Mühlbacher,
relationship oriented. Barry Wel man proposes other categories of
“Community-Based Innovation: How to
virtual communities, including one cal ed communities of con-
Integrate Members of Virtual
sumers.26 Such communities have a product or product category as
Communities into New Product
the constitutive shared interest. Users who are engaged in such
Development,” Electronic Commerce
Research 6, no. 1 (2006): 57.
communities often bring in many innovative ideas for product
28 Jonathan Lazar and Jennifer Preece,
improvements.27 In addition, members of such communities can
“Social Considerations in Online
contact and help each other. While profound help and recommen-
Communities: Usability, Sociability,
dations from other users support the usage of a product, compa-
and Success Factors,” in Cognition
nies see positive commitments as an effective form of marketing.28
in a Digital World, H. Van Oostendorp,
ed., (Mahwah, NJ: Lawrence Erlbaum
With the idea of use discourse environments as a platform for
Assoc., 2003).
“built-in” communities related to technological artifacts, we fos-
29 Volkmar Pipek, “From Tailoring to
tered user–user col aboration to support our appropriation work.29
Appropriation Support: Negotiating
Groupware Usage” (PhD thesis,
University of Oulu, Finland, 2005).
66
DesignIssues: Volume 28, Number 3 Summer 2012
An important theory for involving users in the design pro-
cess is given with the ‘Lead User Theory.’30 Based on several stud-
ies, Franke et al. define lead users as users who fulfill two
characteristics:31 First, they are intensively engaged with the partic-
ular product and the associated market; therefore, they can dis-
cover new trends and demands in an early stage. Second, lead
users anticipate advantages that lie in new technologies for them-
selves. These two characteristics lead to a high engagement for par-
30 Nikolaus Franke, Eric von Hippel, and
ticipation. The motivation for taking part in such design processes
Martin Schreier, “Finding Commercially
Attractive User Innovations: A Test of
was explored by Fül er et al., who found that users help to create
Lead User Theory,” Journal of Product
an improved product that meets their personal needs better. The
Innovation Management 23, no. 4 (2006):
aspects for participation are manifold and include factors as fun,
301-15.
curiosity, desire to learn, personal interest, acceptance from others,
31 Nikolaus Franke, Eric von Hippel, and
and the access to exclusive information.32 In addition, users feel
Martin Schreier, “Finding Commercially
Attractive User Innovations: A Test of
more accepted and build up a deeper relationship to the producer.
Lead User Theory,” Journal of Product
Von Hippel splits the process of lead user involvement into four
Innovation Management (Massachusetts:
phases.33 In the first stage, a new trend is identified. Then, based on
MIT Press, 2005), 301.
the users’ requirements and experiences, some lead users are cho-
32 Johann Füller, Michael Bartl, Holger
sen. In the third stage, the lead users’ demands are analyzed,
Ernst, and Hans Mühlbacher, “Community
which results in new product concepts. Final y, these new concepts
Based Innovation: How to Integrate
Members of Virtual Communities into
are projected on a larger market. Innovations that are driven by
New Product Development,” Electronic
users also are referenced in the work from Björgvinsson et al.34 In
Commerce Research 6, no. 1 (2006):
their understanding, democratic innovation is more than a process
57-73.
that is democratized by the involvement of lead users. Instead,
33 Eric von Hippel, “Lead Users: A Source of
”democratizing innovation” practice as an alternative can appear
Novel Product Concepts,” Management
Science 32 (1986): 797.
in “an open innovation milieu where new constel ations, issues,
34 Erling Bjoergvinsson, Pelle Ehn, and
and ideas evolve from bottom-up, long-term col aborations among
Per-Anders Hillgren, “Participatory
diverse stakeholders.”35
Design and ‘democratizing innovation’”
The involvement of users in the design phase is not trivial.
in Proceedings of PDC (2010), 41-50.
Users as well as employees have to be prepared for such a process.
35 Ibid, 41.
On the developer side, programmers often resist contributions
36 Ari Heiskanen and Jouni Similä,
“Gatekeepers in the Action Structure of
from external stakeholders. One solution is the involvement of so-
Software Contracting: A Case Study of
cal ed “gatekeepers.”36 Gatekeepers have the users’ as well as the
the Evolution of User–Developer
employees’ confidence. They connect a company with external
Relationships,” in ACM SIGCPR
sources by filtering relevant information in a structured way. Such
Computer Personnel 14, no. 1-2 (New
gatekeepers often exist in open-source software projects. Barcel ini
York: ACM Press, 1992), 30-44.
37 Flore Barcellini, Françoise Détienne, and
cal s them “cross-participants” because they participate in paral el
Jean-Marie Burkhardt, “Users’
discussion spaces and, therefore, may have the best overview of
Participation to the Design Process in a
ideas and improvements.37
Free Open Source Software Online
Fül er et al. describe a concept that al ows for the involve-
Community,” Proc. of the 18th workshop
ment of members of virtual communities in a structured way.38
Psychology of Programming PPIG’06
Cal ed “Community-Based Innovation” (CBI), their concept can
(2006), 99-114.
38 Johann Füller, Michael Bartl, Holger
be applied in four phases. In the first phase, attributes of the
Ernst, and Hans Mühlbacher,
users are identified that fit the requirements of the task at its best.
“CommunityBased Innovation: How to
Second, a community is identified where the key users can be
Integrate Members of Virtual
found. In the third step, a virtual interaction design is developed
Communities into New Product
Development,” Electronic Commerce
Research 6, no. 1 (2006), 57-73.
DesignIssues: Volume 28, Number 3 Summer 2012
67
to support communication with the users. The last step focuses on
the real involvement of the users, starting with establishing con-
tacts and resulting in design participation. This way, users can par-
ticipate already in early design phases: “Members of online
communities who are characterized by high product and activity
involvement represent an ideal resource for co-designing products
when confronted with those new methods.”39 As one of the major
findings of the study, users are able and wil ing to participate in
such a process.
Community-Driven Development
In the previous sections, we described concepts that have users
somehow involved in the design and innovation process. However,
none of the known studies treats users and employees with equal
importance. Users can express wishes and take part in the devel-
opment process, but they do not have any influence on the deci-
sions that are final y made. As a development process that is real y
driven by users, we introduce “Community-Driven Development”
(CDD). The concept is closely related to the traditional under-
standing of Participatory Design in workplace settings.40 User
representatives and IT designers work together throughout the
whole development process to gain a deep understanding of
demands and needs. But CDD goes beyond traditional forms of
collaboration, by applying Participatory Design to the online
world. Distributed users are involved, providing their knowledge
and their ideas.
Concept
Involving users from online communities in a software design pro-
cess requires room for discussions. Virtual platforms (e.g., forums)
where all interested users can share and discuss their ideas and
opinions provide an alternative to physical meeting places. In the
CDD approach, the group of users involved in design is cal ed the
“user parliament” of the community. The company can limit the
number of members in the user parliament and establish an appli-
cation procedure. The concept’s second institution is the “central
committee,” which consists of elected users and staff members
who col ect information and make the final decisions. As represen-
tatives from user’s side, the most engaged ones are qualified for
such a position. In our case, the role of “moderators” already was
established (see Figure 1). Moderators are users who stay in closer
contact to the staff members of the company and voluntarily con-
tribute in helping other users. The members of the central commit-
39 Ibid.,
tee play a very important role in the process; they should
40 Kerl Bødker, Finn Kensing, and Jesper
consequently enjoy the full confidence of both users and staff. The
Simonsen, Participatory IT Design:
election process can vary from case to case, depending on aspects
Designing for Business and Workplace
such as size of the community, number of existing moderators, and
Realities (Cambridge, MA: MIT press,
the available time of staff members.
2004).
68
DesignIssues: Volume 28, Number 3 Summer 2012
Figure 1
Community-Driven Development Approach.
A democratic way to elect the representatives to the central
committee would be a poll by members of the user parliament;
but, several aspects make such a procedure difficult. Users in the
parliament cannot estimate how much time the representatives
can spend, what knowledge they have, and in which voice they
speak. Moderators, on the other hand, are users and company rep-
resentatives who already have earned acceptance by the commu-
nity for an extended time. They are characterized by their ability to
help others and stimulate discussions. Because of these already
established competencies, moderators are best qualified for such a
position. Moderators and staff together then elect the members of
the central committee. These persons can take part in the discus-
sions of the user parliament as private users, but in their function
as committee members they should be neutral and act as modera-
tors, if necessary. The committee hosts regular conferences, either
in person or by telephone, to discuss users’ ideas and interests
about previously defined topics and to seek consensus on user
needs. Such decisions should represent the prevailing opinions
based on discussions in the user parliament. To al ow for transpar-
ency and room for reflective user feedback, the results are summa-
rized in a public space. Later on, the final decisions can be used as
a central requirements specification that forms the basis for the
software development process. An initial prototype should be
built and given to all interested users as soon as possible, so that
they can constantly test and improve it. The online forum can fur-
ther be used by the user parliament to provide feedback about
advantages and disadvantages of the prototypes. This input is
41 Gerhard Fischer and Eric Scharff,
gathered and discussed by the central committee again and then
“Meta-Design: Design for Designers” in
brought to the development team. From an engineering point of
Proceedings of the 3rd conference on
Designing Interactive Systems:
view, the design cycles should follow the STEPS model. In the
Processes, Practices, Methods, and
STEPS process, developers and users work closely with each other
Techniques, D. Boyarski and W. Kellogg,
to cooperatively generate a system specification and cyclical
eds., (New York: ACM Press, 2000),
improve early versions.41
396-405.
DesignIssues: Volume 28, Number 3 Summer 2012
69
Use Case: CDD in a Software Design Process
Omega, a medium-sized software company developing products
that help to connect personal computers and televisions (i.e., media
center software) has applied the CDD concept in practice. Media
center software typical y offers functionalities that include paus-
ing and recording live TV, managing existing video, audio, and
image files, and streaming media files to other clients. The devel-
opment of a new media center OmegaTV was studied as an exam-
ple of the involvement of a user community in the design process.
Setting
Omega provides an online community space for its users. The
portal consists of a wiki system that al ows users to share their
knowledge about Omega’s products, and a forum that serves as a
platform for information exchange (e.g., problems and potential
improvements) between users and Omega employees.
An active community was established over the course of
three-plus years; about 200 of the more than 15,000 registered
users regularly took part in discussions. The Omega team had
introduced the CDD concept both in the forum and in a weekly
newsletter several months before the project started. The members
of the forum had the opportunity to apply for seats in the user
parliament via an online form. The original plan included only
30 persons in the user parliament, but because each applicant
seemed highly motivated and reliable, all 70 applicants were
al owed to serve.
The Omega staff and the moderators of the forum elected
the members of the central committee. The moderators are nine
private users who work on a voluntary basis and have been coop-
erating with Omega for a long time. Al applications received for
membership on the central committee were presented in the inter-
nal moderators’ forum. The moderators and the staff quickly
agreed on four users who were convincing because of their experi-
enced knowledge about the product and their ability to discuss
objectively. From time to time, forum discussions between users
become overheated. In such cases, moderators must be able to
defuse the tension and focus on the facts. From the Omega team’s
side, the central committee was complemented by the product
manager, the product supervisor, and the quality manager.
The cooperation began with the central committee’s kickoff
workshop, where all members met in person. At this first meeting,
Omega introduced the technical framework, provided the unalter-
able definitions already established by the developers, and shared
the basic concept for the project procedure. The user parliament
started working when the first technical preview was published,
and the preview version provided a first visual representation.
70
DesignIssues: Volume 28, Number 3 Summer 2012
Progress
The discussions of the user parliament were held in a separate
forum where write access was restricted to its members. New
entries could be written as text, as text with attachments, or as sur-
veys. The members of the central committee had their own forum,
as well, although it was mainly used for making appointments.
Central committee members contributed their ideas and opinions
to the user parliament forum. Each member of the committee
specialized in a certain topic, depending on personal interest.
They each took part in discussions and worked as moderators in
these areas.
The product manager summarized forum discussions and
sent them to the members of the central committee as a basis for
the weekly conference cal . In these cal s, the average duration of
which was two hours, previously defined topics were discussed
intensively, and decisions were made. The results of every confer-
ence call were published in the wiki system. The requirements
listed there served as the basis for the requirement specification
the developers used to implement the system.
Methodology
We studied the use case both qualitatively and quantitatively. The
quantitative analysis was concerned with the participants’ forum
entries. The gathered data al owed us to make statements about
the community itself (e.g., how many users, how many entries), as
well as about the participation of individual users with regard to
certain topics over a particular period of time. The qualitative anal-
ysis included evaluation of the entries in the forum and wiki, as
well as of semi-structured interviews conducted with 14 represen-
tatives of the different committees. Both users and employees were
interviewed: six members of the Omega team, two of whom were
members of the central committee, and eight users (four members
of the user parliament and four of the central committee).
We interviewed each person twice. The interviews held at
the beginning were primarily concerned with the participants’
motivation and the conditions for the project. Later interviews tar-
geted possible alterations in the participant’s opinion: Did the proj-
ect meet the expectations and did the attitude toward a CDD
process change? The interviews with employees lasted up to 30
minutes, and those with users up to 23 minutes. All of the inter-
views were recorded for later analysis.
Findings
Motivation: The users’ motivation for taking part in a CDD
process was very high, especial y at the beginning of the project.
The opportunity to participate in the development process and to
DesignIssues: Volume 28, Number 3 Summer 2012
71
bring in own ideas was considered valuable. About 2,000 entries
were written in the first three weeks, and several of them were
rather long. After four weeks, the discussions slowed down. Users
who contributed had expressed their ideas and were waiting for
first results. As soon as the first alpha version was released, the
users again got heavily involved. However, of the 70 members of
the parliament, only 49 persons participated in the first design pro-
cess. Only 15 users took part in the project throughout the 8-month
process. On the other hand, 30 new participants joined the project
and provided regular contributions to discussions after the first
prototype was released.
The motivation of staff members to participate in such a
project was difficult to access. On the one hand, the management
saw great potential, and on the other hand, the developers were
quite reserved, especially at the beginning of the project. This
same distinction could also be observed in the central committee:
While the product manager was the main driving force, the devel-
oper participated only occasional y in discussions. From the devel-
oper’s point of view, the CDD disturbed his usual work. The
manager, on the other hand, had been familiar with media center
systems for many years and initiated many discussions in the user
parliament. Because his ideas often were accepted, he had a strong
influence on the design process. This outcome does not contrast
with the original concept because as member of the central com-
mittee he also was al owed to participate in the discussions of the
users’ parliament. In fact, the stimulating influence of the manager
was observed to be absolutely necessary in structuring the process
and addressing every subtopic (including several functionalities,
usability, and control ing mechanisms).
Technology
One aspect we regarded as critical already in the starting phase
was the technical infrastructure used to support communication.
We optimistical y expected that users could handle a CDD process
that used the existing and familiar infrastructure (forum and
wiki). But our results show that the existing infrastructure is insuf-
ficient for supporting a highly dynamic process like CDD. The sep-
aration of discussion (forum) and functional specification (wiki)
resulted in an environment in which both tools were seen as inde-
pendent instances with different responsibilities. For the members
of the central committee, the wiki was the center of reference; for
the members of the user parliament, the statements in the forum
discussions were regarded as important. Another problem was the
presentation of the specifications in one document. Although the
wiki has a changelog function, the readability of the specification
obviously did not fulfill users’ needs. Furthermore, the document
contained many images and screenshots so that downloading it
took quite a long time, especial y for users with a low bandwidth.
72
DesignIssues: Volume 28, Number 3 Summer 2012
Organization
The subdivision of the CDD concept into user parliament and cen-
tral committee has proven to be suitable in principle. However,
members of the user parliament had reservations about the central
committee because members of the committee were seen as
favored in the direct communication with the development team
staff members. Members of the user parliament thought that mem-
bers of the committee kept information secret or held information
back. Concerning these matters, users in the parliament stated that
members of the central committee should serve on a rotating basis.
Furthermore, making the communication within the committee
more transparent would be valuable (e.g., by letting members of
the user parliament participate in the weekly telephone confer-
ences in a passive way or by recording the conferences and pre-
senting the results in the online area afterwards). Another
suggestion for the early stage of the design process was to use per-
sonal group discussions. Both users and representatives from the
company were interested in module-oriented, face-to-face work-
shops. However, the planning of the physical central committee
meetings general y was difficult, because of time and travel con-
straints. Traveling to reach a common meeting point would have
been too time-intensive. In the whole process, only two meetings
between the members of the central committee took place. Web
conferences were, therefore, seen as alternatives to the weekly tele-
phone conference sessions.
Another important aspect is related to a clear separation of
the roles and tasks of the members of the central committee.
Because everyone was responsible for everything in the first
stage of the process, members of the committee asked for a clear
role assignment. In the feedback interviews, they recommended
that several tasks (e.g., communicating with members of the user
parliament, summarizing requirements, or coordinating mile-
stones) should be assigned to committee members so that a clear
and transparent assignment of roles is made public, and the
members of the user parliament would know who is responsible
for a particular task. Such clarity can help to correct misunder-
standings faster.
The amount of time for supervision, as well as for the whole
process, is a critical issue, too. Especial y for the moderators (as
representatives for the user), the amount of work became crucial.
One of these persons left the commitment during the project,
because the personal situation (private and work) did not al ow for
enough time to invest in the project. Even employees of Omega
mentioned that the effort of time to manage the project was much
higher than was expected at the beginning of the project. A ful -
time employee would have been needed just for the communica-
tion with the user parliament. The process as a whole was more
DesignIssues: Volume 28, Number 3 Summer 2012
73
time-consuming than traditional software development. The dura-
tion of a CDD process cannot be predicted exactly because users
assign time for contribution individual y. Nearly all the partici-
pants of the CDD process mentioned that the time frame for apply-
ing the whole project was too short.
Satisfaction
Both users and staff members learned from each other through the
CDD process. The user parliament generated a number of ideas,
which were gathered and discussed in the central committee.
However, the restriction of a virtual discussion space comes with
several limitations compared to traditional Participatory Design as
described by Bodker et al.42 The central committee members dis-
cussed issues and demands in weekly telephone cal s, even though
they had their own forum; and, although the conference cal s gen-
eral y lasted about two hours, sometimes ensuring that all voices
were heard was difficult. Especial y in the requirements phase,
mediating between the user parliament and the central committee
was chal enging. An Omega staff person reflected at the end of the
project: “They [the users] come to us very pragmatical y with any
suggestions and discuss on the basis of any visual scripts, Power-
Point pages, but [they] don’t see the results afterwards. […] Many
[of them]…have to see it …, and we could here not deliver enough
[by discussing and defining functionalities and improvements in
textual form only].” The comparison of the different reactions to
the first prototype is quite interesting. Members of the user parlia-
ment were disappointed to a certain degree, while persons from
the uninvolved online community gave positive feedback in the
public forum. The negative comments by members of the user par-
liament probably resulted from the fact that the developed proto-
type could only be a compromise between the different
suggestions (as it was defined in the public wiki documentation).
Users who participated in the project may have been less satisfied
because they invested time and effort making a contribution to the
process, and dissatisfaction increases when suggestions offered are
not considered. The whole second phase of the project ran more
smoothly after the alpha versions were published continuously in
intervals of only a few weeks. Because most of the criticisms men-
tioned were considered, the discussion was less active. After the
release of the last two alpha versions, contributions often were lim-
ited to the reporting of program errors.
At the end of the study, both users and employees reported
appreciating the opportunity to participate. Even though the pro-
cess of the CDD was problematic at certain points, it was neverthe-
less “a bigger success [that] the method can apparently work and
might work even better for other projects,” according to one
42 Kerl Bødker, Finn Kensing, and Jesper
Simonsen, Participatory IT Design.
74
DesignIssues: Volume 28, Number 3 Summer 2012
employee. Except for one person, all employees were wil ing to
conduct another CDD, although they would try to solve the now
known problems. It was particularly important for them to reserve
more time for the project. The users that we interviewed also saw a
lot of potential in the concept: According to one member of the
user parliament, “User driven development works when certain
things are clearly defined, tasks are clearly distributed, the team
supports it, and the communication with the users is good.”
Conclusion
In this paper, we explored the involvement of a virtual user com-
munity in the whole development process of a software system.
Compared to previous work, e.g. from Fül er et al.,43 we introduced
the concept of a community-driven software development process,
in which participants not only give feedback, but also have the
power to influence decisions. The results of the evaluation under-
line previous work (e.g., members of an online community are able
and wil ing to contribute; fun is an intrinsic motivation to partici-
pate; users provide valuable information). But our study also
shows that especial y the structures of professionalization lead to a
power imbalance toward the designers’ side, even if it is not
intended: What started as a nice leisure activity for the users in the
central committee felt like unpaid real work during the project, e.g.
what became visible when a moderator left the membership in the
central committee. The “work character” of user participation was
also il ustrated by the demand for explicit and transparent roles for
certain tasks, by the perceived need for self-organization among
users, and by the efficiency concerns with regard to the technolog-
ical infrastructure that was used.
Using existing virtual user communities as a starting point
for a Participatory Design process seems to be obvious, but the
advantages of using an existing discussion culture needs to be
exploited careful y. The normal discontinuities of participation in
online communities can become a problem when they appear
among user representatives in a process model like ours. As a con-
sequence, we would suggest that responsibilities for the user rep-
resentatives have to be framed according to the concrete use case.
Personal interests, varying time to contribute, and different levels
of experience may result in an unbalanced reflection of the users’
needs. Instead of giving the most engaged users the power of deci-
sions, the more valuable contribution is for them to act as media-
tors who summarize and reflect the previous results. Such
43 Johann Füller, Michael Bartl, Holger
summaries should be linked directly and integrated into the dis-
Ernst, and Hans Mühlbacher, “Community
cussion and decision process. At this point, it should be clearly
Based Innovation: How to Integrate
defined which aspects can be decided about by members of the
Members of Virtual Communities into
online community (e.g., in the sense of polls as reaction to the
New Product Development,” Electronic
Commerce Research 6, no. 1 (2006),
57-73.
DesignIssues: Volume 28, Number 3 Summer 2012
75
summary documents). With respect to duration and the quality of
results, the process itself is hard to estimate. Nevertheless, we
would advise designers to articulate the framing conditions for a
CDD approach in a clear and continuously manner.
Final y, although users may be familiar with general com-
munity tools, specialized tool support might increase the quantity
of participation, as well as the quality of articulations (e.g., by
referring to representations of the technology). While wikis and
Web forums are sufficient to run a user community, a participation
process demands more specialized technological support (e.g.,
with respect to references to other parts of the discussion or to
design aspects under consideration), even if users are already
familiar with the community infrastructure. By providing more
flexible tools that run on a meta-level and consider the context of
use, we expect a much better integration of the participants’ input
in the whole design process. When design-time is supported dur-
ing use-time (e.g., by al owing users to give direct feedback when a
problem occurs) — on a tool level as well as on an organizational
level — the process of a continuous community-driven develop-
ment will run more fluidly.
When Ehn distinguished between “design for use before
44 Pelle Ehn, Participation in Design Things
use” and “design for design after design,” he pointed to the chal-
in Proceedings of the Tenth Anniversary
lenges professional designers face for the latter case.44 Our study
Conference on Participatory Design 2008,
(Bloomington, Indiana, October 01 - 04,
il ustrates the chal enges for users in this latter case: Democratic
2008, 2008), Indiana University,
design comes at a cost that is difficult to estimate against the bene-
Indianapolis, IN, 92-101.
fit one gets. Our experience with the delegation patterns described
45 Volkmar Pipek, Volker Wulf,
suggests that modest redesign goals and shorter redesign cycles,
Infrastructuring: Towards an Integrated
together with a stronger integration of these activities into use
Perspective on the Design and Use of
Information Technology, Journal of the
practice, could be helpful. This finding complements and concret-
Association of Information System (JAIS)
izes the discussion around the “when” of design-in-use in our
10, no. 5 (May 2009): 306-32.
notion of “infrastructuring” with the necessary “how.”45
76
DesignIssues: Volume 28, Number 3 Summer 2012