indicating that locals often gathered in a corner booth
(redrawn from figure 12.3, page 277 [10]).
[Tom's Home Page]
[Professional] [Life,
Fun, &c] [Tell Me...]
[Bookmarks] [Publications
List] <and many papers and essays>
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 [10], 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.
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. [13, 15]) 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. A secondary goal is to encourage readers to join in exploring ways of creating design lingua francas. That is, I strive to raise important questions, share provocative examples, point to common resources, and suggest productive directions for research and design practice; however this is a new area of investigation for HCI-those looking for solid, empirically validated answers will not find them here.
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 [10]. Manteo provides an illustration of the possibility-and the power-of creating a lingua franca as part of a design project. The next two sections turn 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 [6, 11, 12, 16, 17, 19] and are now seeing increasing interest from the HCI community [3, 5, 7, 8, 18]. The sections describe Alexandrian pattern languages, discuss why they are well suited to the generation of lingua francas, and explore ways in which they might be used to support interaction design. The paper ends with a discussion of questions and issues raised by the paper's reviewers, and a summary.
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. By common language I am referring not just to vocabulary (otherwise English or another natural language would typically serve quite well), but to the conceptual frameworks which disciplines and professions bring to bear during the 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 all stakeholders to participate more fully in the design process.
In the next section, we look at an example of a simple lingua franca that emerged during a design process. The goal of this section is to demonstrate the power and importance of a lingua franca. However, the lingua franca described was hand crafted-it was developed from scratch specifically for the project described, requiring a considerable investment of time, energy and expertise. Since time, energy and expertise are typically limited resources in high tech design, the following sections introduce the concept of pattern languages, and explore the notion that they might serve as short cuts or scaffoldings for generating project-specific lingua francas.
The content of this section is drawn almost entirely from an article by Randolph T. Hester, Jr. [10]. 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.
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.
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.
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.
| |
| Figure 1. An activity map of The Dutchess restaurant, indicating that locals often gathered in a corner booth (redrawn from figure 12.3, page 277 [10]). |
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-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. A portion of Manteo's Sacred Structure map (redrawn from figure 12.4, page 278 [10]). |
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.
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.
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.'"
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).
For this reason it is worthwhile to examine a different approach to the creation of design lingua francas. 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-known as design patterns or pattern languages, which have the potential to lower the cost of creating lingua francas for various design projects.
In this section I describe a pattern language for architecture and urban design developed by Christopher 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.
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 [9] 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; however, 'patterns architects' do get a steady stream of clients who have sought them because they wish to use Alexandrian patterns. 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 [14]. The continuing popularity and use of Alexander's pattern language by layfolk is 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, which has 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 [17], and there are now annual conferences, mailing lists, web sites [16], and books [6, 11, 12, 19] devoted to the application of patterns to object oriented software design. For example, Gamma, et al. [12] have produced a book of design patterns for reusable components and object classes. At a different level of inquiry, Coplien [6] 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, with four more workshops occurring in 1999 and 2000 (see [8]).
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:
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 as representational systems in general, and as representational systems suitable for constructing lingua francas, in particular. Finally, it is 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.
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 references 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.
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.
Perhaps the most common misconception about pattern languages is that they are sets of templates that are rigidly applied to situations. This is not the case. Understanding how a pattern languages are intended to be applied is absolutely crucial to their effective use.
Alexander's pattern language is actually a meta-language. Both the language and individual patterns are malleable and are used to generate site-specific pattern languages for particular projects. Alexander carefully describes the process of generating a project-specific pattern language [2, pp xxxviii-xl], which I've summarized as follows:
88 Street Cafe
[picture omitted]
...neighborhoods are defined by Identifiable Neighborhood (14); their natural points of focus are given by Activity Nodes (30) and Small Public Squares (61). This pattern, and the ones which follow it, give the neighborhood and its points of focus, their identity.
The street cafe provides a unique setting, special to cities: a place where people can sit lazily, legitimately, be on view, and watch the world go by.
The most humane cities are always full of street cafes. Let us try to understand the experience which makes these places so attractive. We know that people enjoy mixing in public, in parks, squares, along promenades and avenues, in street cafes. The preconditions seem to be: the setting gives you the right to be there, by custom; there are a few things to do that are part of the scene, almost ritual: reading the newspaper, strolling, nursing a beer, playing catch; and people feel safe enough to relax, nod at each other, perhaps even meet. A good cafe terrace meets these conditions. But it has in addition, special qualities of its own: a person may sit there for...
[nine paragraphs of rationale omitted]
Therefore:
Encourage local cafes to spring up in each neighborhood. Make them intimate places, with several rooms, open to a busy path, where people can sit with coffee or a drink and watch the world go by. Build the front of the cafe so that a set of tables stretch out of the cafe, right into the street.
[diagram omitted]
Build a wide, substantial opening between the terrace and indoors-OPENING TO THE STREET (165); make the terrace double as A PLACE TO WAIT (150) for nearby bus stops and offices; both indoors and on the terrace use a great variety of different kinds of chairs and tables-DIFFERENT CHAIRS (251); and give the terrace some low definition at the street edge if it is in danger of being interrupted by street action-STAIR SEATS (125), SITTING WALL (243), perhaps a CANVAS ROOF (244).
[text omitted]...
Figure 3. An example of an Alexandrian pattern.
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. (Thus, for example, it is conceivable that Alexander's pattern language could have been used to help the residents of Manteo identify important places, i.e. those that instantiated Alexandrian patterns.)
Alexander's pattern language has a number of attributes that make it suitable for generating lingua francas.
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 project-specific lingua francas, and discussed the representational properties which make them suited to that end. 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. Here I discuss my explorations, and describe some fragments of pattern languages that might be used to design various sorts of interactive systems.
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 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: though she did not frame her advice in these terms, what she was basically doing was describing patterns for designing a successful wedding.
Here are two examples of her recommendations.
Clearly the wedding consultant understands the structure of the wedding experience and realizes that the wedding 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 could 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.
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.
The Final Fifteen Minutes-Bride
...the two main events of THE WEDDING DAY are THE MARRIAGE CEREMONY and THE RECEPTION. Many things must be taken care of in advance so that these events go smoothly: while most of these may be done ahead of time, this pattern, and the others in this section, must be done on the day itself.
The final fifteen minutes before the ceremony is a frenetic time. The bride and bridesmaids will be engaged in final adjustments of cosmetics and clothing.
In the final fifteen minutes, wedding participants are focused on the upcoming ceremony, not the farther future. There is the potential for handbags, cosmetics, unworn jewelry and other accessories to be left behind in the dressing area, where they may be left behind in the excitement of going off to the reception, or stolen from the dressing room during the wedding ceremony. etc. etc.
Therefore:
Designate a person to be responsible for collecting each participant's belongings, and storing them in a safe place.
Other patterns which may overlap or interact with this one are FINAL FIFTEEN MINUTES-GROOM, USHERS , and ASSEMBLY FOR PROCESSION
Figure 4. A pattern from a (hypothetical) wedding
pattern language.
As a consequence of reflecting on the wedding example, I decided to look for temporal 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:
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. This provided an opportunity to examine patterns involving multi-user interactions and workplace roles.
Closing the Loop
An individual's actions are dependent upon, and often shaped by, the activities of others. Thus, workers make an effort to STAY IN SYNCHRONY with their coworkers, and with outside events that may have an impact on their work. One manifestation of this is the explicit process of checking relevant communications channels after a period of being out of touch.
Workers often engage in the activity of checking their communications channels when they return to the office (or arrive at a place where they can communicate) after a period of being out of touch.
In the situations studied so far, closing the loop most commonly involved checking voice mail and email. It also sometimes involves checking physical mail, the fax machine, and visiting colleagues who are nearby, but not in the immediate work area.
When engaged in the pattern, people like to quickly scan through their messages to see which ones require urgent action. Some people act only on high priority items, leaving the rest in the queue for later. Others use the period as an opportunity to organize their messages in terms of a number of classes of priority.
Therefore:
Provide a place where incoming communications and news can accumulate. Make it possible for the worker to quickly scan new items, so that high priority information can be noticed and acted upon.
Other patterns which support this one are SCANNING, PRIORITIZING, REMINDING.
Figure 5. A pattern from an office pattern language
Elsewhere [7] 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 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.
The draft of this paper that was submitted to the DIS conference received four thoughtful and provocative reviews. After some reflection I decided it would be appropriate to respond explicitly to the most important issues raised, rather than blending my responses back into the paper. Thus, I have extracted the central questions and issues the reviewers have raised, synthesizing and rephrasing them where necessary, and follow them with my own responses. The rationale for this approach is that the purpose of this paper is to raise questions and encourage discussion, rather than to argue that a particular method or technique is the answer. Although I am firm in my admiration of Hester's work in Manteo, I am not certain that pattern languages are, in any sense, the answer (though I believe they deserve exploration), and the dialog format that I follow here seems better suited to expressing the reservations, questions and intuitions present in my own responses.
So, without more preamble, I'll begin.
Why do need a special lingua franca? That is, why is it not sufficient to use language and discussion?
To begin with I should make it clear that I am advocating multiple lingua francas (rather than "a" lingua franca). A frequent confusion is to think of Alexander's pattern language (or the fragmentary languages I have sketched in this paper) as "the" language. But Alexander's language (et al.) is just a proto- or meta-language: it is used to generate languages appropriate to the particularities of the project, site and community involved.
As to why not just use English, to me the answer has to do with the nature of disciplines and expertise. When designers get involved in a project, they bring with them a conceptual framework that has, often implicit in it, perspectives, values, methods and so forth. When the design team is itself interdisciplinary, conflicting conceptual frameworks can lead to discord and confusion. But even if the design team has a single conceptual framework that they apply, the users are at a great disadvantage: they are confronted with designers speaking a language that-though full of words everyone understands-refers to concepts, methods, values and assumptions that arise discipline or profession rather than from the users' daily lives. The example of Manteo illustrates the power of rooting design in concrete exemplars of the design domain, rather than abstract disciplinary based concepts.
I'm not convinced by the need for a lingua franca: it could be argued that the tension between different kinds of expertise, and the integrity of their respective languages, is more likely to produce rich design than a common (and potentially comprised) agreement.
This is a good point, particularly in the case of a multi-disciplinary team where the various members have the confidence and rhetorical skill (and the time) to resolve the tensions among the various disciplinary languages. However, I am more concerned about ensuring that the users can participate in the process of resolution, and I think that framing the discussion in terms of concrete objects in the domain being designed gives users more of a chance of being heard. It also seems to me that having a project specific lingua franca doesn't necessarily eliminate the tensions among different sorts of expertiseit just means that those tensions can, perhaps, be resolved on a more level playing field.
The work hasn't been applied to real interaction design situations and I am concerned that the utility of patterns in practice to do a design is not demonstrated; nor is the utility of a pattern language assessed.
This is certainly a valid objection. Even though [9] documents one application of patterns, and a fairly large HCI pattern language is available [18], it is quite clear that serious work is just beginning. In the absence of definitive evidence, I think the best way to proceed is to spread these ideas and let the community of HCI researchers and practitioners experiment as they see fit. Enough is now happening in the area that those inclined to explore will certainly have company (see [8] for on-going developments).
The process of building such a language in a real, ongoing design project might be difficulty and potentially unwieldy.
Yes, that concerns me too. Clearly, the Manteo example took a lot of effort and time, more, perhaps, than is typically available in a high tech design process. My hope is that pattern languages can provide a head start, or catalyst, for realizing what was achieved in Manteo, but that is a hope and not a fact.
Is this anything more than yet another design notation that no one will use?
I think the longevity of Alexander's language-the fact that it has an avid following among layfolk (as illustrated by the fact the A Pattern Language [1] remains a best selling architecture book after two decades) -suggests that, at the least, people will use it. A similar point could be made about the use of patterns in the software engineering community, though that use of patterns does not generally encompass layfolk [11, 12, 17, 19].
What characteristics of a pattern language are especially useful for design?
I see three characteristics that make pattern languages suitable for design. First there is the concrete nature of pattern languages. By expressing patterns in terms of concrete prototypes they become more accessible to the diverse audiences who will ideally participate in the design process. A second characteristic is the way in which they are intended to be generatively used (as described in section 4.2.2). The ability to use a pattern language to generate a project-specific language seems of great import. Third, these two characteristics interact. Because the patterns of any given pattern language are specific to the domain, and because they are accessible to anyone who understands that domain (most particularly, the users), the patterns can be bound to the particulars of the situation and used to ground the design discussion (as occurred in the case of Manteo).
A lingua franca should probably emerge from practice, rather than being imposed from the top down as this paper might imply.
I agree. Manteo is a perfect example of this. The hope for pattern languages is that they will provide a scaffolding for the emergence of a lingua franca. That is, by using a pattern language to generate a project-specific set of patterns that users can map to their own environment, perhaps the sort of experience that occurred in Manteo can be replicated more easily.
I've sketched out my notion of design as an inherently communicative process, and suggested that the creation of project-specific lingua francas have the potential to create a leveler playing field among the diverse parties involved in the design of interactive systems. 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 project-specific pattern languages-might catalyze the production of 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.
This paper draws very heavily on the work of Hester [10], 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. Finally, the comments of four reviewers were very helpful in producing the final version of this paper.
* To appear in the Proceedings of Designing Interactive Systems (DIS 2000, Brooklyn, NY, August 17-19, 2000). ACM Press, 2000.
.
[Tom's Home Page]
[Professional] [Life,
Fun, &c] [Tell Me...]
[Bookmarks] [Publications
List] <and many papers and essays>
© Copyright 2000 by Thomas Erickson. All Rights Reserved.