• | • 
The Need for a Lingua Franca for Design:
From Sacred Places to Pattern Languages
Thomas Erickson
IBM T. J. Watson Research Center
snowfall@acm.org
ABSTRACT
A central challenge in interaction design has to do with its diversity. Designers, engineers, managers, marketers, researchers and users all have important contributions to make to the design process. But at the same time they lack shared concepts, experiences and perspectives. How is the process of design-which requires communication, negotiation and compromise-to effectively proceed in the absence of a common ground? I argue that an important role for the interaction designer is to help stakeholders in the design process to construct a lingua franca. To explore this issue, which has received remarkably little attention in HCI, I turn to work in urban design and architecture. I begin by discussing a case study in community design, reported by Hester [9], that demonstrates the power of a lingua franca for a particular design project. I then describe the concept of pattern languages and discuss how they might be adapted to the needs of interaction design in general, and used, in particular, as meta-languages for generating lingua francas for particular design projects.
Keywords
Design methods, patterns, pattern language, interaction design, interdisciplinary
design, architecture, urban design
INTRODUCTION
The fundamental premise of this paper is that the design of interactive systems is, at its heart, a communicative process. Successful design requires communication-presentation, discussion, disagreement, negotiation, compromise, and so on-among a diverse array of people.
If we take this premise seriously, it raises the question of how we go about supporting the communicative aspect of design. And, indeed, there has been a lot of work to this end. The basic repertoire of designers' tools-storytelling, scenario-making, prototype building, user testing, etc.-are all methods which aim to improve communication. However, often these tools are 'owned' by the designers-that is, they require the designers' expertise to deploy, administer, operate or interpret. Workers in the participatory design tradition (e.g. [12; 16]) have explored various approaches to making these tools more open, but more remains to be done.
The fundamental goal of this paper is to describe and explore one approach to making communication in design a more egalitarian process: the notion of creating a lingua franca-a common language-for a design project. The idea is that a lingua franca is accessible to all stakeholders, particularly those who are traditionally marginalized in the design process: the "users."
The paper begins by making the case for a lingua franca, arguing that the increasing complexity and diversity of the design process creates a need for common languages. Next, drawing from the urban design literature, it describes the example of the redevelopment of the town of Manteo, North Carolina [9]. Manteo provides an illustration of the possibility-and the power-of creating a lingua franca as part of a design project. The third part of the paper turns to the topic of pattern languages. Originally developed in architecture, by Alexander and his colleagues [1, 2], pattern languages have been taken up by the object oriented programming community (e.g. [11; 10; 18; 19; 17]) and are now seeing increasing interest from the HCI community [e.g. 3; 7]. The paper describes Alexandrian pattern languages, discusses why they are well suited to the creation of lingua francas, and explores how they might be used to support interaction design.
THE NEED FOR A LINGUA FRANCA
The interactive systems design space is growing rapidly. From the technical vantage point it is evident that microprocessors are continuing to shrink in terms of their cost, power, and space requirements. This, in combination with similar trends in sensing and effector technologies, and the increasing ubiquity of wireless communications, provides a host of new possibilities for making technology an intimate part of daily life. A panoply of products-reactive rooms, interactive walls, augmented objects, smart jewelry, implanted chips-all conspire to make interactive systems more and more entwined with the minutia of our daily lives.
To me, it feels as though this new intimate relationship with interactive systems is coming quite rapidly, quite a bit more rapidly, perhaps, than we are able to cope. That is, quite simply, how do we figure out how to design such systems? While we certainly understand, in principle, how to make such systems usable, it is not clear that we know how to make them useful. How can we design interactive systems so that they enhance the quality of our lives? Or, at the very least, how do we go about doing interactive systems design so that it doesn't disrupt our lives?
The challenges posed by the increasing size of interactive systems design space are exacerbated by another trend: the increasing diversity of the design process. This is, in part, a side effect of the increasing size of the interactive systems design space. While it is well accepted that visual designers and social scientists, as well as technologists, have roles to play in interactive systems design, as interactive systems colonize an increasing number of product niches more disciplines will become involved in the design process. Architects, musicians, video artists, fashion designers, jewelers, are all playing increasing roles in the design of interactive systems. Similarly, the more entwined interactive systems are with daily life, the more 'users' (who are, of course, no more homogenous than 'designers') need to be involved in the design process. All of this diversity poses a problem: how are the various stakeholders in the design process to communicate with one another, when they share little or nothing in the way of a core discipline, practice, or theoretical basis?
This brings us to the concept of a lingua franca, a common language which is accessible to all the participants in a design process. The idea to be explored here is that part of the process of interactive systems design should be the development of a lingua franca for a particular design project, a common language which permits stakeholders to participate more completely in the design process. In the next section, we look at an example of a simple lingua franca that emerged during a design process, and in the following section we look at an approach for generating lingua francas for particular projects.
THE POSSIBILITY OF A LINGUA FRANCA
The content of this section is drawn almost entirely from an article by Randolph T. Hester, Jr. [9]. In addition to its description of an interesting design process, the article is noteworthy because it is retrospective: the designer returned to the site of the design seven years later, and assessed how the design-and the remnants of the design process-fared over the long term.
The Problem
In the 1950s North Carolina built a bridge to facilitate tourist travel to the beaches of its Outer Banks. While this was a boon to the Outer Banks' tourist trade, it was a slow catastrophe for the town of Manteo, North Carolina, which was bypassed by the new highway and the flow of tourists. Over the next thirty years Manteo changed from the region's principal trade center to a near ghost town with the highest unemployment and tax rates in the state.
In 1980 the town of Manteo asked Hester, a community designer, to devise a plan to bring about an economic revival by developing Manteo's historic waterfront to encourage tourism. At the same time, the residents wanted to preserve the aspects of Manteo that they valued; they didn't want to sacrifice the town's character to tourism.
The Beginning of the Process
Hester began by trying to identify what it was that residents valued about their town. Initially he used surveys and face to face interviews to explore what was important to the residents. These techniques resulted in a number of general findings: people valued small-town qualities such as friendliness and informality; they also saw certain areas (e.g., the waterfront) and places (e.g., particular shops) as important to their quality of life.
Figure 1. An Activity Map of The Dutchess restaurant, indicating that locals often gathered in a corner booth.
Hester and his team were not satisfied by these findings. It was not obvious how to move from the general sentiments expressed to decisions about what might be changed and what ought to be preserved. So Hester and his colleagues turned to an approach they called "behavior mapping." This involved observing and recording the activities of the townsfolk over a period of several weeks. The result was a set of sketches of settings and maps of place-based activity that seemed important to the life of community. Mapped behaviors included activities such as "hanging out at the docks", "watching the sunset", and "debating politics in the Dutchess restaurant" (figure 1). As Hester said, "Lifestyle and landscape were intertwined. Daily ritual was place-specific, and the cultural dependence on places seemed more widespread than people had reported in our interviews." It is interesting to note that most of the places in which seemingly important activities were observed had not been mentioned in the surveys or interviews.
Validation and Ranking
The next step was to verify that the places where the activities occurred were actually important to the residents. Using information from the surveys, interviews and behavior mapping, and drawing on knowledge of social patterns in other towns and discussions with Manteo's leaders, Hester and his team generated a list of 'important places'. The list, in conjunction with a newspaper based questionnaire, was used to allow the residents to rank the places in order of their importance. The idea was that items above a certain point would be protected from development. The results were collated, and the resulting list was published in the town newspaper. One resident, observing that quite a few places were ranked higher than the local churches and cemetery, dubbed the list "the Sacred Structure of Manteo." The name stuck, and came to be used for the places that were to be preserved and protected.
Manteo's "Sacred Structure"
Manteo's sacred structure-eventually codified in a map (figure 2)-consisted of rather mundane places. As Hester notes, "these places are almost universally unappealing to the trained professional eyes of an architect, historian, real estate developer, or upper-middle-class tourist." For example, the sacred structure included the marshes surrounding the town, a park, the Dutchess restaurant, locally made (unreadable) street signs, and a gravel parking lot where people gathered to watch the sun set and where the town's Christmas tree was set up. Of the sacred places, only two were protected by historic preservation legislation, and a few more by zoning laws; that is, the existing planning and legal mechanisms that were intended to help preserve the character of places missed most of what the residents of Manteo actually valued.
Figure 2. Manteo's Sacred Structure map.
The codification of Manteo's sacred structure had a number of important consequences. First, it shifted the discussion of the town's redevelopment from the abstract ('let's keep it friendly and homey') to the concrete ('let's keep the Dutchess restaurant and the gravel parking lot'). Second, it enabled the residents to see that each person's preferences weren't idiosyncratic: for the first time, for example, it became evident that many people liked the unreadable street signs. Third, the sacred structure map became a vehicle for legitimization. That is, Manteo's sacred structure was not, as already noted, composed of impressive buildings or places. Indeed, Manteo was not a particularly "quaint" place, and occasional disparaging comments from tourists led many residents to feel that the unpretentious places reflected poorly on their town. When the design team recognized that locals were somewhat ashamed, they stepped forward and spoke in favor of the places, and the townspeople came to feel that their values were legitimate.
A Common Vocabulary
Over time, the sacred structure map became a part of the local vocabulary, and, by so doing, it came to serve as a collective tool for controlling the development of Manteo. The concept of Manteo's sacred structure played two important roles. One role was that of a measuring rod. What the sacred structure really did was to project abstract values onto concrete places. That is, while it may be difficult to see whether building a shopping mall in a particular location will decrease the friendliness of the town, it is very easy to see whether it will require the marsh to be filled in, or the gravel parking lot to be built on. Second, the sacred structure also served as a negotiating tool. It provided a way for residents to articulate their intuitive responses to particular development plans and proposals. And, because the sacred structure was representation that the townspeople shared, it gained power. A developer intent on building a strip mall on the gravel parking lot might ignore the first few people who described it as a sacred structure, but, as the developer encounters more and more people who speak of it in the same way, a powerful impression is formed.
Seven Years Later: Manteo's Sacred Spots
Hester's work did not stop with the creation of Manteo's sacred structure; the process continued for several months, resulting in a development plan and the solicitation of proposals from developers. However, we will not look at that; instead we will jump ahead seven years to when Hester returned to Manteo to see how the plan had fared over the years.
The redevelopment effort had been extremely successful in stimulating economic growth without destroying what residents liked about the town. However, what is of primary interest here is the degree to which the community's knowledge of Manteo's sacred structure had persisted. The residents of Manteo-not just politicians and planners, but 'ordinary people' as well-continued to refer to it, though by this time they used the phrase "sacred spots". Hester reports that his interviews with residents revealed that knowledge of the town's sacred structure influenced the redesign of the Dutchess restaurant, the rebuilding of Fearing's Soda Shop (another part of the sacred structure) after it was destroyed in a fire, and that "community members have consistently undertaken similar conscious actions to save and enhance what they now call 'Sacred Spots.'"
Discussion
To me, this is an amazing and inspiring result, perhaps the highest goal to which a designer can aspire. Hester's work in Manteo resulted not only in a plan for achieving economic renewal without sacrificing the town's character (the explicit goal he was employed to achieve), but it also resulted in a shared, self-sustaining system of beliefs and values that enabled the plan to be realized over a much longer period of time.
It seems to me that a key aspect of this self-sustaining system was that it became part of the common language of the town. It gained its power because people had shared understandings and values, and because they knew that their understandings and values were shared by the community. I also believe that a critical aspect of the adoption of sacred structure as a shared vocabulary was that it was expressed in terms of concrete objects that were part of the community's everyday life.
If we agree that the emergence of Manteo's sacred structure as a shared vocabulary provided a tool that allowed a community to exert some control over its own development and evolution, and if we agree that such control is desirable, the next question that arises is whether this process is repeatable. That is, it may be that the circumstances in this case-a skilled design team, a receptive populace that was well aware of both the need to change and the perils that accompany such change, and a situation in which the central issues could be bound to everyday objects-are so unusual as to preclude repetition of the process. Or, it may be that the process that occurred in Manteo requires so much effort to support, that it is impractical to apply in most cases (i.e. when the stakeholders do not see the outcome of the design process as fundamentally shaping their future).
However, I suggest that there is reason for optimism. In the next section I describe a method-drawn, again, from architecture and urban design, but distinct from that employed by Hester and his colleagues-which offers a path to the same end. I discuss the concept of pattern languages, and will argue that they offer an approach to creating lingua francas for various design projects.
PATTERN LANGUAGES AS LINGUA FRANCAS
In this section I describe a pattern language for architecture and urban design developed by Alexander and his colleagues [1, 2]. Alexander's pattern language* is a network of patterns of varying scales embodied as concrete prototypes. The goals of Alexander's pattern language range from supporting the design of environments that have what Alexander calls "the quality without a name," to-most relevant to our purposes-helping non-architects participate in the design of their own environments. Alexander's pattern language addresses the latter goal by providing its users with a common language that enables them to reflect on their experiences and on the relationship between their experiences and their environment.
Ways in Which Pattern Languages are Used
Before we examine Alexander's pattern language, it's useful to provide a bit of context. First, it's important to emphasize that the pattern language is more than an engaging theory: it has been used by a wide variety of people for nearly two decades. The firmest evidence is that the book of design patterns, A Pattern Language [2], continues to be a best selling architecture book after nearly two decades on the market, even though it is available only as a rather expensive hard back. There are a couple dozen published accounts of building projects employing patterns (see [8] for some of these). A practicing architect who sometimes uses patterns tells me that Alexander's approach has a relatively small following within the architecture profession; many architects appear to have been alienated by his sometimes intemperate rhetoric which includes attacks on the structure of the profession. Most use of pattern languages appears to be by those outside the architecture profession: designer-builders, and people with no design training whatsoever who simply wish to remodel or build their own homes [15]. The continuing popularity and use of Alexander's pattern language by layfolk is, of course, an argument in favor of its status as a lingua franca.
In the last decade, pattern languages have become popular among technologists. In the early nineties, they began to be appropriated by the object-oriented programming community, who have employed them to support the production and re-use of high quality programming constructs. The Communications of the ACM published a special issue on software patterns [13], and there are now annual conferences, mailing lists, web sites, and books (e.g., [5, 10, 11, 19]) devoted to the application of patterns to object oriented software design. For example, Gamma, et al. [11] have produced a book of design patterns for reusable components and object classes. At a different level of inquiry, Coplien [5] has proposed a family of patterns for shaping software development organizations and processes. More recently, beginning with the CHI '97 workshop on pattern languages [3], pattern languages have begun to attract increasing interest within the HCI community [7], with four more workshops in 1999 and 2000.
I should begin by acknowledging that my view of the role and usefulness of pattern languages differs from the perspectives of other exponents of pattern languages. The two most oft-cited rationales for the use of pattern languages are these:
Quality. Pattern languages will support the creation of systems that have what Alexander and his colleagues [1, 2] call "The Quality Without a Name"-this is a shorthand for systems which really 'work' for people, in all of the many meanings of that phrase, and
Re-Use. Pattern languages permit the re-use of the hard-won wisdom of designers, allowing the accumulation and generalization of successful solutions to commonly encountered problems.
As should be evident from the preceding sections of this paper, my concern is with pattern languages as a possible lingua franca for design process. This concern is not entirely divorced from Alexander's views. Although Alexander focuses on the use of pattern languages for achieving the quality without a name, he has much to say about pattern languages as common languages. For instance, in A Timeless Way of Building [1] he argues that, in pre-industrial societies, pattern languages were not the domain of specialists like architects, but were shared by all members of a community:
In a town with a living language, the pattern language is so widely shared that everyone can use it. (page 229)
And he goes on to say:
Each person in a town knows that his own small acts help to create and to maintain the whole. Each person feels tied into society, and proud because of it. (page 231)
This seems in remarkable synchrony with what happened in Manteo, with the creation of the sacred structures leading to a shared understanding that certain places were valued by the community, and that those valuations were legitimate. This lends some credence to the supposition that pattern languages are not disconnected from the events in Manteo.
Now let us turn to the pattern language for architecture developed by Alexander and his colleagues. There are several purposes to our examination. One is to dispel a number of common misconceptions about pattern languages. A second is to discuss pattern languages are representational systems, in general, and a representational systems suitable for constructing lingua francas, in particular. Finally, it is very difficult to understand pattern languages without giving an extended example, and so we will do that as well. Once we've covered Alexander, et al's work, we will return to its relationship with the wider field of interactive systems design.
Example: A Pattern Language for Architecture
Alexander's language consists of a network of 253 patterns. The patterns range in scale from a pattern for the distribution of towns and cities down to a pattern for walls. The patterns are loosely connected across scales: any given pattern typically points to smaller scale patterns which can support it, and larger scale patterns in which it may participate. For example, the IDENTIFIABLE NEIGHBORHOOD pattern (aimed at creating neighborhoods with their own sense of place) invokes smaller scale patterns such as STREET CAFE, INDIVIDUALLY OWNED SHOPS, and CORNER GROCERY, and participates in larger scale patterns such as MOSAIC OF SUBCULTURES that specify characteristics of communities.
A common misconception is that pattern languages are sets of templates that are rigidly applied to situations. This is not the case. Alexander's pattern language is actually a meta-language. Both the language and individual patterns are malleable and are used to generate a site-specific pattern language for a particular project. Alexander describes the process of generating a pattern language [2, pp xxxviii-xl] as follows:
- 1. Choose the pattern which best describes the overall scope of the project
- 2. Go to the end of the pattern, where it refers to the smaller scale patterns which support it, and make a list of the patterns which seem to apply.
- 3. For each pattern selected in step 2, repeat step 2, and also examine the larger scale patterns at the beginning of each pattern, adding any relevant patterns to the list.
- 4. Repeat steps 2 and 3 until you have worked your way through the list of patterns.
- 5. Adjust the list of patterns by adding your own material, either by modifying existing patterns so that they are more relevant to the current situation, or by creating new patterns.
- 2. Go to the end of the pattern, where it refers to the smaller scale patterns which support it, and make a list of the patterns which seem to apply.
Thus, for any particular situation, Alexander's pattern language is used to generate a subset of its patterns; in addition, users modify existing patterns and create new patterns so as to reflect the culture, environment, history, customs and goals of the site's location and inhabitants. These patterns-old, modified, and new-form a site-specific language which is used to guide reflection and discussion about the relationships among the site, the proposed design, and the activities of the inhabitants.
Let's look at an example of a pattern. Each pattern is presented in a standard form which provides a prototypic example of the pattern, describes its relationship to other patterns of larger and smaller scales, as well as describing the pattern's rationale and implementation. Figure 3 shows an abbreviated version of pattern 88-STREET CAFE [2]. (It is important to note that this, and all other patterns described in this paper, are greatly abbreviated: Alexander's patterns average about four pages in length.) STREET CAFE begins with its name, number, and (omitted) photograph of a sidewalk cafe. The first paragraph describes some of the larger scale patterns (e.g. ACTIVITY NODE; IDENTIFIABLE NEIGHBORHOOD) of which it is part. These pointers to larger scale patterns support the generation of particular, project-specific languages, though the process just described. Next is a statement of the essence of the pattern, followed by a longer rationale (most omitted from figure 3) which describes the background of the pattern, evidence for its validity, and ways in which the pattern can be manifested, etc. For example, in this case, the discussion ranges from a careful description of the experience of being in a cafe, to an analysis of the elements of successful street cafes, to discussion of a survey on the role played by student-oriented cafes in educational settings. The extended rationale for the pattern is quite important because it helps the user judge how appropriate it is for the situation to which it's being applied, and whether the pattern needs to be modified to fit the current situation. The pattern concludes with a short statement describing how to implement the key features of STREET CAFE, and another paragraph with pointers to smaller scale patterns -- such as OPENING TO THE STREET and SITTING WALL -- which may be used to strengthen this pattern. Again, these pointers support the generation of project-specific languages.
Pattern Languages as Representations
Alexander's pattern language has a number of attributes that make it suitable for forming the basis of a lingua franca.
Concrete Prototypes. Alexandrian patterns are embodied as concrete prototypes, rather than abstract principles. Every pattern comes with a name (often sufficient to evoke an image), a picture of an archetype of the pattern, and a diagram of how it is implemented. This is true for patterns at large scales (e.g., AGRICULTURAL VALLEYS, RING ROADS) and at small scales (e.g., THICK WALL, CHILD CAVES). Whereas abstract principles require users of the principles to understand some conceptual framework, and to be able to map the principles onto their domain of concern, the concrete prototypes in pattern languages make direct contact with the users' experiences. Anyone who has experience with the situation can begin to understand, discuss, and contest Alexandrian patterns.
Grounded in the Social. Another characteristic is that the patterns tend to focus on the interactions between the physical form of the built environment and the way in which that inhibits or facilitates various sorts of behavior within it. Thus, STREET CAFE emphasizes the importance of location along a busy path because this facilitates casual meetings, people watching, etc. This linkage between the components of design and everyday activity reinforces the concrete, grounded nature of the pattern language.
Expresses Values. Alexander's Pattern Language is not value neutral. Patterns such as INDIVIDUALLY OWNED SHOPS, BIKE PATHS AND RACKS,FARMHOUSE KITCHEN, and OLD AGE COTTAGE all manifest particular values in their names alone (and more explicitly in their rationales). While this aspect of A Pattern Language can alarm those who view it as prescriptive -- that is, who think it is intended to be The pattern language -- I see its ability to clearly and explicitly express values as part of its representational power, and as yet another way the language becomes grounded for its users.
Supports Piecemeal Use. Finally, pattern languages are amenable to gradual, piecemeal use. If a pattern language exists for a particular domain, users can begin with just a few patterns and work out from there. If a pattern language is being developed from scratch, it feels natural to start with particular cases, and to identify patterns which recur from one case to another. It is easy to imagine identifying a few basic patterns, and then testing and re-testing them as new cases are encountered, creating more general patterns, and defining more particular ones as appropriate.
|
88 STREET CAFE
|
PATTERN LANGUAGES: LINGUA FRANCAS FOR INTERACTION DESIGN
Thus far I've argued that interaction design has an increasing need for lingua francas, I've given an example which illustrates the power and import of a lingua franca and, in this last section, I've introduced pattern languages as a means for generating lingua francas. In what remains, I explore how the pattern language concept-which was developed for architecture and urban design-might be transposed to other types of interaction design. In this, the final section, I discuss my explorations, and describe three fragments of pattern languages that might be used to design various sorts of interactive systems.
From Space to Time: A Language for Weddings
One important aspect of Alexander's Pattern Language is that its patterns are aimed at supporting the design of physical spaces. This gives them a very concrete character, and doubtless plays an important role in making them comprehensible to a wide audience. An important question for our purposes is whether it is possible to design a pattern language that is not aimed strictly at the built environment. That is, is it possible to develop pattern languages that are oriented towards events or situations?
An answer to this question, came, quite coincidentally, while I was working while sitting in a local cafe. Two women sat down at an adjacent table, and began discussing an upcoming wedding. As the conversation went on it became clear that one of them was a wedding consultant: her goal was to ensure that the wedding came off smoothly, and was a good experience for all concerned. I was struck by the similarity between her advice and Alexandrian patterns. And, although she did not frame her advice in these terms, what she was basically doing was describing patterns that could be used to design a successful wedding.
Here are a few examples of her recommendations.
- Have someone responsible for collecting extraneous objects from the bride and bridesmaids. The recommended procedure is to have a bunch of paper bags labeled with each person's name. About fifteen before the wedding begins, the collector should go to each bridesmaid and throw her things (e.g. hair dryer, make up kits) in her sack, and then take all the sacks and lock them in the trunk of a car. This prevents things from getting left behind in the excitement of going off to the reception, or stolen from the dressing room during the wedding ceremony.
- For the reception, arrange to have two people manning the gift table. Their task is not only to accept and watch gifts, but also to be armed with tape so that loose cards can be firmly attached to their packages. One person can be taping, while the other is receiving gifts. By ensuring that the cards and gifts remain attached, the bride is later able to complete the gifting ritual by sending thank you notes.
Clearly the wedding consultant understands the structure of the wedding experience, and realizes that the wedding experience is not just the ceremony and reception: it begins months before the wedding, and extends long afterwards. For example, she recognized that receiving gifts is part of a larger pattern which includes returning formal thanks, and she made sure that one of the smaller scale patterns (the gift reception table) was structured so as to allow the larger scale gifting pattern to be completed much later on. In general, she had identified many recurring wedding patterns, identified points where the wedding experience can potentially break down (typically where a pattern was protracted over time), and devised procedures for avoiding or repairing breakdowns.
Figure 4 recasts the Wedding consultant's first recommendation in the Alexandrian format, as though it were part of a pattern language for weddings. There are two marked differences from Alexander's patterns. First, time is an important element these of patterns. And second, people--or at least roles-- are important.
|
THE FINAL FIFTEEN MINUTES -- BRIDE
|
While the wedding consultant's 'patterns' provided a useful hint, weddings are still quite different from the sorts of situations that most interaction designers are face with in their work (although I believe that event design, and organizational design, are perfectly valid areas of interaction design). One might argue that while one could design a pattern language for weddings, it might be much more difficult to move from the relatively well structured domain of weddings (which tend to have similar goals, roles, structures, and rituals), to the more general, and less defined domains such as office work?
Towards an Office Interaction Pattern Language
A Pilot Study
Heartened by the wedding example, I decided to look for interaction patterns in a pilot study I had just conducted. The goal of the study was to do a rapid survey of the nature and structure of office worker's daily activities, as described in their verbal reports. Four people were interviewed for the pilot study: a newspaper journalist, a professor of architecture, a magazine editor (in charge of "new media"), and a professional mystery writer.
While I make no claims for the rigor of analysis or the breadth of this study, and am well aware of the limitations of relying on verbal reports, I was encouraged by the fact that the process of using patterns to capture regularities of interaction seemed straightforward.
Here are a few of the patterns that emerged:
- STAYING IN SYNCHRONY. All the people interviewed reported that they made various efforts to stay in synchrony with people and events that were relevant to their activities. Very often getting in synchrony (see CLOSING THE LOOP, figure 5) was one of the first activities of the day, and lead to the pattern Mapping out the Day.
- MAPPING OUT THE DAY. A common activity early in the day (and sometimes repeated later on, depending on the degree of change that characterizes the activity), is trying to structure the day, either formally or informally. (We know from other studies that people in extremely event-driven activities may not have the option of using this pattern.)
- BALANCE BETWEEN PRODUCTIVITY AND RESPONSIVENESS. Three of the four people we spoke with described their jobs as being filled with interruptions... but also said that responding to interruptions was part of their job, sometimes an interesting and enjoyable part. They described their work days as an effort to strike a balance between responding to events and colleagues, and accomplishing what they were 'supposed to be doing.' For them, the most important aspect of MAPPING OUT THE DAY was to schedule time for FOCUSED WORK. (The fourth person was a writer who worked at home, with very few interruptions. Interestingly enough, he described an important aspect of structuring his day as seeking out stimulation).
- FOCUSED WORK. All those interviewed described periods of concentration and reflection during which they worked on producing documents or other concrete artifacts. Each tried to structure their time and environment so as to minimize interruptions during these periods, and each had an (often elaborate) way of arranging their workplace to support this activity.
- BREAK FOR FOOD. Everyone mentioned taking a break to eat. Sometimes the break was used to socialize with colleagues; other times it was used as an opportunity for reflection. Often this pattern was followed by CLOSING THE LOOP.
Figure 5 shows one other pattern, CLOSING THE LOOP, sketched out in its canonical, Alexandrian form. As with the wedding pattern, this hints at how it might fit into a pattern language for describing larger situations, in this case, the daily life of an office-based knowledge worker. This pilot study left me feeling optimistic about the prospect of constructing pattern languages for the workplace. However, since shifting priorities at work took me away from directly studying office workers, I instead decided to try extracting patterns from an ethnographic studies of workplaces.
|
Unpacking an Ethnography
Elsewhere [6] I've described more fully a fragment of a pattern language for a design consultancy based on an ethnography by Bellotti and Bly [4]. Here, I will sketch the fragment, and talk about some of the ways in which it might be used.
The Design Consultancy language's goal is to characterize the design consulting business by describing the various forces which shape it. Thus the language depicts the firm's need to act quickly and flexibly to get, keep, and complete projects, balanced with its need to do this with limited amounts of time and materials, and relatively fixed number of employees. Its designers and engineers work on project-oriented teams, which form and reform as new projects begin and old ones end. The company culture encourages kibitzing and informal collaborations across team boundaries.
One of the largest scale patterns in Design Consultancy is MAINTAINING MUTUAL AWARENESS. This pattern captures the designers' and engineers' attempts to keep up-to-date with what was going on, regardless of the projects with which they were involved. This practice is crucial to allowing the company bring a wide range of expertise to bear on problems, and is a good counterbalance to the potential inflexibility of project-oriented teams. MAINTAINING MUTUAL AWARENESS is supported by a number of smaller scale activity patterns: BLANKET EMAIL (the custom of addressing email messages with questions or answers to large groups); KIBITZING; and DOING A WALKABOUT (i.e. wandering through the work areas to see what others are up to). MAINTAINING MUTUAL AWARENESS was also supported by spatial patterns such as OPEN OFFICES, MODEL SHOP and CENTRAL SCANNING STATION.
Another large scale pattern is LOCALLY MOBILE WORKERS. This pattern captures the fact that many engineers and designers spend considerable time away from their desks, but are still in the general vicinity. On the one hand, workers are pulled away from their desks by the need to get access to immobile shared resources such as MODEL SHOP and CENTRAL SCANNING STATION, or to find local coworkers with whom they need to collaborate. On the other hand, they are pulled back to their desks by the need to use desk-based personal resources (PCs, telephones, voice mail) or to collaborate with remote colleagues. Thus, the engineers and designers spend considerable time moving about, a fact which-as Bellotti and Bly note [4]-has considerable consequences for how they accomplish their work. Clearly, to the extent that locally mobile workers encounter others, this pattern supports MAINTAINING MUTUAL AWARENESS, at least for coworkers in the same locale.
Another pattern that goes hand in hand with LOCALLY MOBILE WORKERS is RECEPTIONIST AS HUB. The mobility of many workers produces a need for coordination, a way for one person to locate another when the need arises. In this workplace, Bellotti and Bly discovered that the receptionist played an important role in keeping track of people. This arose because her location and continuous presence at the entrance enabled her to observe the arrivals and departures of people. This was facilitated by her role as the conference room coordinator, which resulted in her being aware of the time, location and composition of meetings. Finally, some employees, recognizing her role as de facto coordinator, had adopted the practice of informing her of their anticipated whereabouts.
Many other patterns could be described-- OPEN OFFICES, SHARED RESOURCES, KIBITZING, BLANKET EMAIL, and DOING A WALKABOUT-but this is enough to give a flavor of the Design Consultancy pattern language. Let's now consider some ways in which it might be used.
I imagine that the design firm would own and maintain its own pattern language. Perhaps, in the future, corporations will have staff ethnographers whose job is to maintain the corporate pattern language, and make sure that it doesn't get out of synch with the actual life of the organization, which presumably gradually evolves under the influences of a myriad of internal and external pressures. Such a pattern language would be a key part of the firm's intellectual property: it would be how the firm understood itself; it would provide a way for the firm to reflect upon its success and failures and understand its strengths and weaknesses; it would provide a way of gauging the impact of new technologies, processes and people on its functioning. Just as Manteo had its sacred spots, so the design firm might have its 'sacred practices,' that is, activity patterns that it recognized as a core part of its culture.
For example, suppose that the design firm is considering the purchase of an automatic scheduling system. While the first order effects of this might be to reduce the receptionist's workload and to provide employees with more immediate access to room scheduling, consideration of the pattern language-in particular, RECEPTIONIST AS HUB and its supporting patterns-suggests that such a change might have less beneficial second order effects. For instance, reducing the receptionist's involvement in meeting scheduling might well reduce her effectiveness in keeping track of employees whereabouts. Or, to take a different example, switching from open offices to closed offices would could undermine MAINTAINING MUTUAL AWARENESS and KIBITZING.
The point here is not that these patterns and their relationships should be used to reject or approve changes, but rather that they can be used as a language for discussing changes and reflecting on their possible impacts, both in terms of the activities of the organization, and in terms of the qualities of work life which its members value. Just as Manteo was able to support economic redevelopment without sacrificing its quality of life, so might organizations of the future be able to evolve without sacrificing valued aspects of their corporate cultures.
CONCLUSION
I've sketched out my notion of design as an inherently communicative process, and suggested that pattern languages can have an important role as lingua francas. I've offered the redevelopment of Manteo, North Carolina as an illustration of how providing a community with a common, concrete language can give ordinary people more control over how design impacts their lives. And I've suggested that pattern languages-used as meta-languages to produce 'site-specific' pattern languages-might provide a shortcut to producing the sorts of lingua francas which played such an important role in the redevelopment of Manteo.
In the final section of the paper I've explored what it might mean to transpose the concept of pattern languages from the more spatial, fixed-site domain of architecture and urban design, to the more fluid domains (in which time and roles become important) with which interaction designers more commonly deal. In doing this, I've provided fragments of patterns, and hinted at the sorts of pattern languages they imply.
Obviously much remains to be done. My hope is that this paper will encourage others to explore the lingua franca problem, whether it be via the pattern language route, or alternate approaches. It seems clear that as the complexity, diversity, and pace of interactive systems design continues to increase, we will all need better methods of talking about what we're doing.
ACKNOWLEDGMENTS
This paper draws very heavily on the work of Hester [9], and Alexander, et al. [1, 2]; and Design Consultancy on the work of Bellotti and Bly [4]. In each case I am conscious that the interpretations I have advanced, and the liberties I have taken in synthesizing different types of work, are my own, and may not meet with the approval of the authors. I am indebted to two architects, Dale Mulfinger and Robert Boylin, who spent considerable time providing me with practicing architects' perspectives on Alexander's pattern language, as well as helping me to understand its reception and use by layfolk and by professional architects.
REFERENCES
- Alexander, C. A (1979) The Timeless Way of Building. New York: Oxford University Press.
- Alexander, C., Ishikawa, S., Silverstein, M., Jacobson, M., Fiksdahl-King, I., & Angel, S. A (1977) A Pattern Language. New York: Oxford University Press.
- Bayle, E., Bellamy, R., Casaday, G., Erickson, T., Fincher, S., Grinter, B., Gross, B., Lehder, D., Marmolin, H., Potts, C., Skousen, G. & Thomas, J. (1998) "Putting It All Together: Towards a Pattern Language for Interaction Design. Summary Report of the CHI '97 Workshop" SIGCHI Bulletin, ACM: January, 1998.
- Bellotti, V. & Bly, S. (1996). Walking Away from the Desktop Computer: Distributed Collaboration in a Product Design Team. Proceedings of CSCW '96.
- Coplien, J. O. (1995) A Generative Development-Process Pattern Language. In Pattern Languages of Program Design. (eds. J. O. Coplien and D. C. Schmidt). Reading, Mass: Addison-Wesley, 1995.
- Erickson, T. (2000) Towards a Pattern Language for Interaction Design.. In Workplace Studies: Recovering Work Practice and Informing Systems Design. (ed. P. Luff, J. Hindmarsh, C. Heath). Cambridge: Cambridge University Press. In press, 2000.
- Erickson, T. (2000) The Interaction Design Patterns Page. http://www.pliant.org/personal/ Tom_Erickson /InteractionPatterns.html. Version of February, 2000.
- Fromm, D. & Bosselmann, P. (1985) Mexicali Revisited: Seven Years Later. Places, Vol. 1, No. 4, pp. 78-91. New York: The Design History Foundation
- Hester, R.T. (1993) "Sacred Structures and Everyday Life: A Return to Manteo, NC. In Dwelling, Seeing, and Designing: Toward A Phenomenological Ecology (ed. David Seamon). SUNY Press, 1993.
- Gabriel, R. P. (1996) Patterns of Software: Tales from the Software Community. New York: Oxford University Press.
- Gamma, E., Helm, R., Johnson, R., and Vlissides, J. Design Patterns: Elements of Reusable Object-Oriented Software. Reading, Mass: Addison-Wesley, 1995.
- (1991) Design at Work: Cooperative Design of Computer Systems (eds. J. Greenbaum and M. Kyng). Hillsdale, NJ: Lawrence Erlbaum, 1991.
- Harper, R., Hughes, J.A. and Shapiro, D.Z. (1991) Working in Harmony: An Examination of Computer Technology in Air Traffic Control. In J. M. Bowers & S.D.Benford, (eds.). Studies in Computer Supported Cooperative Work: Theory, Practice and Design. Amsterdam: Elsevier, pp. 225-234.
- Heath, C. C. and Luff, P. (1991) Collaborative Activity and Technological Design: Task Coordination in London Underground Control Rooms. Proceedings of E-CSCW 91 (Amsterdam, Sept. 24-27 1991), pp. 65-80.
- Mulfinger, D. (1996) Personal communication, in a conversation on July 12, 1996, Minneapolis, Minnesota, U.S.
- Muller, M.J. and Kuhn, S. (1993) Participatory design. Communications of the ACM, Vol. 36, No. 6, pp 24-28.
- Sane, A. (2000) The Patterns Home Page. http://hillside.net/patterns/patterns.html. Version of June 10, 1999.
- Schmidt, D., Fayad, M., Johnson, R. (eds.) 1996. Special Issue on Software Patterns (eds. Communications of the ACM, Vol. 39, No. 10. New York: ACM Press.
- Vlissides, J. (1998) Pattern Hatching: Design Patterns Applied. Reading, Mass: Addison-Wesley.
site visits since 31 Jan 2005.
• | • 