Joan Greenbaum

Participatory design in Britain and North America: responses to the “Scandinavian Challenge”

It has been argued that the successes of participatory design in the Scandinavian countries will be difficult to reproduce in North America or Britain, because of significant differences in labor, legislative, and workplace environments. This panel is composed of people actively pursuing participatory design in corporations outside of Scandinavia. We focus on what accommodation(s) were required in participatory design techniques to meet the needs of our environments — and on what accommodations occurred in our environments in response to experiences with participatory design. INTRODUCTION The “Scandinavian Challenge,” as proposed by Bjerknes, Ehn, and Kyng [2], is a set of perspectives and practices for increasing the role of users as active participants in the process through which computer artifacts are designed that have impact on the users’ lives in and out of the workplace. This work has come to influence the SIGCHI community through the work of B@lkeret al. [5, 6], Ehn and Kyng [9, 10, 11], and Thoresen [21], and commentaries by Suchman [20] and by Grudin [14], as well as PDC’90 [19] and panel sessions at several conferences. It has been argued that the workplace democracy themes of the Scandinavian challenge are difficult — or even impossible— to carry out in corporate or institutional environments that are not characterized by high unionization, by legislative protection of the users’ roles in system design, or by a relatively small-scale, highly integrated software development process. However, several projects outside of the Scandinavian countries have begun to use participatory design techniques —e.g., Blomberg [3,4], DykstraandCarasik [7, 8], MacLean, Carter, Lovstrand, and Moran [16], Muller [17, 18,22], and in some ways Bennett et al [ 1], These projects argue for the feasibility of democmtic design procedures in apparently “hostile” environments. They also open questions of mutual accommodation between participatory design procedures and corporate/ institutional culture. This panel session brings together participatory design work that is being conducted in various settings outside of Scandinavia. Each panelist emphasizes how those settings have influenced the participatory design paradigm, and how participatory design has influenced the work setting. JEANEllE L. BLOMBERG: IMPROVISING TECHNIQUES TO ACHIEVE PARTICIPATORY DESIGN GOALS: EVERYONES CHALLENGE In discussing the relevance of ethnographic field methods for the design of new technology with practitioners from the Scandinavian school of participatory design, it became apparent that ethnography and participatory design shared a similar orientation. Specifically, ethnographic field methods require an improvisational style of work [3], where adjustments are made in strategy and appropriate techniques as more is learned about the particular situation at hand. Similarly there is an improvisational quality to much of the Scandinavian work in participatory design. There is a recognition that no two situations are alike. Each situation reqttiresacreative weaving of skills, technologies, people, organizations, and opportunities for change. This leads to the question: If no two situations are alike, each requiring a unique way of doing things, then in what sense can we talk about a participatory design approach or for that matter about adapting the “Scandinavian Approach” to the North American context? What isit that unites those of us who identify ourselves aspracticingparticipatory design— whether in Scandinavia or North America? Perhaps what we should be focusing on is not a set of techniques, a list of necessary conditions, or a collection of appropriate technologies, but instead a commitment to a few basic goals: improving the quality of the working lives of those for whom we design technologies, involving the users in the coltaborat.ivc development of new technologies, and providing opportunities to iterate the design in response to the every&y requirements of the work situation [4]. Our techniques and strategies then will reflect the different contexts in which the technology develop-

Participation, the camel and the elephant of design: an introduction

Probably many people reading this special issue have worked with participatory design, or know someone who has tried to inject participatory practices into their work. Others might have heard about it and thought ‘‘this is something I would like to know more about, or even try out’’. Still others, often in the digital field, get it mixed up with user-centred design, or some form of usability studies. This issue is for all of you, as we think that even those who know participatory design well will come away with new insights. Participatory Design (PD) is a hybrid of many sorts. There is an old parable about a camel (or an elephant). In the Western world’s tradition, the story claims that one or the other animal was designed by a committee, resulting in a hybrid that is neither one thing nor another – a rather funny looking and awkward animal. On the other hand, to people from the Middle East, Africa or Asia, a camel (and indeed an elephant) is an elegant animal with many useful purposes. We know that participatory design is the latter: an elegant animal with many useful purposes. However, it is often cumbersome and awkward to design a project and ride it to completion using a participatory approach, as participation is complex, messy and can be slower moving. Those who are familiar with the research traditions of Participatory Research (PR) and its more active sibling, Participatory Action Research (PAR), know that there is a spectrum where research can be by, for and with, people who will benefit from it (Whyte 1991; Greenwood & Levin 1998). Participatory Action Research (called Action Research in some countries) bends more toward outcomes, starting out with the needs of the participants, with researchers engaging and supporting them in participant-defined goals. Participatory Design practices fall within these research traditions, but with the added twist that it is design-oriented work, where the design may be anything from a digital application to a complex urban environment. Both the process and the product are shaped. In the digital realm, PD shares some theories and methods with user-centred design and interaction design, but the main thrust is on democratic and emancipatory practice. In short, it has an agenda for social justice. In the traditions we discuss here, most of what gets called Participatory Design is done by, for and with people who are using some kind of digital technologies – from traditional computer systems to interactive hand-held multimedia devices. But PD can also be applied, as we shall illustrate in this volume, for designing: situations that can confront dominant groups; designing tapestries and weavings; designing parks, bridges and train stations; designing digital storytelling; and designing teaching and learning environments. CoDesign Vol. 8, Nos. 2–3, June–September 2012, 81–85

The head and the heart: using gender analysis to study the social construction of computer systems

In recent years there has been a good deal of healthy experimentation with system development methods and work organization, particularly within Scandinavia. This paper attempts to go further into the questions of the development and use of computer systems by using a gender analysis of the issues. Specifically, it examines the organization of labor and patterns of communication used in developing computer systems. It suggests that the use of gender-biased dichotomies strongly influences both the questions system developers ask and the way questions are asked.

The design challenge—creating a Mosaic out of chaos

As designers we usually find ourselves—and our designs— in complex organizational settings, where diverse and often conflicting interests co-exist. Yet design is often seen as a process where the ‘one best solution’ is developed instead of allowing the rich mosaic of conflicting perspectives to be brought to light. Sooner or later the official pictures of the foreground are contradicted by current practice and create conflicts that may seriously jeep ardize systems built on them. With hindsight we can see how this happened, for example in the 1960’s and ‘70’s when mainframe system software was designed to follow the automation-like flow of production work, controlling work process and workers and dividing labour and tasks. In the 1980s, despite the use of new software tools and the emphasis on PC-based applications, designers focused on the tasks and procedures of given work flows instead of embarking on approaches that would have allowed them to learn about how new software might be appropriated, put to use and tailored in an organization.