HCII 2005 paper

Patterns to Promote Individual and Collective Creativity
John C Thomas

IBM T.J. Watson Research Center
PO Box 704
Yorktown Heights, New York 10598 USA
jcthomas@us.ibm.com
www.truthtable.com

Abstract
To some, “Collective Creativity” sounds like an oxymoron. In American culture, at least, the culturally accepted
icon of creativity is of the lone inventor, struggling against all odds, perhaps an outcast, “swimming against the tide”
until she or he is ultimately successful (or not). This story-line is supported by the Patent System which presumes a
basic dichotomy between those who “were” and those who “were not” involved in the innovation behind a patent.
In classical Aristotelian story, there is a “hero” who overcomes all odds and enemies to become successful in the
end. From a social engineering perspective, there is an advantage to the promulgation of such a myth. It might help
prevent discouragement from those who are on an exploratory path far from the mainstream. However, the
downside risk is that this myth minimizes both the impact of the larger social and cultural context within which
innovation occurs and the more local impacts of family, community of practice, and industrial policy. Moreover,
even in the unlikely (though appealing) story of an isolated individual breakthrough effort, whether or not that effort
influences the rest of society depends on cultural and social factors. The truth lies more in the acceptance of a kind
of tension between individual and collective creativity.

Perhaps an apt analogy may be drawn from golf. Tiger Woods is obviously an amazingly able individual combining
innate talent with early and persistent training. On the other hand, it would be meaningless to ask “how good a
golfer would Tiger Woods be if the game did not exist?” The existence of golf courses, instructors, manuals,
traditions, rules, best practices, and an economic infrastructure all support the development of such an individual.
On the other hand, it is also true that this particular individual has increased the economic infrastructure for the
game generally through his popularity and has increased the number of future players through his foundation. This
is a prototypical example. The individual both benefits from and contributes to the social system and the social
system both gives rewards to and benefits from those individuals who manifest advances in a field.
In an attempt to recognize and facilitate this reciprocal relationship between the individual and the social context (at
various levels of scale), we propose a Pattern Language for Collective Creativity which comprises an inter-related
set of named recurring problems and their associated solutions. Patterns include: “Who Speaks for Wolf?”, “Small
Successes Early”, “Support Conversation at the Borders”, “Special Roles for Special Purposes”, and “Cycle of Unity
and Diversity.” A current real-world application of these patterns is to support a community of practice in
consulting which requires both flexibility to deal with individual clients and uniformity so that knowledge gained in
one arena may be used in another.

1 Background and Motivation
An agent (individual human, group, organization, or software agent) can be said to have a problem if there is a
mismatch between the current state and some desired state and there is no pre-existing algorithm for transforming
the current state to the desired state. Problems can be categorized according to whether the starting state, the ending
state, and the allowable transformations are well-defined or ill-defined. Proving a Euclidean Theorem is an example
of a completely well-defined problem while designing a house, a useful software system, a new business process and
writing a teaching story are examples of completely ill-defined problems. There are many software tools for helping
people solve various types of well-defined problems; however, relatively few tools exist for helping people solve ill-
defined problems such as design problems. Yet, design problems are often extremely high leverage problems. For
instance, errors in design, whether in software, drugs, business processes, public buildings, or automobiles are
extremely costly, compared, for instance, with coding errors or manufacturing errors. Conversely, effective and
innovative designs can be extremely lucrative; innovation is one of the hallmarks of long-lived companies (Collins
and Porras, 1994; DeGeus, 1997).

The world is changing more quickly but the ability of people to creatively design has not increased in any noticeable
way. As a result, there is a widening gap between the degree of flexibility and creativity that is needed to adapt and
the capacity of individuals and organizations to do so (Drucker, 1995). In particular, failure to innovate is not
random, but can generally be ascribed to two main difficulties: 1. Individuals or groups do not engage in effective
and efficient processes of innovative design. 2. The necessary skills, talents, and knowledge sources are not brought
to bear on the problem. Laboratory (e.g., Thomas, 1974; Carroll, et. als, 1980; Farnham, 2000) as well as field
research (e.g., Carroll, Thomas, & Malhotra, 1979; Olson & Bly, 1991; Poltrock & Englebeck, 1999) over the last
several decades has established that the major process difficulties of individuals and groups are mainly due to a
limited number of errors and that these errors can be avoided or ameliorated by providing appropriate structure.

The appropriate overall structure for innovation has several sub-steps and structure is necessary both to help
facilitate the progress through these steps and to help guide the separate sub-steps; distinct guidelines are appropriate
for each of these sub-steps (Stein, 1974; Thomas, 1989). As an example of a common failure in the overall control
structure, people typically fail to spend sufficient time in the early stages of design; viz., problem finding and
problem formulation (cf. Sobel, 1995). As an example of a common failure during a specific stage of innovative
design, people often bring critical judgment into play too early in the idea generation phase of problem solving. As
another example, empirical evidence shows that, unlike Newell and Simon‟s (1972) normative model of ideal
problem solving, in fact, people‟s behavior is path-dependent and they are often unwilling to take what appears to be
a step that undoes a previous action even if that step is actually necessary for a solution (Thomas, 1974). As a third
example, most people find it difficult to generate additional solutions after they have generated one that they feel
solves the problems. No doubt, there are cases where time pressure may require this approach, but in many cases,
the generation of additional solutions may be critical. Other solutions may not only meet the requirements, but
exceed them in various ways. Or, conditions may change in a way that makes the first solution no longer tenable. A
particularly insidious type of example occurs in the interpretation of ordinary social interactions. Since human
behavior is so complex, we can consider the creation of an interpretation or narrative as a kind of creative endeavor.
Consider the following example. You are sitting in a meeting room and note that Fran is not there. The clock reads
10:04 and according to your calendar the meeting is supposed to start at 10:00. You create the following
interpretation: “Fran does not really care about this project.” This might be true. According to the Iroquois “Rule of
Six” (Underwood, 1999) however, before acting on such an interpretation, one should generate five additional
interpretations. In this case, additional solutions might include: 2) Your calendar is wrong. 3) The clock is wrong.
4) Fran comes from a culture where 10:00 means sometime near ten. 5) Fran got waylaid on the way to the meeting
by the company President and is currently pitching the project. 6) Fran is stuck in a traffic jam.

Regarding the second issue (bringing to bear necessary skills, talents and knowledge sources), evidence suggests
that individuals have a large amount of relevant implicit knowledge which they often will not bring to bear on a
problem and that giving appropriate strategies (Thomas, 1974), knowledge sources (Thomas, Lyon, and Miller,
1977) or representations (Carroll, Thomas, and Malhotra, 1980) can significantly improve an individual‟s
effectiveness in problem solving and innovation. In controlled laboratory experiments, for instance, Carroll,
Thomas, and Malhotra (1980) showed that subjects did significantly better in a temporal design task when they used
a spatial representation; yet, very few subjects spontaneously adopted such a representation. The impact of
felicitous representations, however, is not confined to laboratory demonstrations. Speech research advancements
accelerated greatly when waveforms were largely replaced with speech spectrograms and Feynman diagrams
allowed similar breakthroughs in atomic physics.

2 Pattern Languages
A Pattern is a recurring problem in a specified context, an analysis of that problem, and the (named) outline of a
solution. In its full form, a Pattern consists of several parts: a useful, evocative, and mnemonic pattern name, the
author (with reviewer and revision dates), synonyms for the pattern name, an abstract (possibly including an
evocative picture), a statement of the problem that the pattern attempts to solve, a statement of the context(s) in
which the problem occurs, an analysis of the forces in the problem, the solution (possibly including one or more
schematics), some examples of how the pattern might be applied, the likely resulting context(s) of applying the
pattern, the rationale explaining how and why the solution works, references to related patterns, reference to some
known uses, and a reference section listing any relevant literature. A Pattern Language is a set of inter-related

patterns that deals with some coherent domain. While each individual pattern has utility, a Pattern Language also
has emergent utility. A Pattern Language makes an implicit claim about how to partition complex problems into
more manageable sub-problems. The structure of the language itself helps designers find those Patterns relevant to
the task at hand. Work presented here focuses on the Socio-technical area because technological and social issues
must be addressed concurrently. Many failures to reap the proposed benefits of systems come from trying to solve
problems either by technology alone or by social practice alone.
The first Pattern Language was developed by an architect named Christopher Alexander (Alexander, et. als., 1977).
The Pattern Language approach has since been applied to many different fields; first, and most notably to Object
Oriented Programming design (e.g., Gamma, et. al, 1995; Vlissides, et. als., 1996). In addition, attempts have been
made to build pattern languages in Human Computer Interaction, Business Process Design, Change Management,
and Organizing Software Projects. Technological and social support for increasing individual and group creativity
may be generalized appropriately through the development of a socio-technical Pattern Language.

3 Patterns for Creativity Enhancement
In this paper, we cannot present an entire Pattern Language for Creativity Enhancement (and, to the best of my
knowledge, such a complete Pattern Language does not exist); however, some example patterns are given in outline
in order to exemplify such patterns.

Small Successes Early

Abstract: Some problems require large teams of relative strangers to work together cooperatively in order to solve
the overall problem. Yet, people generally take time to learn to trust one another as well as to learn another's
strengths and weaknesses and preferred styles. Plunging a large group of strangers immediately into a complex task
often results in non-productive jockeying for position, failure, blaming, finger-pointing, etc. Therefore, insure that
the team or community first undertakes a task that is likely to bring some small success before engaging in a
complex effort.
Context: A complex undertaking requires the interaction of many people with various backgrounds, skills, and
temperaments. Often, whether in an industrial setting or a community building effort, many of these people have
not worked together before. The group wants to get started and wants to be successful. Although their diversity is a
potential source of strength, at first, there is likely to be natural confusion about how to proceed because people will
have different experiences about the best way to organize and proceed.
Forces:
* Problems are often too complex for all aspects to be addressed simultaneously.
* If a problem is understood, it is logically better to deal with the hardest constraints first.
* The structure of complex problems often becomes clearer as one tries to solve the problem.
* A part of any complex problem solving process requiring more than one person is the interaction and relationship
among the people.
* People in a new team need to learn about each other's skills, working styles, and trustworthiness.
* When people get frustrated because of non-success, they tend to blame each other.
* As people work toward a goal, the goal tends to become viewed as more valuable and therefore people are willing
to work harder to reach it.
Solution: Therefore, when bringing new teams or organizations together, it is useful to begin with a small success.
In this way, people begin to learn about each other and trust each other. People learn more about the nature of the
problem domain. This makes tackling more difficult problems later relatively easier.
Example: At the kick-off to a new software development project, rather than having the people be invited to
"attend" an event that is "thrown" for them, encourage them to organize a party, cook-out, pot-luck, song-fest, or
storytelling event among themselves. In the process of organizing and carrying out this activity, they will learn about
each other's styles, learn about the trustworthiness of others, and be encouraged by having a success.
Alternatively, the team might simply work on an aspect of the problem to be solved, provided it is something fairly
clear that will result in "success" quickly. For instance, the team might initially work profitably on a short
presentation about the project, a poster, or a scenario but not immediately jump into working on a systems design or
a requirements document.
Rationale: As people experience team success, they tend to view the others in the team more positively. Teamwork

is often hard under the best of circumstances. In highly complex problems, when people come together from
different cultures, backgrounds, or agendas, it often becomes so difficult as to seem impossible. Rather than having
people simultaneously attempt to solve a complex problem AND at the same time learn to work together as a team,
it is often more effective to separate the otherwise tangled problems. First, have the people solve a tractable
problem where it is clear that they have a common agenda. A successful experience working together to solve that
simple problem will help people learn each other's styles, strengths, weaknesses and so on. With this knowledge and
trust, they can now move on to try to solve more difficult problems. Some care should be given to the task and
setting. The "small successes early" task should allow some degree of give and take, some opportunity for
expressive, not just instrumental communication. People should have the opportunity and space for doing something
creative, for sharing stories, for physical interaction.

Support Conversation at the Borders
Abstract: In complex business processes, it is often the case that many people and or computer programs in
sequence are required to perform the complete process. Designers of business processes try to anticipate the
information necessary to flow along these sequences in order to make sure the entire process works consistently.
However, in reality, it often occurs that unanticipated additional coordination is required among the sequential
components in a complex process. Therefore, across each transition, an additional facility should exist for
conversation; that is, the transfer of unanticipated but vital coordinating information.
Problem: One would like to have processes that are efficient and effective and lead to customer satisfaction even if
the assumptions about the needs for information interchange among sub-processes in a more complex process turn
out to be insufficient in scope.
Context: Businesses today are always striving to become more efficient. Part of the solution offered for this
striving toward greater efficiency is to automate some steps. When a human being is required to perform some steps
in the process, most organizations choose to specialize function; that is, train one group of people to perform one
function and then “hand off” the process to another group of people that has been trained to perform another
function and so on. In fact, the level of integration that organizations strive for now commonly extends across
formal corporate boundaries so that various elements in a supply chain attempt to coordinate their efforts. There is
no doubt that such larger scale integration can result in greater efficiency. Systems are seldom designed, however,
with a complete understanding of every possible contingency that can arise. Indeed, that is probably impossible in
principle. What often happens is that systems are designed under a set of assumptions that are often, but not always
true. When the assumptions break down, it is important for people on both sides of a functional boundary to be able
to have a cooperative conversation in order to solve the problem left by the gap between the actual reality of a
situation and the model implied by the system design. Luckily, given the right atmosphere, culture, and incentive
structure, people can generally solve such problems. It helps greatly if they have the time and the appropriate space
(preferably real, but at least virtual) to keep informal communication paths open through conversation. In this way,
when a problem arises, they are much more likely to “bridge the gap” constructively rather than point fingers.
Historically, many organizations have recognized the need for such informal conversational ties and have provided
both special places (Officer‟s Club; Traditional Pub; Company Cafeterias) and events (Company Picnics; Religious
Retreats; Holiday Parties; Clubs) to facilitate such interchanges. As organizations attempt integration across ever
wider scales however, providing appropriate venues becomes increasingly challenging. In some cases, two related or
sequential functions will report to a single manager. In such cases, the manager may serve part of the
communication bridging function. Clearly, however, in complex, multi-step processes, formal management
methods alone will be insufficient for coordination across all the boundaries. When links in a processing chain do
not converse, inefficiency and poor customer service result.
Forces
* Modern business processes are often too complex to be understood in detail by any single person.
* Performance on any task is generally a logarithmic function of time on task.
* A person‟s time is limited.
* Complex systems are typically designed and built by decomposition.
* Systems to automate, semi-automate, or coordinate are generally designed by people who are not the people who
actually do the tasks.
* Designs can never anticipate all contingencies.
* Human beings can negotiate to solve novel coordination problems via conversation.

* People find conversation in the service of finding and solving problems rewarding.
* People are subject to forming “in-groups” and “out-groups.”
* If “in-groups” and “out-groups” are formed, rather than negotiating a solution to a problem that is globally
optimal, each group will try to “win” by forcing the solution that is optimal for their sub-function.
Solution
At a minimum, Time, Space, and Means as well as Motivation must be provided for employees who form a bridge
from one step in a process to the next to carry on continuing informal conversation. Employees must have time to
carry on such conversations. A space must be provided in which such conversations can take place. If a physical
space convenient to both parties is not feasible, some means of support for informal distant collaboration and
conversation is necessary. Payoffs must accrue to the parties across a bridge jointly for solving problems, not for
proving that the other party is to blame.
Examples
At IBM Research, I used to play a lot of tennis with other IBMers including an inter-company league. In the course
of playing tennis, I met someone in the corporate tax department. I also used a system called ITIRC which returned
the abstracts of scientific and technical articles that were predicted to be interesting to me based on a key-word in
context search. Such systems are not terribly accurate and I got many false positives. One in particular had nothing
whatever to do with my interests; it was about a new federal program that allowed highly profitable companies to
trade tax credits with companies that were losing money. Instead of throwing this in the trash, because I had had
conversations with Frank, I forwarded the abstract to him who looked into this program and saved a lot of money for
IBM. This case illustrates that ideally people with no obvious process connection should be able to converse
informally.
In planning the first Universal Usability Conference (ACM SIGCHI), it was necessary to delegate various functions
to various parties. While, we attempted to plan ahead of time by standard tools such as budgets and project
timelines, there were numerous unanticipated problems that needed to be solved. A weekly conference call among
all the functional heads allowed us to identify and solve such problems effectively and efficiently.
In WorldJam (an on-line 3 day company-wide electronic meeting in which all IBMers were invited to participate;
generate ideas and comment on them in ten topics), moderators and facilitators used Babble (an electronic blended
synchronous/asynchonous chat) and Sametime (a synchronous chat system) as backchannels to collectively solve
problems, as well as to coordinate information among the ten topics.
In Hanna Pavillion, a children‟s psychiatric hospital in Cleveland, each change of shift is marked by a short joint
staff meeting in which any particularly novel observations or issues are discussed so that a continuity of knowledge
persists across the shift boundaries (this is common in most medical settings, in fact). In addition, at least some
people work double shifts or rotating shifts and get to know people from various shifts. There are ample
opportunities for informal conversation during the course of the day as well as in various special outings. On these
occasions, staff members can insure coordination of treatment for a specific child across the boundaries of the
various nurses, psychiatrists, occupational therapists, and child care workers who interact with each child.
Resulting Context
In the ideal case, trust and even friendships can develop among people working on related processes even though
they belong to different functions and report to different managers. Unanticipated problems can be identified,
solutions designed and implemented in a cooperative spirit. As a result, the workforce is more productive and more
satisfied leading to lower turnover, absenteeism, and sabotage. Further, the customers ultimately benefit from
improved service and feel as though they are dealing with an integrated and intelligent entity and not an
uncoordinated collection of selfish “not my job” people.
Rationale
People are naturally social beings. Conversation with others to solve jointly identified problems is a pleasurable and
useful activity. However, people also have a tendency to form “in-groups” and “out-groups” which resist globally
optimal solutions. The balance of these opposing tendencies can be shifted by allowing people the time, appropriate
space, and lending management support to conversation and informally solving problems without resort to officially
escalation.

Radical Co-location
Synonyms
“Put the team in one room for the duration of the project”, “War rooms”

Abstract: When small to medium teams of people need to solve a problem or design a novel solution and there are
many highly interactive parts, it is useful for the people to work in one large room where people have easy access to
each other and shared work objects can be easily viewed, modified, and referred to when necessary.
Problem
Some problems are amenable to decomposition; that is, the overall problem can be broken down into a series of sub-
problems and when each of the sub-problems is solved, the overall problem will be solved, possibly with slight
modification to some of the sub-solutions.
In other cases, especially problems that are relatively novel, complex, or “wicked”, such decomposition is not
possible. If decomposition is attempted and each of the sub-problems is solved, the resulting composition of sub-
solutions will not be anything close to an overall solution. Under these circumstances, people working alone on
their sub-problem will become frustrated because all the progress they thought they had made will prove illusory.
Morale will suffer. Management will become upset that the apparent progress has not been real and typically
attempt a variety of counter-productive measures such as requiring more frequent reports and adding new personnel
to meet a schedule.
Context
In the design of complex systems with many interacting parts, it is often the case that understanding how best to
“decompose” a problem cannot be determined ahead of time. Examples include complex software systems,
especially where the overall system includes human-human and human-computer interaction, new machinery, novel
nuclear power plant designs, complex military operations. In such a context, handing out separate “assignments” to
various individuals or small teams will at first seem to produce progress as each individual or small team carries out
their assignment. Unfortunately, when an attempt is made to compose or integrate these sub-solutions into an
overall solution, the result doesn‟t work because of unanticipated interactions.
For instance, suppose that a software development team is designing an integrated office support package.
Independently, various teams or individuals design various functions. Each of these may be well-designed in itself.
However, the combination will be flawed on at least three counts. First, numerous functions will have been
duplicated in separate modules. Second, some functionality that would have been useful for the whole package will
not have been implemented at all because it would have been too much work for any one team. Third, the user
experience will be scattered and inconsistent as separate designers make independent choices about what the user
experience will be. In addition, it is quite likely that hard bugs will also be in the design due to the inconsistent
treatment of data objects, deadlocks, infinite loops, etc.
There are two main general solutions common in the software development community. First, there may be an
attempt to set “ground rules” or “style guides” that everyone is supposed to follow. These will help ameliorate the
problem but cannot solve it entirely. Second, there may be overall project meetings where people report on progress
or even do mutual design reviews. Again, this helps but even if problems are found and resolved, the resolution will
require considerable rework.

Forces
* People are naturally gregarious.
* People can concentrate better on difficult mental tasks when it is quiet and when there are a minimum of
interruptions.
* Some problems are amenable to decomposition into relatively independent sub-problems; others are not.
* Social cues can be used as a guide to when to interrupt others.
* Having work-related shared artifacts that can be viewed and understood by others continually leads to
productivity.
* Shuffling work artifacts in and out of view in a small space takes time.
* Space costs money and is therefore limited.
* A group will tend to develop useful social conventions when they are co-located.
* Noticing and resolving conflicts among sub-solutions early will result in minimizing rework.
* Noticing common problems and solving them collectively as soon as possible will result in maximum efficiency.
* Human performance often shows a “social facilitation” effect; that is, people perform better in the presence of
others.
Solution
When small to medium sized teams work on non-decomposable problems, it is useful for them to be radically co-
located in one large room. This room should provide each person some private space and individual work tools
(e.g., a computer, a drawing table) as well as numerous spaces for public display of large scale work artifacts (e.g.,
designs, work plans, diagrams, decisions, group rules, etc.).

Examples:
In the Manhattan Project, people from all over the country were relocated to a relatively remote and isolated area.
There they had large workrooms to work on complex problems together.
Recently, automobile companies have empirically compared software work teams that were radically co-located
with traditional software development and found the former to be significantly more productive. Interestingly,
although before the experience, people thought that they would hate working in a single room, afterwards they said
they preferred it.
Resulting Context:
Prior to the experiments at the auto companies, developers were afraid that they would be too distracted by noise
and interruptions to get much work done. In fact, social cues can be read fairly well and a potential interrupter can
gauge the time to interrupt. In radical co-location, a person might have to wait minutes or hours to resolve an issue
by conversation and mutual problem solving. In traditional software development, they may have to wait for a
weekly meeting or not discover a problem until integration testing.
People working under conditions of radical co-location tend to develop common vocabulary and artifacts quickly
and can easily and efficiently refer to these artifacts. Motivationally, it is also easier to see where the individual‟s
work fits into the larger whole.
Rationale:
In a complex problem solving process, it is most efficient to solve the most difficult constraints first. Similarly, the
sooner potential design conflicts or potential design commonalities are discovered, the more efficient the global
optimization. Social groups that work together can rely on subtle cues about whether to interrupt or not. Being
alone in the office may seem more conducive to concentration but is still amenable to a knock on the door or a
phone call; in this case, the person interrupting generally does not know the state of concentration of the person
being interrupted. When we work separately, it is easy to imagine that others are “slacking off.” If we actually see
all of our colleagues working, it tends to motivate us to work harder as well.
Who Speaks for Wolf?

Problem: Problem solving or design that proceeds down the wrong path can be costly or impossible to correct later.
As the inconvenience and cost of a major change in direction mount, cognitive dissonance theory (Festinger, 1957)
makes it somewhat likely that the new information will be ignored or devalued so that continuance along the wrong
path is likely.
Context: Complex problems such as the construction of new social institutions or the design of complex interactive
systems require that a multitude of viewpoints be brought to bear. Unfortunately, this is all too often not the case.
One group builds a "solution" for another group without fully understanding the culture, the user needs, the extreme
cases, and so on. The result is often a "system" whether technical or social, that creates as many problems as it
solves.
The idea for this pattern comes from a Native American (Iroquois) story transcribed by Paula Underwood (1983).
In brief, the story goes as follows. The tribe had as one of its members, a man who took it upon himself to learn all
that he could about wolves. He became such an expert, that his fellow tribes-people called him “Wolf.” While Wolf
and several other braves were out on a long hunting expedition, it became clear to the tribe that they would have to
move to a new location. After various reconnaissance missions, a new site was selected and the tribe moved.
Shortly thereafter, it became clear that a mistake had been made. The new location was in the middle of the wolves‟
breeding ground. The wolves were threatening the children and stealing the drying meat. Now, the tribe was faced
with a hard decision. Should they move again? Should they post guards all day and night? Or, should they destroy
the wolves? And, did they even want to be the sort of people who would kill off another species for their own
convenience? At last it was decided they would move to yet another new location. But as was their custom, they also
asked themselves, “What did we learn from this? How can we prevent making such mistakes in the future.”
Someone said, “Well, if Wolf would have been at our first council meeting, he would have prevented this mistake.”
“True enough,” they all agreed. “Therefore, from now on, whenever we meet to make a decision, we shall ask
ourselves, „Who speaks for Wolf‟ to remind us that someone must be capable and delegated to bring to bear the
knowledge and interests of any missing stakeholders.”
Forces:
* Gaps in requirements are most cheaply repaired early in development; it is important for this and for reasons of
acceptance (as well as ethics!) by all parties that all stakeholders have a say throughout any development or change
process.
*Logistical difficulties make the representation of all stakeholder groups at every meeting difficult.

*A new social institution or design will be both better in quality and more easily accepted if all relevant parties have
input.
* Once a wrong path is chosen, both social forces and individual cognitive dissonance make it difficult to begin
over, change direction or retrace steps.

Solution: Provide automated reminders of stakeholders who are not present. These could be procedural (certain
Native Americans always ask, "Who Speaks for Wolf" to remind them) or visual or auditory with technological
support.
Examples: Some groups make it a practice to “check in” at the beginning of any meeting to see whether any group
members have an issue that they would like to have discussed. In “User Centered Design”, and “Contextual
Design” methodologies, an attempt is made to get input from the intended users of the system early on in the design
process.
Resulting Context: When every stake-holder‟s views are taken into account, the solution will be improved in
quality and in addition, there will be less resistance to implementing the solution.
Rationale: Much of the failure of "process re-engineering" can be attributed to the fact that "models" of the "is"
process were developed based on some executive's notion of how things were done rather than a study of how they
were actually done or asking the people who actually did the work how they were done. A "should be" process was
designed to be a more efficient version of the "is" process and then implementation was pushed down on workers.
However, since the original "is" model was not based on a very complete picture of reality, the "more efficient"
solution often left out vital elements. We hope that this type of mistake is not being remade in the field of
knowledge management, but fear that many such systems are attempts to provide a purely technological solution in
a situation that calls for a socio-technical approach (Thomas, Kellogg, and Erickson, 2001). In any complex human
endeavor, once a wrong path is initiated, it becomes progressively more difficult to change. For instance, in “A
behavioral analysis of the Hobbit-Orcs problem”, (Thomas, 1974), people found it difficult to solve a simple puzzle
when it appeared that they had to “undo” progress that has already been made. In more complex endeavors, not only
does individual cognitive dissonance make changing direction difficult. In addition, social and logistical factors
multiply the difficulties of changing paths.
Technological and sociological "imperialism" provide many additional examples where the input of all the
stakeholders is not taken into account. Of course, much of the history of the US government's treatment of the
Native Americans was an avoidance of truly including all the stakeholders. A challenge in applying the "Who
Speaks for Wolf" pattern is to judge honestly and correctly whether, indeed, someone does have the knowledge and
delegation to "speak for Wolf." If such a person is not present, we may do well to put off design or decision until
such a person, or better, "Wolf" can be present.
Known Uses: As a variant of this, a prototype creativity tool has been created. The idea is to have a "board of
directors" consisting of famous people. When you have a problem to solve, you are supposed to be reminded of, and
think about, how various people would approach this problem. Ask yourself, "What would Einstein have said?"
"How would Ghandi have approached this problem?" And so on. This prototype can be viewed at the following:
www.research.ibm.com/knowsoc/
In a previously published study (Desurvire & Thomas, 1993), Human Computer Interaction specialists, computer
programmers, and individuals with a background in neither field were asked to do a kind of “heuristic evaluation” of
a user interface design under one of two conditions. In one condition, they were simply asked to find as many
potential problems as possible and to suggest new features. In a second condition, they were successively asked to
try to find potential problems and suggest new features from various perspectives including a cognitive
psychologist, a behaviorist psychologist, an occupational therapist, a worried mother, and so on. Subjects in the
various conditions had equal amounts of time, but people whom were specifically asked to take different
perspectives, on average, found more actual usability problems and made a greater number of suggestions than those
who were not given the suggestion to look at the problem from these various perspectives.

Discussion. In the case of the tribal experience that gave rise to the story and subsequent heuristic pattern, “Who
Speaks for Wolf?” the people of the tribe knew every member of the tribe. That is, all the stakeholders were known,
even if all were not present. Furthermore, because of the nature of their culture, it was presumed that each person
would have to “live with” the consequences of every other person and their family and friends continuing to be a
part of that tribe. Thus, not only were all the stakeholders known, but every stakeholder was likely to remain a
stakeholder with continuing influence. Under these circumstances, everyone is wise to consider quite seriously the
concerns and perspectives of every other stakeholder, not only because greater overall wisdom will result, but also
because of future negative consequences that would occur if someone‟s concerns were not at least respectfully
considered. In many circumstances today, we live under more complex circumstances. During discussions at the
DIAC02 conference, it was brought up that we may not always know who all the relevant stakeholders are.
Furthermore, because of complex property rights and power relationships, some people may believe that some
stakeholders may be ignored without consequence. There are certainly many similar stories in today‟s complex
society wherein people really do want to include all relevant stakeholders but finding them can be challenging. The
following related patterns are meant to offer various suggestions relevant in such situations.
Related Patterns. Radical Co-location. (See above).
Advocates. In this pattern, rather than each individual being on the look-out for activities, changes, and situations
that may be highly relevant to their concerns (which would be extremely time consuming), a single person (or small
group) is charged with the task of understanding the concerns of a related group of individuals and making it their
business to watch the environment for situations in which this group should be considered as stakeholders.
Examples include public advocates, lobbyists, and activists.
Honey-pot. In this pattern, the systems designers, in order to attract the input of all relevant stakeholders, produce
an event, or a thing which has extremely wide appeal and wide publicity; e.g., a party, a fair, a website, a free gift.
Associated with this is an appeal for input from anyone who has an interest in doing so.
Exploring the Formal Organization. In this pattern, one finds a person or small group of people who know the
entire formal organization, or one uses a tool that displays the entire formal organization and then explores links to
any functions that may be relevant to the situation at hand, contacting those people whose job title, interests, or
function may relate. Not all of these will be stakeholders, but clusters who are stakeholders may be revealed with
minimal effort or disruption. For example, IBM has a world-wide directory called “Blue Pages” that allows one to
search not only by name, but also by job responsibility, project, expertise and interests. This still does not solve the
problem that you may not know or recognize the correct term to indicate an important relationship .
Exploring the Informal Organization via Chaining. Here, one begins with people one knows and asks them who
they know who would be most likely to be a stakeholder or know a stakeholder relevant to the situation you
describe. By working in this recursive fashion, one can connect to relevant stakeholders fairly quickly.
Gaming Scenarios. In this technique, one assigns separate known stakeholder roles to each of several people on the
project team. Each is given a different perspective to take and a different set of payoffs. They begin to “play”
through a scenario and begin negotiating requirements. In the process of doing this, however, people will be on the
look-out for “missing players.” Once people begin to confront a concrete (though imagined) reality, other
stakeholders who are not being represented become clear.
Hypothesized Anti-Hero. In writing good fiction, it is important, not just to have good heroes, but, perhaps even
more important to create interesting, powerful, and believable villains. It is natural in undertaking a project to think
of all the benefits of the project and to imagine ourselves as systems designers as the “heroes.” Step back and try to
imagine that there is someone completely opposed to the system you are designing. What would this person be like?
Try to avoid the temptation to imagine them as idiotic, misinformed, or evil (although that can also be a useful
exercise). Instead, try to imagine a smart, well-informed, good-intentioned person who is against the project. Why?
What is their perspective? What history led to their view?
Multiple Agents. Although so-called “intelligent agents” have not really reached the point where they exhibit
intelligence in the human sense, multiple agents can help remind people of sources of knowledge and viewpoints
that they might not have otherwise considered.

Public Notice. It might seem too obvious to mention, but of course, wherever feasible, projects whose implications
are widespread should be given public notice in appropriate forums; in some, but not all cases, this is a legal
requirement. However, the utility of public notice goes beyond the avoidance of a lawsuit. It can result in better
design.
Environment Change. Typically, a design is produced for a specific context. One way to test the robustness of
design is to imagine a change in the envisioned environment. As a part of that thought experiment, a new set of
stakeholders may come to mind as well. Some of these same stakeholders may well be relevant to the project as it
stands; they are simply more saliently relevant in the changed environment.
Extreme Characters. Just as stories typically portray the edges of human social and emotional experience, and for
that reason we find them fascinating and instructive, we also find extreme characters to be interesting.
Djajadinangrat, Gaver, and Frens (2000) from the Royal College of Art have been using a technique during design
of imagining some extreme but very different characters and then building scenarios for how those characters would
react to a design; how they might use it; what their concerns might be.
Similar Past Experience. Although it may well be the case that no-one on the design team has experience with
exactly the current set of circumstances, it may prove worthwhile to exchange stories of past design projects in
which there were forgotten stakeholders; how those stakeholders could have been found earlier. Then, the team can
reflect on how that knowledge might apply to the current situation.
Of course, designing any new socio-technical system is a difficult undertaking and none of the methods
expressed in these patterns can guarantee that all relevant stakeholders will be discovered ahead of time. Taken
together, however, we believe such methods have three important effects. First, the methods increase the chances of
finding previously undisclosed stakeholders. Second, the methods generally increase the sensitivity of the design
team to potential “side-effects” of their design. Third, such actions demonstrate a values-based design process and if
and when new stakeholders are found, negative reactions are more likely to be restricted to material concerns and
not include emotional negativity due to being ignored.
References:
Alexander, C., Ishikawa, S., Silverstein, M., Jacobson, M., Fiksdahl, I. And Agnel, S. (1977) A Pattern Language.
New York: Oxford University Press.
Alexander, C. The Timeless Way of Building. New York: Oxford University Press, 1979.
Bayle, E., Bellamy, R., Casaday, G., Erickson, T., Fincher, S., Grinter, B., Gross, B., Lehder, D., Marmolin, H.,
Potts, C., Skousen, G. & Thomas, J. (1997) Putting It All Together: Towards a Pattern Language for Interaction
Design. Summary Report of the CHI '97 Workshop. SIGCHI Bulletin. New York: ACM.
Carroll, J., Thomas, J., and Malhotra, A. 1979. A clinical-experimental analysis of design problem solving. Design
Studies, 1(2), 84-92.
Carroll, J., Thomas, J. and Malhotra. 1980. Presentation and representation in design problem solving. British
Journal of Psychology, 71(1), 143-155.
Collins, J. and Porras, J. 1994. Built to last. New York: Harper.
DeGeus, A. 1997. The living company: habits for survival in a turbulent business environment. Boston: Harvard
Business School Press,.
Desurvire, H. and Thomas, J. (1993). Enhancing the performance of interface evaluators using non-empirical
evaluation methods. Proceedings of the 37th Annual Meeting of the Human Factors and Ergonomics Society, 1132-
1136. Santa Monica, CA: Human Factors and Ergonomic Society.
DIAC '02, "SHAPING THE NETWORK SOCIETY: Patterns for Participation, Action, and Change". See
http://www.cpsr.org/conferences/diac02/
Djajadiningrat, J., Gaver, W., and Frens, J. (2000). Interaction re-labelling and extreme characters: Methods for
exploring aesthetic interaction. In Proceedings of DIS 2000, 66-71. New York: ACM Press.
Drucker, P. 1995. Managing in a time of great change. Truman Talley Books: New York.
Duncker, K. 1945. On problem solving. Psychological Monographs, 58:1-112.
Erickson, T. (2000) Lingua Francas for Design: Sacred Places and Pattern Languages. In the Proceedings of DIS
2000. New York: ACM Press, pp. 357-368.
Farnham, S. et. als. 2000. Structured online interactions: Improving the decision-making of small discussion groups.
Proceedings of CSCW 2000. pp. 299-308. New York: ACM.
Festinger, L. (1957) A theory of cognitive dissonance. New York: Harper.

Gamma, E., et al. Design Patterns: Elements of Reusable Object-Oriented Software, Addison-Wesley, Reading, MA,
1995.
Gordon, A. 2001. Playing chess with Machiavelli: Improving interactive entertainment with explicit strategies.
AAAI Spring Symposium, Stanford.
Landauer, T. The trouble with computers. Cambridge: MIT Press, 1995.
Lawrence, D. and Thomas, J. Social dynamics of storytelling: implications for story-base design. Presented at
AAAI workshop on Narrative Intelligence, Nov. 1999, N. Falmouth, MA.
Lawrence, P. and Nohria, N. (2002). Driven: How Human Nature Shapes our Choices. New York: Jossey Bass.
Lee, A., Danis, C., Miller, T., and Jung, Y. (2001) Fostering Social Interaction in Online Spaces. In Proceedings of
INTERACT, '01 (Tokyo, Japan, July 2001), IOS Press, 59-66.
Malhotra, A., Thomas, J., and Miller, L. 1980. Cognitive processes in design. International Journal of Man-
Machine Studies, 12, 119-140.
Mattimore, B. 1993. 99% Inspiration: Tips, tales, & techniques for liberating your business creativity. New York:
American Management Association.
Newell, A. and Simon, H. Human problem solving. Upper Saddle River, NJ: Prentice-Hall.
Olson, M. and Bly, S. 1991. The Portland experience: A report on a distributed research group. International
Journal of Man-Machine Studies, 34, 211-228.
Olson, G. and Olson, J. (2000) Distance matters, Human-Computer Interaction, 15, 2-3, 107-137.
Poltrock, S. and Englebeck, G. 1999. Requirements for a virtual collocation environment, Information and Software
Technology, 41(6), 331-339.
Sobel, D. 1995. Longitude: The true story of a lone genius who solved the greatest scientific problem of his time.
New York: Penguin.
Stein, M.1974. Stimulating creativity. New York: Academic Press.
Thomas, J. and Carroll, J. (1978). The Psychological Study of Design. Design Studies, 1(1), 5-11.
Thomas, J. Studies in office systems I: The effect of communication medium on person perception. Office Systems
Journal, 1(2), 75-88, 1983.
Thomas, J. and Kellogg, W. (1989). Minimizing Ecological Gaps in Interface Design. IEEE Software, pp. 78-86.
Thomas, J. (1996). The Long-Term Social Implications of New Information Technology. In R. Dholakia, N.
Mundorf, and N. Dholakia (Eds.), New Infotainment Technologies in the Home: Demand Side Perspectives.
Hillsdale, NJ: Erlbaum.
Thomas, J. 1974. An analysis of behavior in the hobbits-orcs problem. Cognitive Psychology, 6, 257-269.
Thomas, J., Lyon, D., and Miller, L. 1977. Aids for problem solving. IBM Research Report, RC-6468.
Thomas, J. and Carroll, J. 1978. The psychological study of design. Design Studies, 1(1), 5-11.
Thomas, J. 1989. Problem solving by human-machine interaction. In K. Gilhooly (Ed.) Human and machine
problem solving. London: Plenum.
Thomas, J.C. 1999. Narrative Technology and the New Millennium. Knowledge Management 2(9):14-17.
Turner, M. 1996. The Literary Mind. New York: Oxford University Press.
Thomas, J. (2001). An HCI Agenda for the Next Millennium: Emergent Global Intelligence. In R. Earnshaw, R.
Guedj, A. Van Dam and J. Vince (Eds.), Frontiers of Human-Centered Computing, Online Communities, and
Virtual environments. London: Springer.
Thomas, J., Kellogg, W.A. and Erickson, T. (2001). The Knowledge Management Puzzle: Human and Social
Factors in Knowledge Management. The IBM Systems Journal, 40(4).
Underwood, P. (1983). Who speaks for Wolf: A Native American Learning Story. Georgetown TX (now San
Anselmo, CA): A Tribe of Two Press.
Underwood, Paula (1999). Three strands in the braid: A guide for learning enablers. San Anselmo, CA: A Tribe
of Two Press.
Vlissides, Coplien, Kerth, eds. Pattern Languages of Program Design 2, Addison-Wesley, Reading, MA, 1996.

4 Potential Applications

4.1 [Click here and type Heading 2]
[Click here and type text]

4.1.1 [Click here and type Heading 3]

4.1.2 [Click here and type Heading 3]

[Click here and type first-level bulleted list]
[Click here and type second-level bulleted list]
[Click here and type second-level bulleted list]
[Click here and type first-level bulleted list]

References

HCII 2005 paper

More Related Content

Similar to HCII 2005 paper (20)

More from John Thomas (20)

Recently uploaded (20)

HCII 2005 paper