From: AAAI Technical Report WS-93-07. Compilation copyright © 1993, AAAI (www.aaai.org). All rights reserved.
Using stories to overcomesocial obstacles
in design collaborations
E. A. Domeshek1, J. L. Kolodner1, R. BilHngton I ~
and C. M Zimring
ICollcge of Computing
~Collegeof Architecture
Georgia Institute of Technology
Atlanta GA 30332-0280
USA
1.
Collaboration in Design
Thelone design genius, if not mythical or completelyextinct, is surely on the endangered
species list. Nowadays,significant design projects require teams of designers coordinating
their varied expertise to arrive at effective designsolutions. In moreprogressivecircles, design
teams do not workalone either. As the world adopts methodssuch as ConcurrentEngineering
(CE) and Total Quality Management
(TQM),designers are being required to coordinate
customers, marketers, production experts, maintenancestaff, and all the other stakeholders
likely to be affected downstreamby the evolving design. Common
sense responses to
growingcomplexityand past failures are crystalizing into neworganizational conventionsand
newdesign procedures. Thesenewforms reflect a growingrealization that higher quality,
lower cost products can be producedmorequickly if potential problemsare recognizedearlier
in the designcycle.
Despite its desirability, spatial, temporal, and social barriers often prevent effective
collaboration on design projects. Weare interested in studying the social obstacles to design
collaborations. Webelieve wecan build computertools that will contribute to overcoming
those obstacles. In contrast to muchworkin the burgeoningfield of ComputerSupported
Cooperative Work(CSCW),we are not devising technical and procedural innovations
improvecoordinationof spatially and temporallydistributed groups. Noveluses of computers,
networks,databases, and displays can help deal with the reality that large design teamscannot
143
always workin the sametime and place, and maynot even workon the sametime scale. But
whenwe look at complexlarge-scale design situations, we see that even once the physical
obstacles to collaboration are resolved, there remainsocial obstacles to turning communication
andcoordinationinto effective collaboration.
Teamsare assembled,in part, so that their memberscan contribute a variety of strengths and
abilities to the task. A design team is usually composedof individuals drawnfromdifferent
specialities. Theycometo the project with different prior knowledgeand expectations. They
maybe workingto fulfill different agendas.Theyfit into different roles, and those roles partly
determine howthey get to influence the project. These differences multiply as more
downstream
stakeholdersare broughtinto the earliest design deliberations.
Changesin design practice are beginning to makecommunicationamongvarious participants
morefrequent. Webelieve we can help makesuch communicationmoreeffective. If we can
directly improvethe quality of interactions, wemayalso havethe desirable effect of increasing
their quantity as well. Wehave, for sometime, been developingcomputer-baseddesign aiding
tools. Nowwe want to extend these tools to improvecommunicationand coordination among
participants in conceptualdesign -- to bridge the social gaps introduced by diversity among
designparticipants.
2.
Social Obstacles to Effective Design Collaboration
Wesee the social obstacles to collaboration as fitting into three broadcategories: structural,
relational, and cultural. Ourgrouphas focusedon the cultural differences that restrict people’s
ability to understandand contribute to a collaboration. Webreak downcultural obstacles into
differences in goals, differences in abilities, differences in knowledge,and differences in
conventions. Theconventionsweare concernedwith are primarily distinctive waysof talking
about or otherwiserepresenting design issues, but mayalso extend to conventionsfor howto
proceed with design, or even howto behave in a collaboration. Just as overcomingthe
obviousphysical obstacles to collaboration still leaves all these social obstacles, so too,
overcomingthe structural and relational problemsleaves a complexset of cultural stumbling
blocks. Figure 1 sketchesour taxonomy
of social obstacles to effective design collaboration.
Communication
is difficult whenparties do not share common
backgroundand assumptions,
or whenthey lack a common
technical languageand facility with external representations. We
believe that failures of attemptedcommunication
are most apparent, and also mostdetrimental,
in the early stages, during conceptualdesign. Early in design, the design team-- especially the
extended team, including clients and users -- is not a cohesive group. Early on, membersdo
not have muchpersonal feel for one another, and they lack any shared group history or any
commonreference points. The normal terms of discussion in conceptual design only
exacerbate these problems.In the absenceof concrete design proposals, the participants will
often talk in termsof abstractionsand generalities. Butwhata structural engineerthinks of as a
"large" space maybe quite different than what an architect meanswhenhe says "large"; the
engineer worries about spanninganythingfroma living roomto a conventioncenter to a river,
whilethe architect visualizes somethingscaled to his imageof a building designformingin his
head. Similarly, a space described as "large" probably conjurs different images for a
custodianwhohas to keepthings clean, and the state official whohas to pay for the building.
Bythe end of the crucial conceptualdesign phase, the designers mustcometo understandwhat
144
the clients and users really want, while the clients and users must cometo understandthe
design implications of their desires as well as newpossibilities created by innovativedesign.
Both of these ends can be advancedby carrying out a dialogue in the context of specific
examplesof related artifacts. Illustrative examplescan be quite powerful; consider, for
instance, the difference betweenabstractions like "we’ll havea large waiting area outside the
courtrooms",and concrete imagesof existing courthousewaiting areas that give an immediate
feeling for whatit is like to be in thosespaces.
¯ Structural
- Lack of opportunity to Interact
- Lack of inclination to Interact
¯ Relational
- Lack of trust or respect
- Differences in status or power
- Fear of embarassmentor failure
¯ Cultural
- Differences in goals
- Differences In abilities
- Differences in knowledge
- Differences in conventions
+ Vocabulary
+ External Representations
+ Design Procedures
+ Collaboration Procedures
Figure 1: Taxonomy
of Social Obstaclesto Collaboration.
3. The Value of Concrete Communication
Ourbasic premiseis that couchingdesign issues in terms of concrete examplesis one of the
most useful things we can do to help the various design participants arrive at a common
understandingof their problemand the possibilities for solutions. Examplescan serve as aids
to communicationamongstdiverse membersof an extended design team. For instance, in the
context of designinga countycourthousethe questionof whatcounts as a "large public waiting
area" can be answeredby looking at someexisting county courthouses and focusing on some
particular waitingareas in those buildingsthat havethe characterdesired. If an architect tries to
design a residence for the disabled with standard bathroomsan exampletelling of howthe
residents will suffer can makeclear to her whyher users object. If a client asks for a large
floorplate building with private offices all aroundthe perimeter, an examplehighlighting the
dimcavernousinterior can makeclear to himwhyhis architect objects.
Theseexamplessuggest kinds of interactions that could be supportedby a design tool capable
of storing and presentingevaluative stories along with documentation
aboutexisting buildings.
Easy access to examplescould help design participants workingindividually to prepare for
meetingsby anticipating others’ reactions. Discussionsduring actual meetingscould be more
productivebecausethe teammembers
could easily refer to relevant details of specific examples.
145
Easy access to exampleswouldmakeit easier to conveythe reasons for particular design
decisions to other team members.Appealto examplescan also serve to bolster the claims of
low status teammemberswhomight otherwisebe hesitant to advancetheir point of view.
Whencontrasted with design guidelines stated as abstract rules, design lessons taught in the
context of particular evaluated existing designs have manyadvantages:examplesmakedesign
lessons morevivid, and thus morememorable;examplesare embeddedin a context so users
can makemoresubtle attributions of cause and effect, and thus moreprecisely determinewhen
the lesson applies; well crafted presentations of examplescan also teach aspects of an
underlyingmodelof the domainas they teach the higher level design lessons. Whencontrasted
with rule-based critiquing and advising, a story-based approachto representing and teaching
design lessons makessense because manyaspects of design lack a solid underlying domain
modeland because, accordingly,mostdesign guidelines do not really havethe force of rules.
4.
Research Issues for Design Collaboration
If we expect existing artifacts to influence newdesigns, it is critical that we create
presentations that teach clear lessons and prepare effective external representations of those
design experiences. Wecannot magically transport a group of users to the sites of sample
buildings to experiencedirectly the goodand bad aspects of their design; evenif wecould get
themto the sites, wecould not ensure they wouldtalk to the right stakeholdersthere, or that
they wouldbe told the relevant stories on cue. Usinga particular existing building as an
exampleto teach a design lesson requires crafting a presentationthat makesthe desired points.
The sameholds true for most other types of artifacts. Wecall such presentations stories.
Stories, in this sense, neednot be texts, or neednot be soley texts. Ourchoice of architecture
as a domainhas driven us to concentrate heavily on graphical presentations, and we are
interested in multimediapresentationsin general.
Wecan take graphic presentations as representative of the sorts of problemswe expect to
encounter whenaiming presentations at audiences with divergent backgrounds.For instance,
floor plans are a good wayto illustrate someaspects of building design; floor plans are
developedand used by architects to facilitate their ownthinking and to communicate
with some
of the other participants in buildingdesign. When
architects looks at floor plans, certain things
are particularly salient andmeaningful:theyinstinctively note the scale, andwith their extensive
experience,are capableof accuratelyinterpretting the real sizes of the spacesdepicted;they can
decodethe distinctive fill patterns that often indicate somethingaboutthe materials used for
parts of the building; they can interpret schematicsymbolsor annotationsshowingconstruction
details. Whenpotential residents of a building looks at a floor plan, they are unlikely to see
any of those things; they will simplysee the relative sizes and arrangementsof rooms.If the
point of the story being presented(in part) by that graphic dependson any of the cues that are
(initially) invisible to oneset of designparticipants,then there is a potential problem.
Wehave said that various design participants maynot understandeach other wheneach speaks
their ownnative languages,particularly whenthey talk in abstract and technical terms. Ideally,
we will arrive at somewayto characterize what kinds of gaps separate the participants’
conceptions of the evolving artifact. Wewill not only describe the differences in their
experiencesand points of view, but also the similarities. Wewill developsomeinsight into
whichdifferences are really significant impediments
to communication
and howsimilarities can
be exploited to compensate.If groundingdiscussions in concrete examplesis to help avoid
146
misunderstandings,wewill have to face the question of what kinds of concrete details make
sense to different design participants, and whatkinds of waysof talking aboutor illustrating
exampleswill effectively communicate.
5.
CBR and CBDAs
Wehave, for some time, been developing an example-drivenapproach to helping designers
think through the implications of their conceptual design proposals. Nowweare looking at
howto apply a similar approachto supportingdesign collaboration. This approachto building
design tools is rooted in the Artificial Intelligence paradigmknownas Case-BasedReasoning
(CBR).In brief, CBRis an appropriate technologyon whichto base computerizeddesign aids
becausea significant factor in gooddesign is experience, and CBRis an evolvingtechnology
aimedat capturing and retrieving useful experiences. It is a common
enoughobservation in
design research that designersin all fields makeextensive use of case studies, precedents, and
prior personal experience. Andit is a common
frustration of design practice that finding
records of past experience is often annoyingly (or even prohibitively) expensive.
Psychological research further suggests that people are often quite poor at picking out
appropriate past experience, even whensuch experiences are present in their ownmemories.
Ourdesigntools aimto broadenthe availability of experienceswith designand use of artifacts.
Thesetools are called Case-BasedDecision Aids (CBDAs).Theyhelp designers by supplying
themwith descriptions and evaluationsof prior designs relevant to current decision making.In
the context of a current problem,an old design can be taken as a suggestion, a warning,or a
prod to consider particular issues. For the systemto retrieve relevant examples,the user must
give it somedescription of the current problem and any partial commitmentstowards a
solution. In response, the system can present a view of somepast design annotated with
stories that teach lessons the user should knowabout in the current situation. Theviewsmay
be graphical or textual. Thestories maybe only a selected subset of everything the system
knowsabout the old design. Fromthe initial view, whichmayencompassonly a part of an old
design, the user can access other informationaboutthat old case. Fromthe selected stories, the
user maybrowseto presentations of relevant design guidelines that suggest howa designer
should approacha related class of problemsin general. Guidelines, in turn, provideaccess to
other stories (perhapsdrawnfromother designs) that serve as illustrations, counterexamples
caveatsto the generalrule.
The issues in designing and building CBDAs
include 1) gathering stories and guidelines, 2)
preparingeffective presentations for a targetted user group, 3) developinga wayof describing
the stories so they can be foundin responseto a user’s situation, 4) finding an acceptableway
for users to expresstheir situations, 5) providinga limited but useful set of presentationsand
browsingoptions at any time.
Wehave been developingCBDAs
for several domains,including architecture, lesson planning
and airplane design. As wehave developedthese tools, it has becomeapparent to us that they
could provide a basis for correcting the communication
breakdownsso common
in large design
efforts. Webelieve CBDAs
can play this importantrole becausetheir majoreffect is to illustrate
the implications of constraints and proposals in concrete form -- as stories of real examples
with supportingdocumentation,illustrations, and analysis.
Doinga goodjob of supporting collaboration will require further pursuit of several already
147
active lines of inquiry and will result in evolutionarygrowthin our CBDA’s
capabilities. We
will continueto look for formsof experiential material that can be of use to a workingdesigner,
but wewill also consider whensuch materials might be appropriate for other users. Wewill
continueto look beyondcase materials per-se to explorethe effective integration of experience
with generalizations, rules and principles, but we must rememberthat not all users have
appropriate backgroundto understandgeneralizations (with their technical terms and unstated
limitations), or to interpret examples(with their welter of relevant and irrelevant details).
will continue to seek effective organization and presentation strategies, but wewill haveto
considerthe background,interests, and mediaexperienceof all participants.
148