Kim Halskov Madsen

Computer support for cooperative design (invited paper)

Computer support for design as cooperative work is the subject of our discussion in the context of our research program on Computer Support in Cooperative Design and Communication. We outline our theoretical perspective on design as cooperative work, and we exemplify our approach with reflections from a project on computer support for envisionment in design — the APLEX and its use. We see envisionment facilities as support for both experiments with and communication about the future use situation. As a background we sketch the historical roots of our program — the Scandinavian collective resource approach to design and use of computer artifacts, and make some critical reflections on the rationality of computer support for cooperative work.

Cooperative usability practices

Usability activities are often applied to development processes as a means of bridging the gap between users and developers. Due to this middle position, which at times can be extremely vulnerable, usability groups need to cooperate and establish appropriate relations with both users and development teams. They need to cooperate with users to obtain knowledge about their work practices, and they need to cooperate with developers to make them apply this knowledge about work practice. In this article we provide an overview of the practices of usability groups in the three U.S. and the three Danish companies featured in this section. Based on their practices, we discuss the usability groups’ relations to developers and users and examine some of the differences between the groups and between the countries. The Danish companies: Bang & Olufsen (B&O), Danfoss, and Kommunedata (KMD), were the first three Danish companies to have usability lab facilities. These three companies are participating in our research project, “Usability in Danish Industry,” which is a three-year project that aims at developing the theoretical and practical foundations of usability work. As part of “Usability in Danish Industry,” studies of usability practices have been conducted in 12 U.S. companies. Most of the studies have had a duration of several days and are based upon both observations of the work of usability specialists and interviews with a number of different people, including usability specialists and their managers. In this article we focus on the three U.S. companies featured in this section: IBM, American Institutes for Research (AIR), and Microsoft. In a previous overview of usability labs, Nielsen [5] focuses on quantitative measurements of the physical characteristics of the lab: size of the floor space, number of rooms, number of cameras, existence of one-way mirrors, and number of staff members. Our overview Usability engineering and

Experiences using cooperative interactive storyboard prototyping

T h e i n t e r f a c e s o f c o m p u t e r s y s t e m s e m b e d d e d in c e r t a i n t y p e s o f c o n s u m e r e l e c t r o n i c p r o d u c t s a r e f r e q u e n t l y t a r g e t s o f c r i t i c i s m . P e r h a P S t h e m o s t f r e q u e n t l y c i t e d e x a m p l e s o f p o o r u s e r i n t e r f a c e s (UIS) a r e t h o s e a s s o c i a t e d w i t h v i d e o c a s s e t t e r e c o r d e r s (VCRS).

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-

Participatory analysis of flexibility

Analysis as part of requirements gathering, conducted according to conventional systems development approaches like structured analysis and object-oriented analysis, focuses on standard data formats and general data flow. The data dictionaries and data flow diagrams of Yourdons structured project life-cycle [21] model the general standard data format and flow, respectively. Within the object-oriented paradigm Booch [2] emphasizes, quoting W. Wulf, that: We (humans) have developed an exceptionally powerful technique for dealing with complexity. We abstract from it. Unable to master the entirely of an object, we choose to ignore its essential details, dealing with the generalized, idealized model of the object. (Our emphasis).

The diversity of usability practices

A usability lab was originally a testing room and an observation room separated by a oneway mirror. For a formal usability test, a single user is brought into the testing room, which, in addition to the software product to be tested, contains video cameras and microphones for recording sessions. After the test, the usability expert’s analysis of the videotape is reported to the developers. Current usability practice is much more diverse, and has changed from being an addon to the development process to becoming an integrated part of it. Usability work encompasses a broad range of activities, including field studies of work practice, cooperative prototyping, user workshops, and post-release tests. Today’s usability practitioners aim at creating a realistic context of use for these activities by working outside the conventional lab, or by equipping the lab with documents, tools, and other elements from the users’ daily environment. The lab suite in its original form is playing a steadily decreasing role. Usability work is becoming a cooperative

Methods & tools: context: an active choice in usability work

T The concern for usability in the Danish software industry has become more visible because of usability labs or usability groups within software companies. In the BIDI (Brugbarhedsarbejde I Dansk Industri, in English: Usability work in Danish industry) project , we are collaborating with Bang & Olufsen, Danfoss, and Kommunedata, the first three Danish companies to have usability lab facilities.

Methodological Challenges in the Study of Technology Use at Home

Based on the planning and conduction of a longitudinal field study of the use of television sets in the homes of two families, we discuss how approaches like field studies which are otherwise well established when designing for work practices, becomes questionable when transferred to a home setting where the issue of privacy is prevalent. The fairly sporadic operation of a TV set poses additional methodological challenges. Furthermore, we point out how our general concern of designing for development in use becomes even more relevant with the introduction of interactive technology in the home sphere. Key elements of the approach applied include: hands-on in context, incident diaries, scenarios, iterative and explorative investigation, and role playing.

Customer‐vendor co‐operation

Illustrates a case story detailing the customer‐vendor co‐operation in a project concerning the beta test of hardware and software at a radiology department. A qualitative analysis of the project has unveiled that contextual conditions like the nature of the technology, the organizational structure at both the customer and the vendor side, the development strategy, and the project organization were very important forces during the project. Technologically, the project was more complex than usually was seen at the hospital because it concerned both biomedical and administrative aspects. Conflicting interests in particular on the part of the customer side as well as between the customer and the vendor affected the course of the project. Methodologically, the project lacked a proper strategy for the co‐operative process. There was no formalized project organization which otherwise could have provided different conditions for the project.

Design as interaction with computer based materials

Professional practice of designers as traditionally portrayed in academic text books and scientific papers only remotely resembles the concrete phenomenolog of real life activities. Design is not primarily governed by instrumental rationality, scientific theory, and techniques applied to specific problems defined at the outset. Rather than that as ilhwtmted in this paper by a case study of protocol designers the professional practice of design is a reflective interaction with computer based materials. The practice of the protocol engineer is very similar to the practices of other prof=ionals, but the anaIysis also reveals some characteristics specific to the particular design case. When the protocol engineer was experimenting with a specific aspect of his design at different stages in the design process, he was careful not to manipulate the model in a way that would violate other aspects of the model currently not in his fbcus. Some moves intended to solve one problem produced unintended effectsleading to new problems to solve. The design formalism and the design tool 1) made it ease work with different and coherent design representations in the same computerized medi~ 2) provided the opportunity to study the behavior of the model at a slower speed than in the built world, 3) made it easy to set up a large number of experiments, 4) and to create and explore aspects of the model which would be extremely expensive to explore in the built world. Keyworde Design Practice, Instrumental Rationality, Coloured Petri Nets, Protocol Design. INTRODUCTION According to Sch5n [12], professional knowing and practice in a diversity of areas such as the ones of designers, engineers, architects, psychotherapists, and managers have a number of common characteristics and are in addition more complex than traditionally portrayed in academic text books and scientific papers. The work of Sch6n challenges the predominant view on professional practice as one where general principles, scientific theory, and techniques are applied to specific problems defined at the outset. Rather than tha~ professional practiceinclud Permission to make digital/hard copy of part or all this work for personal or classroom use is granted without fee provided thet copies sre not made or distributed for profit or commercial advantage, the copyright notice, the title of the publication and its date appear, and notice is given that copying is by permission of ACM, Inc. To copy otherwise, to republish, to post on servers, or to redistribute to lists, requires prior specific permission and/or a fee DIS ’97 Amsterdam, The Netherlands @ 1997 ACM 0-89791 -863 -0/97 /0008 .,.