Boundary objects - Design for Collaboration

The first time I heard about boundary objects was at the Oslo School of Architecture and Design. Bridgeable, a Canadian service design consultancy, was invited to talk about their work with the New York City Transit. One of the things that got stuck with me was their view of a designer as a diplomat. Especially this quote:

I have somehow always strived to avoid conflict, thinking that conflicts are bad for collaboration. That it's a show-stopper for innovation and efficiency. To look at conflict as a necessary precursor for change was an eye-opener for me.
But what can a designer bring to this conflicted table?
You probably guessed it, boundary objects!

What is a boundary object?

Boundary objects were first introduced by Susan Leigh Star and James Griesemer in 1989, writing an article analyzing the formation of the Museum of Vertebrate Zoology in Berkeley. A project where various actors had to cooperate, despite having different and often conflicting interests. The museum director, its primary patron, university administrators, and amateur collectors. Everyone with different concerns about the museum. It is here Star and Griesmer found that certain objects helped in the collaboration despite the differences. Star and Griesmer initially defined boundary objects as:

"Objects which are both plastic enough to adapt to local needs and constraints of the several parties employing them, yet robust enough to maintain a common identity across sites...They have different meanings in different social worlds but their structure is common enough to more than one world to make them recognizable, a means of translation. The creation and management of boundary objects is a key in developing and maintaining coherence across intersecting social worlds."*

Yep.. classic academic language…but what does it mean?

I'm going to explain my understanding of boundary objects, but it might help to have some common boundary objects for designers in mind before reading the next part. E.g. user journey maps, prototypes, flow charts, blueprints, giga-maps, or whatever design you have presented outside your team.

It has to be an object

A boundary object needs to exist outside your, or other people's head. A map of Oslo is a boundary object. It exists and functions on its own, it's not someone's personal opinion. A conversation, on the other hand, is not a boundary object. It is something that exists inside the heads of the people conversing. There is no guarantee that they have the same conception or that they are imagining the same thing.

Plastic enough to adapt

It's something each actor involved can use according to their needs. A tourist will use the map of Oslo to find sights, a taxi driver will use it to find the best road from a to b. An architect will use it to plan the next opera house.

Robust enough to maintain a common identity

It's something people can’t argue with. It is based on facts or accepted truths. It should be looked at as logical and realistic. The tourist and the taxi driver can disagree about the best way to get from a to b. But the map as a boundary object is the same for both of them. A tool to understand each other even though they are disagreeing.

A means of translation between intersecting social worlds

Intersecting social worlds could for instance be the IT departments world and the law departments world. Two worlds with very different perspectives on problem-solving. In the case of a boundary object, people from both these worlds should be able to understand the object without a lot of explanation or reading pages of documentation.

A boundary object that failed

I got this from a colleague on Slack the other day.

"I had an a-ha moment about boundary objects last week when doing a workshop with a neighboring team. We are trying to collaborate with them, but have struggled for a while to understand each other. Then it suddenly hit me! They don't have any boundary objects. They have a very beautiful prototype with a lot of interesting new functionality, but the developers don't understand what to do with it. The product owner can't find a logical connection with the available data at hand..."

In this case, they have what seems to be a boundary object, a prototype. The problem here seems to be that the prototype is not robust enough to qualify as a boundary object. It's not based on "accepted truths" since the product owner does not find a logical connection with the data at hand. It's not convincing enough to be used as a base for collaboration.

If the taxi driver was given a map with roads that did not exist, he or she would never accept it as a tool to decide the best way to get from a to b.

Finishing notes

This is the first time I write about my understanding of boundary objects, and I'm no expert. If you have any comments I would love to get feedback.

Some key takeaways:

• Conflict is a necessary precursor of change. Our aim is not to eliminate conflict, but to understand it, channeling it into creative and productive action.
• If you use boundary objects to collaborate, make sure that they qualify as boundary objects. Especially if you feel that they're not working as expected.

-----------------

• * Star, Susan; Griesemer, James (1989). "Institutional Ecology, 'Translations' and Boundary Objects: Amateurs and Professionals in Berkeley's Museum of Vertebrate Zoology, 1907-39" (PDF). Social Studies of Science. 19 (3): 387–420.
• A field guide to boundary objects
• Prototyping and Boundary Objects by Matt Cooper-Wright