PERSPECTIVE-BASED CRITIQUING: HELPING

PERSPECTIVE-BASED CRITIQUING: HELPING DESIGNERS COPE WITH CONFLICTS AMONG DESIGN INTENTIONS Kumiyo Nakakoji* and Tamara Sumner Department of Computer Science and Institute of Cognitive Science University of Colorado at Boulder Boulder CO, USA 80309-0430, *Software Research Associates, Inc. Practical Software Engineering Laboratory 1-1-1 Hirakawa-cho, Chiyoda-ku Tokyo 102, Japan and Benedikte Harstad Computas Expert Systems A.S. Leif Transtads Plass 6 Postboks 430 1301 Sandvika, Norway

Abstract. Analyses of design activities indicate that conflicts detected at the solution level often originate in conflicts at the design intention level. We have extended previous computational critiquing approaches by helping designers to become aware of, understand, and resolve conflicts among design intentions. A perspective-based critiquing system allows designers to explicitly represent design intentions in terms of perspectives, and critiques design solution forms according to each specified perspective. By attending to the critic messages and associated design rationale, designers become aware of the conflicts among abstract perspectives. We describe two design environments that provide such perspective-based critiquing systems: the KID (Knowing-in-Design) design environment and VDDE (Voice Dialog Design Environment). These design environments use different approaches for representing perspectives and partitioning the knowledge-base. We compare the two approaches and enumerate design guidelines for creating perspective-based critiquing systems.

1. Introduction Design tasks require human creativity and judgment in indecisive circumstances. Design tasks are ill-defined (Simon 1973) or wicked (Rittel, Webber 1984) because the processes of identifying design intentions (problem specification) and constructing a concrete design representation (solution construction) are intertwined.

J.S. Gero and F. Sudweeks (eds.), Artificial Intelligence in Design '94, 449-466. 1994 Kluwer Academic Publishers. Printed in the Netherlands.

2

K. Nakakoji, T. Sumner and B. Harstad

In Fischer et al. (1993), we argue that expert system and design automation approaches are inadequate for solving ill-defined design tasks. Our approach to supporting design with computers focuses on augmenting human design activities with domain-oriented, knowledge-based design environments. Design environments are computer systems that contain design tools and information repositories that designers use for understanding, reflecting on, and constructing their designs. Our design environments are cooperative problem-solving systems (Fischer, Nakakoji 1992) in which computational critiquing systems help users evolve design intentions and solutions themselves. This view of computer support for design contrasts with expert systems approaches in which design solutions are based on predetermined and unambiguous requirement specifications. Designers may start with initial design intentions. Only some of these initial intentions can be explicitly represented as goals, objectives, or constraints; the rest remain tacit (Polanyi 1966). The process of design is one of mapping these design intentions into concrete design representations such as a graphical floor plan. These design intentions and the partially constructed solution talk back to designers (Schoen 1983) and they become aware of problematic situations in either the intentions or the partial solution. Traditional critiquing approaches (Fischer et al. 1991a, Silverman 1992) only support the evolution of the partial solution by focusing on evaluating a concrete design representation with respect to general design principles represented in a rule-base. Perspective-based critiquing systems extend traditional approaches by also supporting the evolution of design intentions; this evolution is supported by providing an explicit representation of these evolving intentions and computational critics that analyze design activities with respect to the stated intentions. Design intentions may evolve as designers become aware of (1) inadequate design intentions (intentions that do not match what designers hope to accomplish) and (2) conflicting intentions (intentions that force designers to make trade-off decisions). Design intentions can be represented in terms of perspectives. A perspective is a point-of-view which implies that certain design goals exist, certain bodies of design knowledge are relevant, and certain solution forms are preferred. Designers are often unaware of conflicting intentions because the associated perspectives may not be comparable at the same level of abstraction. Such conflicts are uncovered only when those perspectives are mapped to concrete features in the solution representation. Two critiquing systems that help designers to evolve their intentions have been prototyped. Our perspective-based critiquing systems support designers to become aware of conflicts, to understand underlying design principles that are relevant to the conflicts, to attend to relevant features of the design


ARTIFICIAL INTELLIGENCE IN DESIGN ’94

3

solution form, and to record their response to inform future designers. The KID (Knowing-in-Design) kitchen design environment (Nakakoji 1993) and VDDE (Voice Dialog Design Environment) (Repenning, Sumner 1992) illustrate two different approaches for implementing perspective-based critiquing systems. The two approaches, in turn, provide designers with different forms of support for design activities. In this paper, we first discuss computational critiquing mechanisms in general and present requirements for perspective-based critiquing systems. Both of the critiquing systems are then presented. We compare the two approaches and discuss the pros and cons of each. We conclude the paper by enumerating design guidelines for creating perspective-based critiquing systems. 2. Computational Critiquing Systems Supporting Design Critiquing in design tasks is a dialog in which the interjection of a reasoned opinion about a product or action triggers further reflection on or changes to the designed artifact. For example, a kitchen designer might critique a kitchen floor plan in terms of building code violations or design intentions such as efficiency, safety concerns, or resale value. Computer-based critics are made up of sets of rules or procedures for evaluating different aspects of a product (Fischer et al. 1991a). Using a perspective-based critiquing system, designers generate and modify design intentions and solutions. The system analyzes these solutions in terms of the specified intentions and notifies designers when problematic situations are detected in the solution form. Thus, critiquing systems augment the ability of designers to evaluate their design; decisions concerning whether to follow the critic suggestions are left up to the designers. 2.1. A NEW APPROACH FOR COMPUTATIONAL CRITICS The first generation of critiquing systems (Fischer et al. 1991a, Silverman 1992) supported designers in evolving design solutions with respect to general design principles. This was problematic because not all general design principles are equally important for all designs. For example, the principles that apply to the design of small kitchenettes do not apply when designing large, industrial kitchens. Critiquing systems must tailor their activities to reflect design intentions. A critiquing system requires an explicit representation of designers' intentions to be able to analyze the design with respect to design intentions. Although some of these intentions are tacit, vague, and cannot be entirely described with symbolic systems (Snodgrass, Coyne 1990), designers can


4


express partial intentions in terms of perspectives. Our definition of perspective is an explicit stance taken with respect to certain domain distinctions. Domain distinctions are vocabularies that commonly occur within the domain of consideration (Winograd, Flores 1986). This definition of perspective allows us to concretely partition the knowledge-base to reflect designers' intentions at various levels of abstraction. Design knowledge must be partitioned so that different parts of the system's knowledge-base can be selectively activated according to the specified perspectives. Each partition in the knowledge-base consists of a related set of critic rules. Different perspectives bring different knowledge (rule sets) to bear on the design, and the specified perspectives enable the system to determine which rules are relevant to the task at hand Using this partial understanding of the designers' intention, the system can detect (1) inconsistencies between specified intentions and a partial solution, and (2) conflicting intentions. Figure 1 illustrates the two situations. (1) Inconsistencies between intentions and a solution. Suppose a kitchen designer is working on a floor plan where the dishwasher is to the right of the sink. After meeting with clients, the designer learns that the primary cook is left-handed. If the designer specifies that the kitchen is for a left-handed person, then the system critiques that the dishwasher should be on the left side of the sink (because a lefthanded person can easily load dishes in the dishwasher with the left hand). (2) Conflicting intentions. In a subsequent meeting with the clients, the designer learns that they anticipate selling their house in a few years and are remodeling their kitchen primarily to increase the house's resale value. The designer now specifies that resale value is an important design consideration and the system critiques that the dishwasher should be on the right of the sink (because the average kitchen buyer is right-handed). Thus, the placement of the dishwasher in the design solution has identified a conflict at the perspective level. The designer must make a trade-off decision concerning whether to support the current kitchen owner's lefthandedness or future resale value. These examples illustrate that a perspective-based critiquing system needs: (1) to partition system knowledge-bases to reflect possible perspectives, (2) to allow designers to define and select multiple perspectives, and (3) to help them understand the trade-offs involved in making difficult design decisions by providing explanations about mappings between abstract perspectives and concrete design representations.



conforms conflicts

Design Intentions

Perspective 1 Left-handed cook

DW

5

Perspective 2 Resale value

DW

Domain Distinctions Design Solutions

Figure 1: Identifying Conflicting Intentions The real conflict is not between the two alternatives in terms of the location of the dishwasher and sink, but between the two perspectives, the left-handed perspective and the resale-value perspective.

2.2. A PERSPECTIVE-BASED CRITIQUING SYSTEM ARCHITECTURE The architecture for perspective-based critiquing systems consists of the following components (Figure 2): •Knowledge-Base: The knowledge-base consists of all the critic rules that are used during evaluation and the design rationale underlying each rule. The design rationale provides designers with explanations indicating how aspects of the current perspective are related to the rule. •Specification Component: The specification component allows the designer to specify parts of their design intentions by taking a stance on various domain distinctions. These stances can be prioritized and saved to create new perspectives. •Perspective Manager: In order to deliver knowledge that is finely tuned to the task at hand, the perspective manager functions as a filter for the knowledge-base. At the request of the critic manager, the perspective manager uses the explicitly represented perspectives to enable only relevant critic rules from the knowledge-base. •Critic Manager: The critic manager activates the critic rules relevant to the designers' stated intentions and their actions in the work area. Although the critic manager activates the rules, it does not contain knowledge about which rules to use in different situations; it must receive this information from the perspective manager. •Message Manager: When a critic rule detects a violation, the message manager creates and displays a message. The message manager provides a link for each displayed critic rule into its underlying design rationale.


6


•Work Area: The work area is where the graphical representation of the design solution form is created. Activates all relevant rules

Specification Component Intentions

Work Area

Reports inconsistency

Critic Manager

Perspective Manager

Message Manager

Rationale for rules

Determines relevant rules Critic messages

Rules

Knowledge Base

Figure 2: An Architecture for Perspective-Based Critiquing Systems

We have implemented two critiquing systems based on this architecture – the KID system and the VDDE system. KID is a design environment supporting kitchen floor plan design. The VDDE system is a design environment for creating phone-based user interfaces. These two systems have taken radically different approaches toward representing perspectives and partitioning the knowledge-base. Each system is now presented as a case study. For each case study, we present a brief description of the design domain and the design environment, and a scenario illustrating how the critiquing system supports designers. This is followed by a description of (1) how the system represents a perspective, (2) how the knowledge-base is partitioned, and (3) how the system increases the designers' awareness of conflicting design intentions. 3. Case Study 1: The KID System When designing a kitchen floor plan, professional kitchen designers extensively converse with their clients to better understand their design intentions. A common form of initial communication is a questionnaire, which contains a series of questions that ask for a wide variety of information from abstract goals to specific constraints, such as costs, cabinet needs, eating habits, cooking style, life style, and physical characteristics of the clients. These constraints may involve implicit conflicts. Part of the designer's role is to recognize these conflicts among design intentions, to ask their clients to refine their intentions, to make trade-offs, and to reflect these modified intentions in the design. The KID kitchen floor plan design environment (Nakakoji 1993) integrates a tool for representing design intentions (Figure 3) and a tool for



7

constructing a floor plan (Figure 4). The knowledge-base in KID contains critic rules, design rationale represented in the IBIS (Conklin, Begeman 1988) structure (an argumentation-base), and a catalog of completed floor plans together with their associated specifications (a catalog-base).

Figure 3: Specification Component in KID Designers can select answers presented in the Questions window. The summary of currently selected answers appears in the Current Specification window. Each answer is accompanied by a slider that allows designers to assign a weight representing the relative importance of the answer (1-10 scale where 10 indicates most importance). The Argumentation For window provides further explanation about how a presented critic message is related to the current specification.

3.1 SCENARIO Jack, a kitchen designer, begins designing by first specifying some partial design intentions by selecting answers to questions presented by KID. He browses questions and selects three answers (Figure 3). He assigns a weight indicating their relative importance. Since this client may have a roommate in the future, he assigns less importance to the single-person household requirement. Jack starts constructing a floor plan in the work area (see Figure 4). When he puts a dishwasher to the right of the sink, critiquing messages appear (see the Messages window). The critiquing message with the highest number (i.e.,


8


8.1) complains that the dishwasher should be to the left of the sink. Wondering why this is required, Jack selects the message. KID presents Jack with argumentation describing how left-handed cooks prefer the dishwasher to be on the left side of the sink (see the Argumentation-for window in Figure 3).

Figure 4: The Work Area of KID Designers can construct a kitchen floor plan in the Work Area by selecting components from a palette of domain abstractions in a direct manipulation style or by copying an example from the Catalog window. Critiquing messages (Messages window) are accompanied by numbers indicating their computed relative importance in terms of the current specification.

3.2 THE CRITIQUING MECHANISM KID represents a perspective as a set of issue-answer pairs. An implication rule mechanism uses these issue-answer pairs to dynamically construct critics that detect inconsistencies between the stated intentions and the solution form. Critics are prioritized using a weighted sum algorithm to reflect conflicts among design intentions. Each of these points is discussed in more detail below. 3.2.1 Representing a Perspective The specification component of KID (see Figure 3) has been built as a hypertext interface on top of the argumentation base, and the representation for a specification is a set of issue-answer pairs. This choice of representation is based on an analysis of questionnaires used by professional kitchen designers to elicit design requirements from clients (Nakakoji 1993). Each of the issue-answer pairs is linked to a corresponding domain distinction (Winograd and Flores 1986). These domain distinctions reflect commonly used vocabulary in the kitchen design domain. Using KID-Specification,



9

designers can specify their design priorities by selecting and annotating alternative design decisions documented in the argumentation-base. Designers can assign weights to the selected answers to articulate the relative importance of specified items. A perspective in KID corresponds to a particular specification (i.e., selected issue-answer pairs). KID allows designers to have multiple versions of design specifications. Designers can store sets of selected answers in the catalog-base. When designers create new perspectives, the system can critique the construction based on the currently selected version. In this manner, designers can compare multiple perspectives and play what-if games. 3.2.2 Partitioning the Knowledge-Base The argumentation-base is structured as a network of nodes consisting of issues, answers, and arguments. An issue-answer pair represents a design decision in terms of function, structure, or behavior at various levels of abstraction. A relationship between two issue-answer pairs is implied through the argument "a single-bowl-sink is enough for a single-person household." In KID, designers partition the argumentation-base by associating predefined domain distinctions with issue-answer pairs and arguments. KID captures the implied relationship between two issue-answer pairs by computing an interdependence between their associated domain distinctions. For the single-bowl-sink argument above, KID computes: Size-offamily=one-> Type-of-sink=Single-bowl-sink. This computed implication is referred to as a specification-linking rule. The perspective manager of KID uses the specification-linking rules to selectively enable only the critiquing rules that are relevant to the current specification. Every time designers modify the existing specification or select previously defined specifications, KID dynamically invokes specificationlinking rules to enable the system to provide information relevant to changing design perspectives. If designers disagree with existing arguments, they may modify or add other arguments to the argumentation-base. This will then lead to the derivation of new specification-linking rules and subsequently impact KID's critiquing behavior (see Nakakoji and Fischer (1995) for more details).


10


If there are many people in the house hold, the size of meal must be large. size-of-family=seven-or-more

If the size of meal is large, you need a dishwasher.

size-of-meal=large

0 .9

need-dishwasher=yes

9

1 0 entertainment-requirement=yes Legend: domain distinction argumentation

If you often entertain, you need a dishwasher.

implies

Figure 5: Specification-linking Rules Selectively Enable Critics A collection of specification-linking rules forms an interdependence network among design decisions. Each specification-linking rule is derived from an argument. If the designer assigns the weight 10 to the entertainment requirement, the system computes the importance of the need for a dishwasher as 9 using a weighted sum algorithm.

3.2.3 Increasing Conflict Awareness Often, the stated specification activates conflicting critic rules; e.g., "A dishwasher should be on the right side of a sink" versus "left side of a sink." Instead of resolving conflicts automatically, critiquing messages are presented with an associated computed value (see Figure 4). This value is derived using a weighted sum algorithm and reflects the importance assigned to each contributing issue-answer pair in the partial specification (see Figure 5). To derive the computed value, the system first identifies the collection of specification-linking rules related to the partial specification using a forward chaining inference engine. While collecting these rules, the system assigns a weight to the consequent of each rule reflecting the weights assigned to the selected answers in KID-Specification and the number of inference steps involved. This essentially prioritizes potentially conflicting consequents. If the same consequent appears more than once, the assigned importance values for all occurrences are summed (see Nakakoji (1993) for more details). 4. Case Study 2: The VDDE System The Voice Dialog Design Environment (Repenning, Sumner 1992) supports the design of phone-based user interfaces such as voice mail systems and voice information systems. These interfaces consist of a cascading series of voice prompted menus requesting the user to perform certain actions; e.g. “to listen to your messages, press 1.” The user issues commands by pressing



11

touch-tone buttons on the telephone keypad, and the system responds with appropriate voice phrases. One challenge facing voice dialog designers is that their design task is influenced by many conflicting design objectives such as compliance with different sets of user interface guidelines (regional, national, and international) and the desire to create designs that are consistent with related products or existing applications in the installed product base. Unfortunately, many applications in the installed base predate the interface guidelines and so do not conform to these guidelines. Thus, the designer must make difficult trade-off decisions between these competing objectives.

Figure 6: The Voice Dialog Design Environment Design units are arranged to create a flow chart-like representation. Each voice menu consists of vertically adjacent menu items where each is assigned a key and a function. These menu items correspond to touch-tone buttons on a common telephone. Assigning a menu item key 1 and associating it with function "listen" is interpreted as "to listen to your messages, press 1." Critic messages are displayed in a separate message pane. Every message is preceded by a symbol indicating the rule set that is relevant to the critic.

The VDDE system provides a gallery of voice dialog design units, such as menus and prompts, a worksheet for design construction and simulation (Figure 6), and a knowledge-base that contains sets of critic rules and design rationale (Harstad 1993). Three sets of critic rules correspond to the regional, national, and international phone-based user interface standards. A fourth set – the consistency set – represents rules for comparing two designs and detecting inconsistencies. Designers select which rule sets to use and prioritize


12


them when evaluating the design. The system provides explanation of critiquing messages by linking the messages with portions of the relevant user interface guidelines documented in the knowledge-base. 4.1 SCENARIO Jill is a voice dialog designer and her task is to design the residential version of a voice mail application. The user interface must first be consistent with the business version of the same application (i.e., "Voice Mail Business"), and secondly comply with the national user interface standards. Jill specifies her design goals by selecting the consistency and national rule sets and assigns a higher priority (1) to the consistency set (Figure 7).

Figure 7: Select Perspectives Designers can choose among four rule sets – regional (US WEST), national (VMUIF), and international user interface guidelines and a rule set that evaluates consistency with a related design. Additionally, designers can specify the application type to enable more specific critic rules.

Jill has just finished designing the Personal Options Menu and wants to add a ‘terminate’ option to the Listen Menu (see Figure 6). As soon as she switches her work attention by selecting the Listen Menu, the system performs a complete analysis of the Personal Options Menu by comparing it with its related menu in the design "Voice Mail Business" and evaluating it with respect to the national interface guidelines. The detected violations are displayed in the Message Pane shown in Figure 6. Because it is important to be consistent with the interface of the business application, Jill decides to associate the function "greeting" to key 1, and violates a national design rule. Jill wants to record her design rationale so she will not forget why this decision was made. Jill selects the "Add Argument"



13

button and enters her name. A small window is displayed with the default line saying "Rejected because:" and Jill explains her design decision (Figure 8).

Figure 8: Capturing Design Rationale in the Hypermedia Knowledge-base Jill records why she violates the design guideline. The windows on the left side are online versions of the various user interface guidelines documents.

4.2 THE CRITIQUING MECHANISM Designers specify their perspective by choosing from provided rule sets. The critic rule knowledge-base is hierarchically partitioned to reflect these rule sets and other domain distinctions. A symbol is associated with each critic message indicating the rule set that activated it. Each of these aspects is discussed further below. 4.2.1 Representing a Perspective In VDDE, designers specify their intentions by selecting from the following domain distinctions (Figure 7): (1) rule set: only rules within selected sets are enabled; (2) priority: the priority assigned to each set influences the order in which the rules are enabled and the order in which critic messages are displayed in the message pane; (3) type of voice dialog application: specific rules apply to the different types of applications, such as voice mail, call answering, voice message delivery, and voice bulletin board; and (4) individual rules within a rule set: all rules within a set are by default enabled, but the designer can enable and disable individual rules. 4.2.2 Partitioning the Knowledge-Base VDDE provides three types of knowledge: (1) rules critiquing compliance with design principles, (2) rules critiquing completeness, and (3) rules critiquing consistency with a related design. The type of knowledge activated


14


depends on the designer’s articulated intentions in the perspective component. The critic rule base is partitioned according to the three types of domain distinctions: user interface guideline type, application type, and completeness. The rules are grouped into four top-level sets: regional user interface guidelines, national guidelines, international guidelines, and the consistency set. Not all knowledge within the three sets representing user interface guidelines applies to all application types, and the sets are further partitioned into generic rules (those applying to all applications) and application-type specific rules that include design principles and completeness rules. Completeness rules check for missing functions in menus and missing menus. The consistency set contains only generic rules for how to compare two designs for consistency. 4.3.3 Increasing Conflict Awareness Due to the nature of the represented domain knowledge, conflicts between perspectives are frequent. VDDE supports designers in reflecting on their conflicting design goals by: (1) allowing the user to assign each selected rule set a priority and (2) explicitly denoting which rule set was violated. The format used when presenting the critic messages in the Message Pane helps designers to detect conflicting perspectives. When multiple rule sets are selected, the critic messages are displayed in their order of priority, and each critic message is preceded by a symbol denoting the rule set with which it is associated. Designers may record rationale for why design rules were violated (see Figure 8). 5. Comparison of the Two Approaches KID and VDDE illustrate two different approaches for implementing perspective-based critiquing systems (Table 1). In both systems, a perspective is an explicit stance with respect to certain domain distinctions. The knowledge-base is partitioned according to domain distinctions. Design intentions explicitly specified through the perspective interface are associated with domain distinctions that are used to selectively enable critic rules. While both are perspective-based, the particular representation of a perspective, definitions of domain distinctions, and the partitioning scheme of each system are quite different. The KID system emphasizes helping designers to evolve their design intentions by making the often complex and conflicting relationships between individual design decisions explicit. The VDDE system emphasizes making designers aware of the conflict inherent in major design goals intrinsic to the phone-based interface domain. These



15

resulting systems afford designers different types of support for the design activity. This will be discussed in detail below. Table 1. Comparison of the KID and VDDE Critiquing Systems Representation of perspectives Knowledge-base being partitioned Knowledge-base partitioning Reflecting priorities of conflicting perspectives

KID selection and weighting of issue-answer pairs argumentation base fine-grained domain distinctions messages numbered according to the weighted sum of selected answers in the specification

VDDE settings of: - prioritized rule sets - application types - activated individual rules critic rule base coarse-grained domain distinctions messages ordered based on assigned rule set priority

Representation of perspectives. The two systems use radically different perspective representations for capturing design intentions. For the most part, these system differences are motivated by differences in practices within the respective domains. In kitchen design, it is a fairly common practice to have a questionnaire-style specification sheet. In voice dialog design, there are no such specification forms, but instead several sets of important user interface design guidelines to choose from. The approach used by KID better lends itself to supporting designers to evolve their design intentions by giving them greater expressiveness (more domain distinctions to choose from) and more control over the applicability of these distinctions (the weighting scheme). Knowledge-base being partitioned. In the KID system, it is the argumentation-base that is being partitioned. A domain distinction is associated with every issue-answer pair. The specification-linking rules dynamically construct critic rules from the argumentation base to reflect the enabled partitions (see Figure 5). In VDDE, the critic rule sets are being partitioned. This partitioning is reflected in the system architecture in that each top level partition (i.e., critic rule set) has its own critic manager that controls the enabling and firing of rules within that partition. The KID approach makes it easier to incrementally add new critic rules by simply adding argumentation and associating domain distinctions with the argumentation. However, with the KID approach it would be difficult to modify all critics related to a particular domain distinction since these rules are distributed throughout the argumentation base. With the VDDE approach, it is easier to maintain related bodies of knowledge, such as rules corresponding to a set of standards, since these sets are aggregated in a single rule set manager. Further research needs to investigate more thoroughly the pros and cons of each approach. Knowledge-base partitioning. Both systems partition their knowledgebase according to certain domain distinctions, but with different levels of


16


granularity. The KID system has a very fine-grained partitioning whereas the VDDE system emphasizes a coarse-grained partitioning. Extremely finegrained schemes give the user control over the enabling of individual rules. The issue of coarse or fine-grained to some extent reflects the trade-off between complexity and control; i.e., giving the user full control over a very fine-grained partitioning scheme typically results in a very complex interface (Nakakoji 1993). Reflecting conflicts. The two systems also try radically different approaches toward supporting designers to become aware of conflicts among design intentions. The KID system uses an elaborate weighting scheme where the resulting computed value associated with every critic message reflects the conflict between several domain distinctions. When looking at critic messages, the computed values help the designer to understand which conflicts are more important than others; however, the system requires the designer to study the associated argumentation in order to know the source of the conflicts. The VDDE system uses a much simpler approach that presents all critic messages in a prioritized order, and each message is prefaced by a symbol denoting the perspective that enabled the critic rule. While the explicit symbol helps the designer to become aware of which perspectives are causing the conflict, he or she must first laboriously examine each message to determine if conflicts exist. The KID system synthesizes the sources of conflict for the designer but places the burden of identifying these sources on the designer. The VDDE system places the burden of synthesizing the conflict on the designer but identifies the source of conflict for the designer in the critic message pane. Neither approach by itself has been found sufficient (Harstad 1993 , Nakakoji 1993), and future work needs to investigate a "best of both worlds" approach in which the system both synthesizes and makes explicit the sources of conflict. 6. Conclusions In Fischer et al. (1993), we discussed how embedding critiquing systems into domain-oriented design environments increases the shared context; i.e., the system's level of understanding of the designer's task at hand. In this paper, we have presented perspective-based critiquing systems that extend this approach by increasing the system's understanding of design intentions. We have argued for the validity of this approach based on an analysis of design activities: we claim that conflicts detected at the surface level of design (solution form) actually arise from conflicts at the perspective level (design intentions). Systems that support design should help designers to become aware of conflicts existing in design intentions, to understand the conflict, and to arrive at some state of resolution. Taking this stance on the role of



17

conflict in design leads to new additional design guidelines to consider when constructing computer-based critiquing systems: • A set of domain distinctions must be identified. The knowledge base should be partitioned to reflect these domain distinctions. • The system must provide a perspective component that allows designers to define and select multiple perspectives so that they can specify their design intentions with respect to certain domain distinctions. These intentions will be reflected in the system by more finely tuned critiquing activity. • A synthesis mechanism such as the weighting scheme in the KID system must be constructed so that the system can detect conflicts and present the detected conflicts to the designer. • Critic argumentation facilities must be oriented toward helping designers identify the source of the conflict, i.e., perspectives favoring certain arguments, in addition to providing designers with information important to understanding the trade-offs involved in resolving the conflict. Perspective-based critiquing systems allow designers to express and evolve their design intentions by stating their stance with respect to various domain distinctions. Using this knowledge about design intentions, the critiquing system can tailor its analysis and argumentation activities to better support human judgment in design. Acknowledgments We would like to thank Gerhard Fischer, Jonathan Ostwald, Gerry Stahl and the HCC group at the University of Colorado who contributed to the conceptual framework and the systems discussed in this paper. This research was supported by Software Research Associates, Inc. (Tokyo, Japan) and U S WEST Advanced Technologies of Boulder, Colorado. References Conklin, J. and Begeman, M.: 1988, gIBIS: A Hypertext Tool for Exploratory Policy Discussion, Transactions of Office Information Systems, Vol. 6, No. 4, pp. 303-331. Fischer, G., Lemke, A.C., Mastaglio, T. and Morch, A.: 1991a, The Role of Critiquing in Cooperative Problem Solving, ACM Transactions on Information Systems, Vol. 9, No. 2, pp. 123-151. Fischer, G., Lemke, A.C., McCall, R. and Morch, A.: 1991b, Making Argumentation Serve Design, Human Computer Interaction, Vol. 6, No. 3-4, pp. 393-419. Fischer, G. and Nakakoji, K.: 1992, Beyond the Macho Approach of Artificial Intelligence: Empower Human Designers - Do Not Replace Them, Knowledge-Based Systems Journal, Vol. 5, No. 1, pp. 15-30.


18


Fischer, G., Nakakoji, K., Ostwald, J., Stahl, G. and Sumner, T.: 1993, Embedding Critics in Design Environments, The Knowledge Engineering Review Journal, Vol. 8 No. 4, pp. 285-307. Harstad, B.: 1993, New Approaches for Critiquing: Pluralistic Critiquing, Consistency Critiquing, and Multiple Intervention Strategies, Masters Thesis, University of Colorado at Boulder. Nakakoji, K.: 1993, Increasing Shared Understanding of a Design Task between Designers and Design Environments: The Role of a Specification Component, Ph.D. Dissertation, University of Colorado at Boulder. Nakakoji, K. and Fischer, G.: 1995, Intertwining Knowledge Delivery, Construction, and Elicitation: A Process Model for Human-Computer Collaboration in Design, Knowledge-Based Systems Journal, Special Issue on Human-Computer Collaboration, (forthcoming). Polanyi, M.: 1966, The Tacit Dimension, Doubleday, Garden City, NY. Repenning, A. and Sumner, T.: 1992, Using Agentsheets to Create a Voice Dialog Design Environment, Proceedings of the 1992 ACM/SIGAPP Symposium on Applied Computing, pp. 1199-1207. Rittel, H. and Webber, M.M.: 1984, Planning Problems are Wicked Problems, in N. Cross (ed.), Developments in Design Methodology, John Wiley & Sons, New York. Schoen, D.A.: 1983, The Reflective Practitioner: How Professionals Think in Action, Basic Books, New York. Silverman, B.: 1992 Survey of Expert Critiquing Systems: Practical and Theoretical Frontiers, CACM, Vol. 35, No. 4 (April 92), pp. 106-127. Simon, H.A.: 1973, The Structure of Ill-Structured Problems, Artificial Intelligence, Chap. 4, pp. 181-200. Snodgrass, A.S. and Coyne, R.: 1990, Is Designing Hermeneutical?, Technical Report, Department of Architectural and Design Science, University of Australia. Winograd, T. and Flores, F.: 1986, Understanding Computers and Cognition: A New Foundation for Design, Ablex Publishing Corporation, Norwood, NJ.
