From: AAAI Technical Report WS-93-07. Compilation copyright © 1993, AAAI (www.aaai.org). All rights reserved.
Facilitating collaborative design through
representations of context and intent
G. Fischer 1, K. Nakakoji ~ and 1J. Otswald
1Departmentof ComputerScience and Institute of Cognitive Studies
University of Colorado
Boulder Colorado 80309-0430
USA
2SoftwareEngineering Laboratory
SoftwareResearchAssociates, Inc.
1-1-1 Hirakawa-cho, Chiyoda-ku
Tokyo 102
Japan
Abstract
Domain-orienteddesign environmentsrequire support for three types of collaboration: (1)
collaboration between domain-oriented designers (the users of design environments) and
design environmentbuilders, (2) collaboration betweendomain-orienteddesigners and clients
(users of designed individual artifacts using a design environments), and (3) long-term
direct collaboration amongdesigners. Design environments provide representations that
serve as a shared context for collaboration and groundlanguagesof design.
In this paper, we describe two componentsof our research workexploring domain-oriented
design environments.First, the Knowing-in-Design
(KID) environmentuses explicit representations of the designers’ task at hand(representing a partial articulation of their intent)
facilitate mutual education betweenclients and designers, and to deliver design knowledge
relevant to the task at hand. Second, the Evolving-Artifact-Approach (EVA)which uses
descriptive representations, functional representations, and seed prototypes to facilitate the
mutual education process betweendesigners and design environmentbuilders necessary for
achieying a deep knowledgeof the application domain,for capturing design rationale, and for
representing domainknowledge.
Domain-orienteddesign environmentsare evolving artifacts supporting long-term indirect
collaboration betweendesigners: Each design produced in design environmentscontributes
to the accumulated design knowledge. By delivering relevant information from the
knowledgebase, design environmentscreate a virtual collaboration with past designers.
Keywords:domainoriented design environments, long-term indirect collaboration, coopera-
293
tive problem-solvingsystems, shared context, mutual education, languages of doing, situational interpretation, focus of attention, EVA,evolvingartifact, KID,communication
of intent,
human-centeredintelligent agents, computer-supportedcooperative work, information overload, informationaccess and delivery, informationfiltering, learning, institutional memory,
design rationale.
1 Introduction
Weview design as intrinsically collaborative and ongoing. Complexityin design arises from
the need to synthesize different perspectives on a problem, the management
of large amounts
of informationpotentially relevant to a design task, and understandingthe design decisions
that have determinedthe long-termevolution of a designedartifact. Ourapproachto supporting design with computersfocuses on human-centereddesign support with domain-oriented
design environments. Rather than modelingthe cognitive processes of designers, we augment
the abilities of designers to understand, manageand communicate
complexity.
In this paper we first describe two modesof collaborative design and discuss howdesign
environmentssupport two of collaboration at two levels of design: the design of individual
artifacts and the design of design environments.The KIDdesign environmentis described to
illustrate support for collaboration in the design of individual artifacts, and the EVA
approach
to design environmentbuilding is describe to illustrate collaboration in the context of system
building.
2 TwoModesof Collaboration
Design environments support two modesof collaborative design: (1) Short-term, Directed
Collaboration; and (2) Long-term,Indirect collaboration. Thesemodesare actually two points
along a continuumof possible collaboration paradigms,but for the purposesof clarity wewill
discuss themas if they weredistinct.
Short-term,Directed Collaboration. Design requirements originate not from designers but
from clients, whodo not have the knowledgenecessary to implementa solution. Initially,
there is a symmetry
of ignorancebetweendesign designers and clients, in which1) the understanding required to solve the design problemis distributed, and 2) there is no common
language that allows the stakeholders to communicate
their understandingto each other. Mutual
education processes enable the construction of a shared "language of doing" that allows
clients and designers to collaboratively build the knowledgerequired to solve the design
problem.
In short-term, directed collaboration, designers and clients worktogether to define the
problemto be solved as well as to producea solution. Ourprimaryemphasisis on conceptual
coordinationrather than on physical coordination. Weare interested in creating a shared understanding amongstakeholders that allows both clients and designers to contribute their
respective knowledgeto the design task. Complexproblemscan be only vaguely understood
before the design process begins. Attemptsat producinga solution reveal additional design
requirements that could not be foreseen. For complexdesign problems, design requirements
and solutions must coevolve.
Long-term,Indirect CollaborationamongDesigners. Long-term, indirect collaboration is
required in the design of complexand evolving artifacts, such as local area networkdesign
294
Modes
of collaboration
Short-term,
Direct
Individual
Artifact
Long-term,
Indirect
Design
Redesign
Seeding
Reseeding
Levelsof Design
Design
Environment
Ume
Figure 1: Four Collaborative Design Processes
Theleft twocells of the matrixdescri.be face-to-face direct collaboration. In seeding, domain
experts and system builders worktogemerto design the design environmenL
The box labeled
designrepresents a collaborationbetweendomainexperts andclients. Theright two cells of the
matrixrepresentindirect collaboration,wheredesignknowledge
stored in the artifact facilitates
virtual collaborationwithpast designers.
and software design, which are maintained and modified over a span of years. In ongoing
design, the emphasis must be on sharing knowledge among designers rather than on
knowledge acquisition by individuals.
Designers who maintain and modify complex and
evolving artifacts collaborate indirectly with the original designers.
The term, "indirect collaboration" implies that communication occurs through a shared
knowledge space rather than directly between designers. A shared knowledge space that supports indirect collaboration provides a background, or tradition, against which the design of
individual artifacts takes place. Knowledgespaces that support indirect collaboration must be
dynamic because design traditions are constantly evolving as new knowledge is discovered
and old knowledge becomes obsolete.
Design documentation, reference materials, precedent solutions, and design guidelines are information sources that enable indirect, long-term collaboration with past designers. However,
the existence of large amounts of design information does not guarantee effective collaboration. In information-intensive domains, the challenge is not merely to accumulate information, but rather it is to find information relevant to unanticipated problemsthat arise during
the design task.
3 TwoLevels of Design in Design Environments
There are two interrelated and ongoing design processes addressed in our design environment
work: (1) the design of individual artifacts within design environments; and (2) the design
design environments themselves. Our claim is that both design processes are collaborative,
are anchored by representations, and employlanguages of doing.
295
Figure 2 illustrates the levels of collaborative design involved in building and using design
environments. Three types of people are involved: (1) design environment builders; (2)
designers, whouse the design environment; and (3) clients, whouse individual design artifacts.
Althoughit is vital to facilitate the communication
amongpeople in the two adjacent levels
(see Figure Figure 2), the goal is to reduce the amountof communicationrequired between
people in non-adjacentlevels. Peoplein each level use different languagesfor achievingtheir
design. Communication
distance represented by the numberof levels involved represents the
numberof languagesthat the participants have to deal with. Themorelanguages, the larger
the risk that mis-communication
maytake place. Wehave to reduce the problemof miscommunicationby reducing the communicationdistance.
Design Envimnmcnt
Use
Collaborativedesign
of DomainArtifacts
Collaborative Design
Processes
Seeding
Collaborativedesign
of DomainEnvironments
Artifacts
Design Support
(e.g., design environments
support
deaignof individualartifacts)
Domain-lndependent
Component
s andTools
Figure 2: Face to Face Collaborative Interactions
Thetwoovalsillustrate the twolevels of direct collaborationinvolvedin buildingandusing
domain-oriented
designenvironments.
EVA
supportsdesignenvironment
builders to producea
designenvironment
~1 usingdomain-independ-ent
tools/rodcompon.ents
in collabo.rationwire
dom~ain
workers{d,esigners)
whowill ,use the designenvironment..,gin
su:p.lX~.d.qsigners,to
proguceinoiviouam
aes~gnartifacts in coimooration
wtmcfients, wnowmusememoivtoum
oestgn
/mitacts.
Figure 3 describes a process model for collaborative design in developing and using a
domain-orienteddesign environment.Themodelillustrates the two interrelated indirect collaborative design processes that design environments support: 1) seeding and continual
design-in-use (Greenbaum,Kyng,1991) of design environments, and 2) design and ongoing
evolution of individual design artifacts within the design environment.
296
297
3.1 Direct Collaboration Mediated by Design Environments
Seeding. Seed building creates the initial conditions for design environmentuse. Because
design environmentsare open systemsthat evolve with use, werefer to the initial systemas a
seed. Thestakeholders are designers (future users of a design environment)and environment
builders. Thedesignedartifact is a domain-orienteddesign environment.
Design.Designis the creation of artifacts. Thestakeholders are the designers (the users of
the domain-oriented design environment) and the client. The designed artifact is an individual designthat is usedby the clients.
Both seeding and design processes involve face-to-face collaboration amongdifferent
stakeholders. Environmentbuilders design domain-oriented design environmentsin accordance with requirementsarticulated by designers. Thedesigners in turn design individual artifacts based on clients’ requirementspecifications. In each collaborative design process, the
requirementspecification and the solution construction must be integrated (Fischer, Nakakoji,
1992). Therefore, the stakeholders mustworktogether to producequality artifacts.
Sinceeach stakeholderuses a different representation to express their ideas, goals and intentions, communicationbreakdownsoften take place. For examplein kitchen design, client
often do not understanda blue-print that a designer provides as a partial design. Explicit
representations support the construction of a shared language of doing by providing a commonreference for communication.
3.2 Long-term, Indirect Collaboration Through Design Environments
A different type of collaboration is required during the reseeding and the redesign processes.
Designers (and design environmentbuilders) have to understand whydesign decisions have
beenmadein order to reuse or modifyit.
Redesign.Artifacts are not designedfrom scratch but are iteratively refined and components
are reused. A complexdesign artifact can never be complete but is constantly evolving in
nature. As illustrated in Figure 3, designers gradually accumulatedesign knowledgethrough
design practice. Thus, the knowledge-baseof the design environment gradually evolves.
Ironically, the moreinformationthe knowledgebase has, the moredifficult it is for designers
to access the useful information without an adequate support because the information space
becomeslarge and complex.
In order to cope with this information overload problem, design environments provide
knowledgedelivery mechanisms.By sharing the problem context with designers, design environmentsmakethe informationspace relevant to the task at hand, thereby supporting designers to access design knowledgestored by other designers. Consequently,it enables designers to collaborate with other designers via stored design knowledge.
Reseeding.As designers use the design environmentseed to create design artifacts, they may
encounter gaps in the knowledgebase or discover newknowledgethat should be recorded. In
both cases, designers can add to the knowledgein the seed. As design knowledgeis accumulated over time, the knowledgebase will occasionally require reseeding. Reseedingis process
in which design environmentbuilders reorganize the knowledge-basein order to eliminate
inconsistent or obsolete knowledgeand to consolidate redundant knowledge.Little research
has been done in howto support this reseeding process, but we need to keep in mindthat
298
reseeding should not be consideredas a result of flaws in the design of a design environment,
but rather be a necessaryprocess for evolution of design environments.
4 Explicit SharedContext and Communication
of Intent
Communication
betweenclients and designers is difficult because designers and clients use
different languages. Explicit Representationsgroundcollaborative design by providinga context for communication.Representations help to detect communicationbreakdownscaused by
unfamiliar terminology and tacit backgroundassumptions, and turn the breakdownsinto opportunities to create a shared understanding.Consequently,explicit representations serve as a
basis for the creation of a newand shared languagebetweencollaborators.
Animportant componentof shared context is the intent of the collaborators. A shared understanding of intent promotesmutualintelligibility by serving as a resource for assessing the
relevance of information within the context of collaboration. In everydaycommunication
between people, intent is often implicitly communicatedagainst in the rich backgroundof
shared experience and circumstances. Machines, however, have a limited notion of backgroundthat limits their ability to infer the intent of users (Suchman,
1987).
Domain-orienteddesign environmentsaddress this problemin three ways. First, a domainorientation allows a default intent to be assumed,namely,the creation of a "good"artifact in
the given domain.Second, a construction situation can be "parsed" by the system, providing
the systemwith informationabout the artifact under construction. Third, a specification componentallows the designer to explicitly communicate
high-level design intentions to the system.
In our design environments,design activities, including the communication
of intent, are centered aroundartifacts. Bycapturing the intentions and priorities of designers and associating
themwith the artifacts, design environmentscan have a deep representation of an artifact.
This deeprepresentation allows the systemto locate stored artifacts and informationthat are
relevant to a designer’s task at hand, and providesthe designerwith rich resources for assessing the relevance of delivered information.
The first aspect of our workdescribed is the role of a specification and construction components of a design environmentduring the use of the design environment.The specification
and construction componentsof the KID(Knowing-in-Design)environmentprovide explicit
representations of the design intention and partial solution, whichgroundcollaboration among
designers and clients. Therepresentations also allow designers to communicate
design intentions to the system, thereby establishing a shared context betweenthe designers and the
design environmentthat enables the systemto deliver design knowledgerelevant to the task at
hand. The design knowledgecontained in our design environments has been accumulated
throughprevious design efforts, thereby allowingdesigners to collaborate indirectly with past
designers.
The second aspect of our work described is design environmentseeding, where domainexperts and system builders collaboratively design a design environment-- a complexartifact
in it’s ownright. The EVA(Evolving Artifact) approach uses descriptive representations,
functional representations, and seed prototypes to facilitate a mutual educationprocess between design environmentbuilders and designers. The evolving seed provides a shared context to groundcollaboration betweendesigners havingdifferent backgrounds.
299
5 Collaboration in The KID Design Environment
TheKIDsystem is a design environmentfor creating kitchen floor plans and substantially
extends the JANUSsystem (Fischer, McCall, Morch, 1989). Figure 4 and Figure 5 show
screen images of the KIDSPECIFICATION
and KIDCONSTRUCTION
components of KID. The
specification componentsupports designers in framing their design problem;i.e., specifying
design goals, objectives, and criteria or constraints. Theconstruction componentsupport
designers in constructing a the solution formof the design artifact. In the kitchen domainthe
solution formis a floor plan.
The user interface of KIDSPECIFICATION
is based on the questionnaire forms used by professional kitchen designers to elicit their clients’ requirements. KIDSPECIFICATION
provides an
extensible collection of questions (issues) and alternative answersfrom whichdesigners select
the requirementsassociated with their current design task, and assign weightsto the selected
answersto represent the relative importanceof the specified requirements.If no existing alternatives express their position, designers can add or modifyinformationin the underlyingargumentationbase.
Domain-orienteddesign environments support a rich notion of design context. In KIDthe
designer determinesthe context of design by manipulatinginterface objects in the construction and specification components.The systemhas access to the context through the state of
the interface objects. Thespecification provides informationabout the designer’s high-level
intentions. Fromthe solution construction, the system obtains information about the design
movesthat have been made. The representations in the specification and construction that
define the design context are shared betweenthe designers and the system because the state
of the representationsare accessibleto both.
KIDuses computationalcritic mechanisms
(Fischer et al., 1993)to alert designers to problematic design situations, such as a violation of domaindesign rules, and to provide information
relevant to the situation. KIDcontains two collections of domainknowledge:an argumentation base that stores design rationale, and a catalog base that stores design artifacts. The
argumentationbase is a semi-structured design space that expresses interdependencies betweendesign decisions as well as the contexts in whichthe interdependencies are relevant.
The catalog base contains precedent design cases represented as a construction (floor plan)
and a specification (design requirements).
Conceptual coherence in design can be defined as the "match" between problem requirementsand problemsolution. A fundamentalchallenge for computationaldesign support is to
represent the dependenciesbetweena high-level problemspecification and a low-level construction. KIDuses specification-linking rules to do so. Specification-linking rules mapfrom
a preferencearticulated in the specification to a correspondingcombinationof constraints that
shouldbe satisfied in the construction.
TheSpecification-linking rules enable KIDto detect design situations in whichthe construction and specification are in conflict. Suchconflicts are broughtto the designer’s attention by
specific critics (Fischer et al., 1993). Informationis providedto help designers understand
problematic situations by two knowledgedelivery mechanisms:
¯ RULE-DELIVERER
locates
information in the argumentation base corresponding
to the conflict betweenthe specification and construction. Theargumentativeinformation helps designers to understand the problemand alternative meansfor
300
!~i,- )’
’i
i i "~ ~,~.~
’~ ~I~ ~I~" ,,i
o ..I.
~A~A~A~AA
e ~I.
,
! j °-...-
~.
w,lo M ~ i
4~
II
5
~
i
r!l
|"
’
P
....
I
I~ ;’;-’-""" .........
" .....
,
,
o
.rr.’~-~-~
~,
,
’
"""’"’i’r ’
~ *ih,
c
t
o ¯
iJ ~
,,
o~
I ;"
8
i
¯
g ~
£ ~
301
I!|.
302
resolvingit.
¯ CASE-DELIVERER
orders
the catalog space so that examplesrelevant to the current design situation are easily accessible to the designer. CASE-DELIVERER
computesconformityof each catalog exampleto the current partial specification
by (1) applying specific critics to each catalog example,(2) computingan
propriateness value for the exampleas the weightedsumof the critic evaluations,
(3) ordering the examplesaccordingto the values, and (4) presenting the ordered
catalog examples.
KID’sexplicit representationsof a problemspecification and solution constructionfacilitates:
¯ collaboration betweendesigners and clients: using the specification component,
clients and designers are encouragedto articulate their design problemeollaboratively. An explicit representation of problem specification provided by
KIDSPECIFICATIONhelps them to achieve and maintain a common
understanding
of the problem, and prevents themfrom overlookingimportant considerations.
¯ long-term indirect collaboration: by having the specification component,the
design environmenthas moreshared understandingabout the designer’s intention
for the current task, and thus can deliver task-relevant information. KID’s
knowledgebases contain design information and artifacts accumulatedthrough
past design efforts, enabling designers to collaborate indirectly with their peers
fromthe past.
5.1 Facilitating Direct Collaboration between Designers and Clients
Collaborationbetweendesigners and clients is supported by KIDthrough a specification and a
construction components.KIDSPECIFICATIONallows designers to specify their problems in
terms of the problem domain. In somedomains, KIDSPECIFICATIONcan be used by clients,
not only by designers. Expert designers are good at understanding "’languages of the
domain," such as a representation provided in a construction component.Clients, or endusers of application software, often do not understandsuch languagesof the domain.
The specification componentof a design environmentprovides an explicit representation of a
problem. While prototypes in the construction componentare built by designers, partial
problemsin the specification component
are built by clients.
Specification-linking roles used in KIDfacilitate the communicationbetweendesigners and
clients by providing a mapping between the construction and the specification. The
specification-linking rules represent interdependenciesamongspecification and construction.
Clients specify their problemin the specification component
and designers build their solution
in the construction component.Specification-linking rules can detect inconsistency among
the two in the form of specific critics identified by RULE-DELIVERER
(see the Messageswindowin Figure 5). Arelation of the fired specific critics to the current specification is in the
the Suggested windowin Figure 4. KIDalso helps clients to understand the language that
designers use by looking at a concrete representation of a solution (a catalog example)that
retrieved according to the relevance to their problemspecification by CASE-DELIVERER.
The
Catalogwindowin Figure 5 lists namesof examplesthat are ordered according to the partial
specification.
303
5.2 Facilitating Indirect Long-termCollaboration
As designers use a design environmentto create artifacts, design knowledgeis accumulated
into the system. A typical exampleof this type of knowledgeincludes design rationale and
design artifacts. Designrationale explains whycertain design decisions are madein what
problemsituations. It provides heuristics and a source of design expertise in the domain.
Design artifacts can be "reused" by designers by combining, or modifying them into a new
artifact. Theycan also be used to warndesigners of possible failures that were previously
made.Both design rationale together with designed artifacts provide a source for case-based
reasoning (Kolodner, 1990; Riesbeck, Schank, 1989).
Theargumentationbase and the catalog base of design environmentsfacilitate long-term indirect communicationamongdesigners. That is, designers communicatethrough designed artifacts instead of directly talking or writing. Communication
is embedded
in design artifacts
(Reeves, 1993).
As illustrated in Figure 3, a designer accumulatesthe design knowledgeinto the system and
later another designer can access the design knowledge.Aportion of the design rationale articulated and stored by a designer can be used to produce a specification-linking rule.
Figure 6 illustrates howthe accumulateddesign rationale can be used to derive specificationlinking rules. A detailed description of the mechanismis found in (Nakakoji, 1993). The
catalog base can also provides a communicationmediumamongdesigners. Designers store a
design, whichhelps other designers in producingideas for a solution. Usingcatalog examples
also amplifies designers’ creativity in performingdesign (Fischer, Nakakoji,1993).
KIDsupports not only recording design experiences but also higher level knowledgeacquisition. Competentpractitioners usually knowmore than they can say. This tacit knowledge
(Polanyi, 1966) is triggered by newdesign situations and by breakdownsthat occur in
design process. A user study of KIDhas shown that users of design environments often
wantedto extend them in response to breakdowns(Nakakoji, 1993). Thus, as design environments are constantly used, their domainknowledgeis increased and refined by interacting
with designers.
End-usermodifiability of design environmentscharacterizes this aspect. MODIFIER
(Girgensohn, 1992) is implementedand tested in the context of JANUS,
a precedent of KID.Girgensohn used the representation of objects to allow designers to perform at least someof the
adaptations on a level above that of a programminglanguage. For example, using MODIFIER,
designers can introduce a new concept such as a microwaveoven by copying and modifying
attributes of existing conceptssuch as a stove using a property sheet. Suchmodificationtasks
are supported by providing task agendas, on-line help, examples, and critics. Girgensohn
identified principles to enhanceend-use modifiability of computersystems, including layered
architectures and parameterizations.
The approachdescribed here in terms of KIDhas demonstratedthe effectiveness of supporting
collaborative design in a relatively mature, stable domainsuch as kitchen design. For an
immatureor an unstable domain,whichis relatively new, still under exploration, or heavily
dependingon state-of-the-art technologies,it is difficult to to identify and analyzethe domain
in consideration. Designershaveneither the design knowledge(principles and abstractions),
nor ideas of whata solution formshould look like.
304
Relates
Spedflmltlofl-Ilnklng
Rule
s~e-of-family~une
--~l~e-of-slnk~single.bowl-sink
Figure 6: Integration of Componentsin KID
Spe~i(fication-linking
rules are derivedfroma_partialspecificationandthe argumentation.
I~rived
Sl~cit~cation-linking.rules are used(1)to makesuggestionsin K~SPEC~CA’nON,
(2) to snow
related,argument
in meargumentation
base, (3) Io iaentify relevantcritics byRtI~-DeLIVERi~R,
(4)
to evamatea cauuogexampleusing mespecmcentic, aria (3) to oraer mecatalog examples
CASE-DELIVERER.
6 The Evolving Artifact Approachto SystemBuilding
The kitchen domainhas been a useful object-to-think-with for our design environmentwork.
The broad-basedfamiliarity and simplicity of the domainmakesit ideal for developing and
communicatingideas to a wide audience. Wehave built domain-oriented design environments for other domainssuch as computernetworkdesign (Fischer et al., 1992), lunar habitat
design (Stahl, 1993), and phone-based voice dialog design (Repenning, Sumner,1992).
doing so, we have experienced the difficulty of acquiring the understandingnecessary to build
design environmentsfor these complexapplication domains.
The Evolving Artifact (EVA) Approachis a system design methodology to support design
environmentbuilding in complexdomains, where the difficulty is not knowinghowto implement system functionality, but rather it is knowingwhat functionality to implement. The
"Evolving Artifact" namerefers to the incremental mannerin which the design environment
is created. EVAapproachis a bootstrapping approach, whereunderstanding of the problems
to solved guides implementation, and implementationcreates understanding. This is in contrast with traditional "waterfall" models of system design, in which a detailed system
specification is constructed before implementation proceeds. Waterfall models assume a
305
completeunderstandingof the problemexists before implementationbegins.
The EVAapproach supports system design as a process of mutual education between system
builders and domainworkers(see Fig2). Becausethe critical resource in system building
application domainknowledge
(Curtis, Krasner, Iscoe, 1988), the initial focus is on representing and understanding application domain concepts. In the EVAapproach, descriptive
representations of application domainconcepts provide a context for understanding system
requirements, and functional representations are used to guide implementation of system
functionality. Theevolving design environmentseed consists of both descriptive objects and
functional objects.
In order to further describe the EVAapproach, we will use EVA-SERVICEas an example
(Ostwald, Bums, Morch, 1992). EVA-service is a design environment to support NYNEX
service order representatives to performthe complextask of service provisioning. Service
provisioning begins with a service representative and customercollaboratively designing a
telephone service configuration to meet the customers requirements. It ends with the implementationof that design, whichinvolvesthe coordinatedactivity of manydifferent internal
groups, such as line-workers and billing departments. The service representative’s job includes entering data in databases, tracking downfield personal for progress reports, and
providingcustomerswith detailed telephone service information.
6.1 Descriptive and Functional Representations
Descriptive representations. In the initial stages of system design, descriptive representations are the meansfor facilitating mutual education betweensystem builders and system
users. Thegoal is to build a shared languageof design by representing domainconcepts in a
formthat can be discussed, questionedand refined.
Figure 7 showsa screen imagecontaining a descriptive representation of information flow in
one perspective of the service provisioning task. Thepurposeof the diagramis to stimulate
discussion that surfaces important issues and terminologyabout the domain.Systembuilders
create descriptive representations and domainworkers, whoare experts in their domain,point
out shortcomingsin the diagramor fill in missing knowledge.Modifications are easily made
to the descriptive representation, and related concepts and knowledgecan be represented and
linked using hypermediatechnology. For defining and discussing basic concepts, descriptive
representations are moreuseful than conventionalobject-oriented formalisms.
Functional representations. Descriptive representations are easily understood and modified,
but they do not support domainworkers to envision howdesign environments can support
their work. In particular, descriptive representations do not have the high degree of interactivity that characterizes moststate-of-the-art applications, including design environments.
Functional representations are used to illustrate howcomputationcan be applied to problems
and tasks in the application domain. Functional representations are implementedusing
object-oriented formalisms, and embeddedin descriptive representations. In the EVAsystem,
function calls maybe associated with graphical objects, so that clicking on the object will
execute the function. Embedding
the functional representations in descriptive representations
providesa context for understandingthe functionality.
Figure 8 showsa functional representation that is embedded
in the descriptive object shownin
306
~
Tw
M
ShowDocumenter.ionShowCandidat4sHelp
Dewcrib¢
He
BMO PPovlsionlng
Bookmarks
NIRX92
CXS Im~lenentatlon
Provisioning
Ftgure Record
- Emtes
~
Serv~ce Rep
Customer
Order
N~otlatln
O
8erviee Order
t
Candldateo
EMO ProJect Deecrtotton
Xncenttuea 4n the BMOProJect
Et111ng Untt- 4Th F1Qor. 1166 ¯ of e, NYC
BHO Tttle
Eustness ~arkettn 9 DpQrattQnS (BflO)
EhO Bt111ng
GMOCollect4ane
BHOUtettw
BMO Reconnendattons
BMO Ordertng
1
Figure 7: A Descriptive Representation
Descriptive
representation
as viewed
in the "EVA
TopicBrowser,"
a tool supporting
designenvironment
building.
Thisrepresentation
illustratesanaspecto~meserviceprovisioning
process.
Figure 7. It expresses a possibility of howthe task of "ordernegotiating" mightbe supported. This functional representationallows service provisioners to evaluate the system
builder’sunderstanding
of the task, andprovidesa concretereferencefor discussion.
Functional representations are importantresources for collaboration, becausethey help
workersto articulate their tacit knowledge.
Likethe moreflexible descriptiverepresentations,
functional representationsare meantto exposegaps in the collective understandingof the
domainand howto supportit. Unlikedescriptive representations,functional representations
allow domainworkersto experiencefunctionality in a hands-onmanner.This is an important
307
Figure 8: A Functional Representation
Afunctionalrepre.sentation
is embedded
in. an descriptiveobject. Thisform-based
representation
~emonstrates
a technique
tor supporting
a aatacollecti.on. taskwithdynamically
configured
fields.
nystembuilde~use.thefun.ctionalrepresentationto elicit knowledge
fromserviceprovisioners
a0outt~ interaepenaencies
oetween
fields andfield values.Serviceprovisioners
usethe representationto understand
the conceptof "smartforms".
part of the mutualeducation process, because it surfaces tacit knowledgeworkershave about
their workpractice, thereby allowingthemto contribute their expertise to the task of system
building.
Seed Prototypes. Seed prototypes are used to focus mutual education on issues relevant to
systemuse, such as accessing informationand collaborating with other users. Seedsaxe built
fromdescriptive and functional objects, but rather than embedding
functionality in descriptive
308
Call
Forwarding
Description
Call forwarding causes a call
transferred to mr)other.
to one number to be automatically
Sales Presentation
wCal! forwarding allows you to get valuable business ceils that might
otherwise end up on your con~etltor’a de~;k,...’
Special deals for large businesses . . .
Service Requirements
Call forwardlng requires both lines (the original line and the line to
which the call Is forwarded to) to be touch tone. The service Is net
offered in . . .
Figure 9: EVA-SERVICE
m A Seed Prototype for Service Provisioning
f
Thetop portionof the screenis the form-~interfaceillustr~tted in Figure8. Belowis informationassociatedwiththe "call forwarding
field selectedwithmemouse.
objects, the functional objects are part of the seed interface. In the seed prototype, functional
objects are accessed and manipulatedin the user interface, while descriptive objects provide
information relevant to the user’s task at hand. For example, in the KIDsystem describe
above, the construction and specification components are functional objects, and the
argumentation-basecontains descriptive objects.
In the domainof service provisioning, forms play a role analogous to the construction kit of
KID. Figure 9 shows a screen image of a EVA-SERVICE
prototype based on the functional
"form"representation shownin Figure 8. In this screen image, the form is placed in a system frameworkto simulate how it would appear to users in a fully functional system. Each
field of the formprovides accesses informationthat is helpful to the service provisioner. This
prototype serves to demonstratehowsuch information might be accessed in the course of the
309
service provisioning task. Domainworkerswill be able to contribute their owninformation
(e.g., sales tips, general information,etc) so that co-workerscan access it. This supportsindirect collaboration with co-workers.
This prototype does not represent the final product of the seed building process, but instead
serves to surface important issues in the collaborative design process. Theprototype raises
the questions of, "what fields of the provisioning form should lead to descriptive problemsolving information?", "what types of information are helpful under whichcircumstances?",
and "howcan workersrecord informationso that it doesn’t distract from the task at hand?"
Eventually the evolving EVA-SERVICE
prototype will be mature enough to release into the
workplaceas a design environmentfor service provisioning domain.As illustrated in Figure
3, EvA-SERVICE
will continue to evolve as it is used to support collaborative design between
domainworkers and clients. Indirect collaboration between domainworkers is supported
through the accumulationand sharingof service provisioning knowledge.
6.2 Short-term, Direct Collaboration in EVA
The major challenge of system building is to identify and refine the system requirements of
domainworkers, and to implementappropriate functionality. In the EVAapproach representations serve two purposes: (1) they elicit knowledgefrom domainworkersthat is often tacit
and therefore not expressible in abstract situations, and (2) they communicate
the intentions
systembuilders to domainworkers.In both cases, the explicit representationsare crucial.
Descriptive representations provide a context for collaboration. Theymakethe intentions of
system builders explicit where they can be understood and critiqued by domainworkers.
Descriptive representations allow the stakeholders to identify and understandimportantissues
early in the design process, before time and effort has beeninvested in the wrongdirection.
Functional representations build uponthe understandinggained through creating and modifying descriptive representations. Embedding
functionality in descriptive objects provides context in whichto understandand discuss the issues raised by applying computationto the application domain. Functional representations support mutual education by allowing system
builders to educate domainworkersabout computational techniques, and by allowing domain
workers to educate system builders about what domainknowledgethe functionality should
contain. Service provisioning workerswere able to articulate shortcomingsin our functional
representationsthat they did not identify in the correspondingdescriptive representations.
Seed prototypes provide a shared context for understanding howfunctional and descriptive
objects should be combinedin a mature system. Seed prototypes build upon the shared understanding generated through the construction and evaluation of descriptive and functional
objects.
6.3 long-term, Indirect Collaboration in EVA
Long-term,indirect collaboration is required betweensystem builders and system maintainers
in domainenvironmentreseeding (see Figure 3). Systemmaintainers need to understand the
design decisions that shaped the system. The EVAapproach builds an information space of
descriptive objects as a natural product of the system building process. Thedescriptive objects represent the application domainknowledgeon whichimplementationis based -- cru-
310
cial information for reseeders. Because descriptive objects are understandable by domain
workers, the objects provide a context for collaboration between system maintainers and
domain workers in the reseeding process.
7 Summary
User studies of KIDhave shownthat the explicit representation of client’s goals and intentions
provided by KIDSPECIFICATION
benefits designers in understanding the design problem better
by allowing them to (1) create (frame) concrete objects to reflect on and (2) reflect on (see)
partially framed design with task-relevant design knowledgedelivered by KID. Thus, the system enhances the quality of collaboration
between designers and clients.
The
seeing-framing-seeing cycle of design processes driven by designers in collaboration with the
design environment has been constantly observed in users interacting with KID. Designers’
reflection was enhanced by the sometimes unexpected arrival of information, which has been
stored by other designers. It was observed that the knowledge delivery encouraged designers
to articulate
design knowledge that had been implicit before. Assessment of these
mechanisms illustrates
the specification component’s beneficial role in enabling the KID
design environment to effectively support direct and indirect collaborative design among
designers, clients and the design environment.
The EVAapproach extends our design environment work by applying our design environment
work to industrial setting where (1) we cannot choose problems conveniently, and (2)
complexity of the real world is inescapable. The artifacts produced with the EVAapproach
support long-term, indirect collaboration between system builders by capturing application
domain knowledge that is produced during system building. Specifically,
descriptive
representations that describe important characteristics, terminology and relations of the application domain are useful during the reseeding process. Conventional system building approaches do not focus on domain knowledge, and do not integrate this knowledge within the
system itself. Consequently, system maintainers are often forced to perform their job without
benefit of the knowledgegained by system builders.
Both KIDand EVAprovide a process view of design environments, by greatly facilitating the
accumulation of design rationale (Fischer et al., 1991), and by supporting design as a cycle
framing, action, breakdownand repair (Schoen, 1983; Rittel, 1984).
References
B. Curtis, H. Krasner, N. Iscoe 1988. A Field Studyof the SoftwareDesignProcess for Large Systems,
Communications
of the ACM,31 (11), November:
1268-1287.
G. Fischer, A.C. Lemke,R. McCall,A. Morch1991. MakingArgumentationServe Design, lluman Computer
Interaction,6(3--4):393-419.
G. Fischer, J. Grudin,A.C.Lemke,R. McCall,J. Ostwald,B.N.Reeves,F. Shipman
1992.SupportingIndirect,
Collaborative Designwith Integrated Knowledge-Based
DesignEnvironments,HumanComputerInteraction,
Special Issue on Computer
SupportedCooperativeWork,7(3):28 I-314.
G. Fischer, K. Nakakoji,J. Ostwald,G. Stahi, T. Sumner1993. Embedding
Computer-Based
Critics in Ihe
Contexts of Design, in HumanFactors in Computing
Systems, INTERCHI’93
ConferenceProceedings, ACM,
(in press).
311
G. Fischer, R. McCall, A. Morch1989. JANUS:Integrating Hypertext with a Knowledge-BasedDesign Environment, in Proceedings of Hypertext’89 (Pittsburgh, PA), 105-117, ACM,NewYork.
G. Fischer, K. Nakakoji 1992. Beyondthe MachoApproachof Artificial Intelligence: EmpowerHumanDesigners - DoNot Replace Them,Knowledge-Based
Systems Journal, 5(1): 15-30.
G. Fischer, K. Nakakoji 1993. AmplifyingDesigners’ Creativity with Domain-OrientedDesign Environments,
Artificial Intelligence andCreativity.
A. Girgensohn 1992. End-UserModifiability in Knowledge-BasedDesign Environments, Unpublished Ph.D.
Dissertation, Department of ComputerScience, University of Colorado, Also available as TechReport CUCS-595-92.
J. Greenbaum,M. Kyng(eds.) 1991. Design at Work: Cooperative Design of Computer Systems, Lawrence
ErlbaumAssociates, HiUsdale, NJ.
J.L. Kolodner1990. Whatis Case-BasedReasoning?,In AAAr90
Tutorial on Case-BasedReasoning, pp. 1-32.
K. Nakakoji 1993. Increasing Shared Understandingof a Design Task between Designers and Design Environments: The Role of a Specification Component, Unpublished Ph.D. Dissertation, Department of Computer
Science, University of Colorado.
J. Ostwald, B. Bums,A. Morch1992. The Evolving Artifact Approachto SystemBuilding, in WorkingNotes of
the AAAI1992 Workshopon Design Rationale Capture and Use, AAAI,207-214, San Jose, CA.
M. Polanyi 1966. The Tacit Dimension,Doubleday,Garden City, NY.
B.N. Reeves1993. The Role of Embedded
Communication
and Artifact Itistory in Collaborative Design, Dissertation Thesis, Departmentof ComputerScience, University of Colorado,Boulder, CO, (forthcoming).
A. Repenning, T. Sumner1992. Using Agentsheets to Create a Voice Dialog Design Environment,in Proceedings of the 1992 ACM/SIGAPP
Symposiumon Applied Computing, ACMPress, 1199-1207, (also published as
Technical Report CU-CS-576-92).
C. Riesbeck, R.C. Schank1989. Inside Case-BasedReasoning, LawrenceErlbaumAssociates, Hillsdale, NJ.
H.WJ. Rittel 1984. Second-Generation Design Methods, in N. Cross (ed.), Developments in Design
Methodology, John Wiley & Sons, NewYork, 317-327.
D.A. Schoen1983. The Reflective Practitioner: ltow Professionals Think in Action, Basic Books,NewYork.
G. Stahl 1993. Interpretation in Design: The Problemof Tacit and Explict Understandingin ComputerSupport
of Cooperative Design, Unpublished Ph.D. Dissertation, Department of ComputerScience, University of
Colorado, Forthcoming.
L.A. Suchman1987. Plans and Situated Actions, CambridgeUniversity Press, Cambridge,UK.
312