Using Pattern Languages in Participatory Design

In this paper, we examine the contribution that pattern languages could make to user participation in the design of interactive systems, and we report on our experiences of using pattern languages in this way. In recent years, there has been a growing interest in the use of patterns and pattern languages in the design of interactive systems. Pattern languages were originally developed by the architect, Christopher Alexander, both as a way of understanding the nature of building designs that promote a 'humane' <X" living built environment; and as a practical tool to aid in participatory design of buildings. Our experience suggests that pattern languages do have considerable potential to support participatory design in HCI, but that many pragmatic issues remain to be resolved. INlROOUCTlON The pattern language concept was originally developed, by the architect Christopher Alexander and his colleagues, both as a theoretical account of the properties of a humane, or ' living', built environment [2, 3, 5] and as a practical tool to aid participatory design processes [I, 41. Patterns and, to a lesser extent, pattern languages have been widely adopted within software engineering as a form for sharing knowledge about ' good' design solutions between professionals [15], but the approach to patterns adopted in software engineering has ignored the participatory aspects of Alexander'S original work. In recent years, there has been a growing interest in the use of patterns and pattern languages to support humancomputer interaction (HCI) design [8, 9, 31]. Much of this work has been inspired by the perceived success of patterns in software engineering. Of course, the parallels between architectural and interaction design, with their In PDC 02 Proceedings of the Participatory Design Conference, T.Binder, J . Gregory, l.wagner (Eds.) MalmO, Sweden, 23-25 June 2002. CPSR, P.O. Box 717, Palo Alto, CA 94302 cpsr@cpsr.org ISBN (}'9667818-2-1. 104 common concern for the design of the human environment, are arguably closer than those between architecture and Software Engineering. This may suggest that the benefits of developing pattern languages in HCI may be even greater than in Software Engineering. However, the approach to pattern languages adopted within HCI has followed closely that of software engineering, with the emphasis on sharing knowledge between professionals rather than on processes to support user participation in design. For example, the definition of a pattern language generated at the Interact'99 patterns workshop states: "The goals of an HCI pattern language are to share successful HCI design solutions among He! professionals . " (our emphasis, as quoted in [9, p39]). In this paper, we report our experiences of developing and evaluating pattern languages as aids to participatory design of web-based systems. From our studies we have identified a number of important issues that require further examination. These issues may also be of interest in other contexts where externally produced design advice is being used within a participatory design process. Structure of this paper In the next section, we introduce the concept of patterns and pattern languages as used in architecture, software engineering and HC! We then describe the approach we are developing for using pattern languages in practice and how it relates to Alexander's approach. We then make a number of observations both about the form of pattern languages and practices using them derived from our investigations. Finally, we discuss relationships with other work, and issues we hope to address in the future . PATTERNS AND PATIERN I.ANGUAGES Pattern Languages in Architecture Alexander introduces design patterns as follows: "Each pattern describes a problem which occurs over and over again in our environment, and then describes the core of the solution to that problem, in such a way that you can use this solution a million times over, without ever doing it the same way twice" [2, preface p. x). Alexander's pattern language includes patterns addressing different physical scales ranging from the distribution of cities [2, pattern 1), the organisation of communal space, e.g. 'Access to Water' and' Accessible Green' [2, patterns 25 & 60), through to patterns addressing detailed structure in individual rooms, e.g. 'Windows which Open Wide' and 'Alcoves' [2, patterns 236 & 179). An intermediate level pattern is 'Light on Two Sides of Every Room', for which the problem and solution are stated as: "Wben they have a choice, people will always gravitate to those rooms whicb have Iigbt on two sides, and leave the rooms wbicb are lit only from one side unused and empty.