3.3.    Capturing the Language of Privacy

The analysis of the lunar habitat design process in this chapter confirms the importance of the ideas emphasized by Alexander, Rittel and Schön in Chapter 2 and the view of design as interpretation proposed in Chapter 1. This section will discuss some implications of the nature of lunar habitat design for computer support.

Problems of collecting knowledge have plagued attempts to provide computer support for design. Often it has been assumed that this is merely a practical problem, with no interesting theoretical aspects compared to the development of AI techniques for representing, accessing, manipulating, and displaying relevant knowledge. The expert system approach, for instance, assumed that a human domain expert, when interviewed, could spell out the important knowledge of the domain in a series of formalizable rules. However, experience showed that professionals had surprisingly partial knowledge of their fields and relied heavily upon heuristics and access to other resources to work around or fill in gaps (Suchman, 1987; Winograd & Flores, 1986). Even what people did have working knowledge of they could not readily state explicitly or fully. Professional expertise relies heavily upon tacit background knowledge of the field that one picks up through apprenticeship-style training, not from the accumulation of rule-like information. This is emphasized by Kuhn (1962), Schön (1983), and Dreyfus (1985) in discussing how people develop expertise.

It may well be that the AI computational tricks are the easy part, for which much work has already been done and options are fairly well understood. The following questions may be more difficult. They have to do with the fact that knowledge is founded on interpretation and is not given independently of the knower’s situations, perspectives, or language traditions:

1.   What are the human cognitive processes involved in design?

2.   What is the nature of the knowledge at work in these processes?

3.   How can that knowledge be captured during the action present when it is available?

4.   How can the often tacit knowledge be represented in ways which are explicit enough for computer processing?

5.   How can stored information be supplied to people to support their current design efforts in a timely manner and a useful format?

These are the kinds of questions being pursued in this dissertation. The following paragraphs start to suggest responses based on observed characteristics of lunar habitat design. They will be returned to repeatedly, particularly in the discussion of the theory of computer support for interpretation in design (Chapter 7).

1. What are the human cognitive processes involved in design? Alexander argued that an important process in design was the decomposition of a problem into functional components, each component having more interactions among the items within it than with items outside the component. Rittel conceived of design as a deliberative process, in which people raised issues, made proposals from different perspectives, and critically debated each other's positions. Schön stressed the importance of active, creative involvement with the design artifact (e.g., sketching) in order to discover constraints and consequences of design moves. These different processes were apparent in the videotaped lunar habitat design sessions. The habitat was decomposed into private, group, and public areas based on functionalities of the items in the layout. Various perspectives on privacy were discussed and debated in verbal exchanges. Successive sketches were made, which formed the basis for discoveries and design decisions. Diverse cognitive processes were at work: analysis (decomposing into functional areas), recall (analogous situations: German bathrooms, Space Station crew compartments, submarines, Antarctic), simulation (imagining life in the habitat), argumentation (discussing the issues), gesture (pointing to drawn objects, indicating other arrangements, sketching), perception (seeing sketched lines as representations of a habitat).

2. What is the nature of the knowledge at work in these processes? Much of the knowledge involved in these cognitive processes of designing is tacit—far more than ever imagined in the heyday of expert systems. The notion of privacy is a good example. A designer’s understanding of what situations are private and which situations require privacy is based on tacit understandings of what it feels like to be a human being in those situations. This understanding is used extensively by Desi and Archie in decomposing the functional areas, in deliberating adjacencies of items, and in seeing problems in layout sketches. What is interesting is that much of this tacit knowledge becomes explicit during the designing. It gets articulated in English statements in order to be introduced into the interpersonal argumentative process. For this period during which it is debated, which Schön calls the “action present”, the knowledge is explicitly available. After the deliberation is resolved, the arguments and their basis in knowledge may sink back into a tacit understanding once more. So the optimal time to capture design knowledge is when it becomes explicit in the designers’ language, while they are situated in the designing and have adopted the particular perspective.

3. How can that knowledge be captured during the action present when it is available? Information may be stored in a computer system in many ways. Some ways—such as textual formats in natural language—are more useful to human users, while others—like encodings in semantic networks or other formalisms—facilitate computer computation and manipulation of the information. However, all these forms are explicit forms of knowledge. Tacit knowledge, by definition, is not expressed in any way that could be stored on paper or in computer memories. It must first be made explicit. Because much important design knowledge is tacit, because it needs to be made explicit in order to be used in a computer-based system, and because tacit knowledge often becomes explicit during the action present of reflection during design, it can be helpful to capture the explicit articulation when it is available.

In general, lunar habitat design is more complex in its use of technical information than the episode transcribed in the preceding sections. Its high-tech nature means that technical data must often be looked up in manuals or even explored experimentally in subsidiary engineering studies. Contractual obligations to NASA and its subcontractors require documented adherence to voluminous specifications and requirements (including the volumes of the MSIS). The design of something like a lunar habitat passes through many phases, carried out by different teams. The capture and use of design rationale plays a variety of roles in this process, and should probably play even stronger roles in the future. Computer support systems could facilitate an increased role for stored design rationale if mechanisms are developed to capture knowledge as it becomes explicit in the design process.

The scenario in Chapter 9 shows how lunar habitat designers could use a software design environment as their design medium, rather than paper and pencil, even for design tasks like those presented in the transcript. If the computer becomes a medium for designing, then the knowledge that arises in the design process is largely already represented in the computer. Such knowledge can be stored for future use. Then the computer system functions as an external, shared memory. Knowledge captured there is available for the original designer to come back to later and for other designers to access as well. It becomes a medium of communication and collaboration, through which designers can share their ideas, approaches, rules, sketches, and interpretations. The computer can represent explicitly the relations that are normally tacit in situated interpretation, organize knowledge into different perspectives, and operationalize terminology of an interpretive language.

4. How can the often tacit knowledge be represented in ways which are explicit enough for computer processing? Lunar habitat design differs from design in simpler domains in a number of ways. For one thing, it is not a well-understood, mature field. One could not expect to interview an expert and come up with a set of formal rules and elements to define a comprehensive system of knowledge here. Workers in this field are attempting to explore a new domain and to begin to map out the potential problem space. A goal of researchers is to sketch in parametric curves that would indicate how designs have to change depending on such parameters as number of astronauts, length of mission duration, or payload delivery capacity (see, e.g., Design Edge, 1990; Moore, et al., 1991; Kazmierski, et al. 1992). This is a very preliminary step toward developing knowledge representations for this domain. Even the most important parameters remain undefined and open to interpretation and debate. For instance, few NASA guidelines cover privacy issues, even though this is an important concern of thoughtful designers and a topic for vigorous political debate and even power struggles within NASA (Compton, et al., 1983).

The MSIS was not able to define privacy well, except for some concern about visual and audio privacy as expressed in the graph of recommended adjacencies for different functions (reproduced as Figure 3-5 in the previous section). It does, however, indirectly recognize its importance when considering habitable volume requirements: “Sufficient habitable volume shall be provided and configured to decrease the possibility of degradation of crew performance due to detrimental psychological effects from feelings of confinement” (NASA, 1989a, p.8-17). Just as Archie noted that the need for private space becomes critical as the length of confinement exceeds a month, the MSIS states, “As the mission duration increases, there is a greater tendency for the crew to feel confined and cramped. This can affect psychological health and crewmember performance” (ibid., p.8-12). A graph of guidelines for determination of total habitable volume per person as a function of mission duration accompanies this statement (reproduced here as Figure 3-6).

Figure 3-6. Required volume per crewmember as a function of mission duration.

It is an excellent example of a set of parametric curves to begin to define the problem space. NASA was able to represent knowledge about privacy here by reducing it to a matter of spatial volume. New methods are needed to allow designers to define less reductionist concepts of privacy and to capture knowledge related to such concepts.

In the lunar habitat design sessions, privacy issues due to prolonged confinement were the first real concerns to surface. They structured how the designers constructed their task. Related questions of social interaction dominated questions of physical layout, indicating that social planning was necessarily a significant aspect of the designing. When the geopolitics (or solar system politics) of NASA's goals are reflected in the deliberations, the result is truly a wicked problem in Rittel's full sense. It is not just that more study is needed to formulate objective rules for the field, but that decisions necessarily involve tacit understanding of inter-personal behavior and non-propositional recognition of political interests.

For relatively unexplored domains such as lunar habitat design, efforts at designing do not seek optimal solutions within a known problem space, but begin to mark out a solution space in the first place—as Schön says, to construct the reality of the design situation. The most important role of computer support for such domains is to capture the ideas that are being generated. Terms (like privacy) and patterns (like Figure 3-6) which are formulated on the spot during this design exploration process are expressions of what designers may want to pay attention to in the future as well. So, for instance, the important criterion for rules is not the rigor of their computations in the sense of some rationalist engineering ideal but their ability to convey the designer's interpretive intent. A computer system incorporating the knowledge should not be conceived primarily as an autonomous equation solver (or an expert system), but as a powerful medium of external memory to empower people's creativity. A software environment for this domain should be designed to capture new and evolving knowledge, rather than simply manipulate predefined knowledge representations and systems of production rules. This has been a primary concern in designing the Hermes software described in Part III.

5. How can stored information be supplied to people to support their current design efforts in a timely manner and a useful format? A high-tech design goes through many stages of development, involving different design teams. Architects, designers, a variety of engineers, and administrators all work on the designs from their own viewpoints. Successful designs are sent to other contractors around the country for detailing, mock-up, testing, and construction. At each stage, the design is modified, based on people's understanding of the design and its rationale. If a creative design concept is to survive this argumentative process—with tight cost, weight, and volume constraints at every stage—strong design rationale must be communicated; a schematic diagram or a pretty picture will not suffice. In fact, a typical product of lunar habitat design consists of a small booklet predominated by textual explanations of rationale, not just detailed drawings. The important role that rationale plays in this extended design process should motivate designers to document their reasoning and interpretation more than they would in a domain like kitchen design. A logical step beyond a written booklet would be a computer system that integrates designs and rationale in useful, easily accessible ways.

Because designers lack personal experience living in lunar habitats, knowledge embodied in related designs (including Skylab, the Shuttle, Space Station Freedom, previous trips to the moon) is invaluable. Old designs are reused extensively. To the degree that design rationale of the old designs has been captured and augmented by subsequent experience, it can be vitally useful. Consequently, it is likely that design rationale will increasingly become an integral part of design. This should add tremendous power for practitioners who take it seriously and those who use computer tools that support rationale capture. Such a development represents a significant break with the tradition of CAD programs, which are purely graphical and embody very little semantics. However, it has impressive precedence in other fields like science, mathematics, and philosophy, where written theories, proofs, and arguments have been refined through processes of public critique and have grown into extensive bases of shared knowledge and accumulated commentary impossible in non-literate cultures.

The need for computer support of lunar habitat design was originally suggested by the sheer volume (and complexity) of knowledge required—far more than people could maintain in their heads or even locate easily in manuals. There are thick sets of NASA regulations for all Man-In-Space designs, ergonomic standards, and specific project contractual obligations that must be adhered to by designs. But the complexity of lunar habitat design is not just a matter of the volume of information. Requirements, components and rationale all have to be reinterpreted within the context of the evolving design. This is an application realm in which, for instance, most physical components require some degree of customization. Because of gravitational or volumetric considerations, one cannot simply select a stock sink or bed from a catalog. Even pumps and fans must be re-thought. Furthermore, there are many design interactions among components that are placed close together—partially because space is at a premium and also because things must work together to form a coherent environment for habitation. This means that design of a given part is very much situated in its context, in terms of neighboring components (e.g., sound buffers), design concerns (privacy), and projected usage issues (traffic flow). The computer representation of the design must function as the unique world in which representations of all the components and their relationships are appropriately situated so that design can take place effectively. One wants to start from existing components, but one then needs to be able to modify them freely to account for differences in the lunar setting. So representing standard parts with schematic icons or fixed items from a palette is inadequate. The idea that there is a definable domain with its primitive elements is too narrow a conception. All knowledge representations must be stored in plastic media, so they can be tailored to different interpretations.

Elements of lunar habitats should be similar to familiar products to facilitate manufacture and to give astronauts a sense of being at home, but they must also be different to meet the severe constraints of their context. This means that models and rules of thumb must be searched for in many other domains (houses, submarines, Antarctic labs) and then applied to the lunar setting. Such application must be done by the creative and synthetic minds of humans, with computer systems merely presenting the relevant elements. Even the determination of what might be relevant must involve the human designer, for this is also very much a matter of interpretation based on a deep understanding of the semantics involved. This means that computer-based systems for design should be people-centered, so that all interpretive judgments are under human control.

Desi and Archie communicate in English. They articulate and share their interpretations of what is going on in the design through the medium of language. To support the subtlety of communication between designers and a computer system, the designers should be able to develop a language that operationalizes their evolving interpretations in ways which can be used by the software. At the same time, the development of a language for interpretation can provide a basis for shared understanding among groups of designers, even if they are not working together at the same time or place. For instance, a designer who is considering an old design for adaptation into a new project can learn about the old design through the language which was developed with it—including the formulations of definitions and argumentation specific to that design. Providing some support for collaborative work among groups is particularly important in this domain because of the way each successful design must undergo the scrutiny of many teams. Generally, the only communication between these teams is the design document itself. To further mutual understanding, it is desirable that the design include effective documentation of the interpretive stance behind the rationale.

The computational platform within which design work is carried out can serve as a communication medium in which designs and related information can be viewed and interpreted by different people working together or working sequentially. Lunar habitat design is not a task for one person sitting at a computer. It is a collaborative process. It proceeds through the work of teams of teams, each viewing the common product through their own perspective. The essential communication is not that between a human and a computer, but among the design teams. What a computer system like Hermes can do is to provide an electronic medium to support this communication. It can do that by facilitating the development of a shared language of design interpretation and by providing a mechanism for the creation and sharing of interpreted designs defined using that language.

The example of lunar habitat design has illustrated the importance of interpretation in design. Desi and Archie interpret their task as one of creating a balance of public and private space. They spend much of their time developing an adequate interpretation of what privacy means in the context they are dealing with. A variety of interpretive perspectives are brought to bear and are deliberated. Finally, a shared interpretation of privacy guides the designing and provides a sense of resolution when the privacy constraints seem to be satisfied.

The interpretive processes draw heavily on tacit knowledge. During computations for decomposition, deliberation of relevant issues, or reflection-in-action, some of that knowledge becomes more explicit. The representations of the situation, perspectives on design, and guiding concepts that become manifest may be represented in calculations, arguments, or ideas—i.e., in formal or natural language. Unless these explicit forms of knowledge are made permanent in some external medium like annotations on paper or statements of rationale in a computer system, they may revert to tacit forms. Particularly in high-tech fields, it is important to capture design rationale knowledge to help people understand and reuse designs.

The following chapter explores the philosophy of interpretation in order to clarify some of the issues related to tacit knowledge, interpretive perspectives, and the explication of understanding raised by the study of lunar habitat design. The problem of computer support for interpretation in design is then addressed in Part II.

The discussion of lunar habitat design has highlighted a number of challenges for a theory of computer support:

(a) The concept of privacy is typical of a broad range of themes that are essential to habitat design but are hard to operationalize. Despite the fact that NASA epitomizes the effort to codify design issues as objective rules, after twenty years their success with the concept of privacy is definitely inadequate. It remains unclear how to represent situations in which privacy plays a key role. This poses a challenge for the design of computational support for interpretation in design. It will provide the key example for the utility of Hermes’ mechanisms in Part III.

(b) Part of the problem with privacy is that different people have different ideas of what aspects are important in defining the concept. These differences may be due to concerns with varying technical specialties or simply to personal preferences. In any case, definitions of such concepts cannot be formulated as statements of necessary and sufficient conditions, but must be allowed to emerge in each situation through deliberation from multiple perspectives.

(c) Another part of the problem involves adapting the concept to the particular design situation. Fixed definitions from a body of domain knowledge can provide useful (even necessary) starting points for articulation of tacit understandings, but they must be capable of flexible modification to be applied appropriately in a concrete situation. This typically involves an iterative process of situated discovery and perspectival deliberation, as seen in the transcripts. Even where NASA has captured important information relevant to privacy (as in Figures 3-5 and 3-6), or Alexander has abstracted useful schemata in his pattern language, these representations must be applied to individual situations through human processes of interpretation. The language user must be capable of generating terminology and expressions whose meaning can be interpreted appropriately to unique situations.

Go to top of this page

Return to Gerry Stahl's Home Page

Send email to Gerry.Stahl@drexel.edu

This page last modified on January 05, 2004