“If only they would know what we know!…”

Developers should learn how to design user interfaces and everyone should learn how to code: The cry for a better education of others in ones own field is frequent: If they only knew what we know, the world would be better and collaboration would be smooth.

The difficulties to collaborate are assumed to be caused by the lack of shared knowledge. Thus, at least one of the sides of the collaboration needs to learn how to see things like the other side in order to collaborate better.

Let's take an example from my profession, the creation of easy-to-use, task-appropriate interfaces for computer programms, in short, User Experience Design or “UX”. A frequent complaint by software developers is that designers ideas do not consider the way developers can translate the ideas into code. The answer to this problem is often that designers should learn more about how developers code or at least that designers should use tools that are as close as possible to the code of developers. Vice-versa, designers also wish for developers to know more about design, for example to avoid being asked if some change in code is really necessary, hope that, if developers would know the methods guiding their design suggestions, they would accept them as necessary.

Such educational efforts need a lot of resources: It must be made clear that the other discipline really, really needs to learn these things, although the “other” might be pretty content with not knowing about them at the moment. If only they would know: Case studies are created to argue for the point, academic research is cited, conferences are held, maturity levels and certifications are employed; incentives to improve along the suggested maturity and to start new fields of work.

But if no field is educated in how the others works, don't we need some translation? This is a common strategy and it is by no means wrong, but even translation is not necessarily needed. People can collaborate without being part of the culture of the collaboration partners and do not need to have to the same values, practices or even vocabulary.

Two concepts that show how collaborations can work without one discipline teaching the other to be more like them are trading zones and boundary objects ⁴.

Trading zones are created when two different disciplines need to work together by creating local means of communicating with each other. For extended and close collaboration this means that a pidgin-like work language is created. Peter Galison developed the concept in research on how engineers and physicists needed to work together in war-time efforts to create the radar and likens their collaboration to the collaboration of different groups of people that, despite their cultural differences, trade goods with each other: “Two groups can agree on rules of exchange even if they ascribe utterly different significance to the objects being exchanged; they may even disagree on the meaning of the exchange process itself Nonetheless, the trading partners can hammer out a local coordination despite vast global difference” ². Both disciplines communicate in this language and translate back to their discipline specific languages (instead of one discipline translating in the other’s language).

Boundary objects are things that are used and valued by different groups, yet in potentially very different ways: “Boundary objects are objects which are both plastic enough to adapt to local needs and the constraints of the several parties employing them, yet robust enough to maintain common identity across sites.” ⁵ In my work in UX design, a typical boundary object is an interface wirefame. Both developers, designers and managers use it to communicate with each other and in their discipline-specific work, but in different ways: Where designers might see interface standards and user needs, developers might see widget libraries and API functions called. Star and Griesemer suggest four different types (and potentially more) of boundary objects (examples are partly taken from their paper):

• Repositories (of objects classified in a standard way),
• Ideal types (that represent something in a usefully limited way, like a map or and user interface wireframe),
• Coincident boundaries (where the boundaries of a metaphorical container coincide for the different parties, but not necessarily what it contains, e.g. “the project”, or “the state of California”)
• Standardized forms (often, a literal form-to-fill-out, or a template that different parties use. In IT, user stories are often created in this way)

Both trading zones and boundary objects suggest that collaboration does not need to be achieved through homogenization. Instead, they focus on local collaboration without the need of formally educating or reshaping one of the sides (which does not mean that both are power-free modes of exchange per se!)

The strength of these collaborations can be their non-alignment and the needed iteration. Particularly because there is no direct transfer of unchanged knowledge, the mutual learning leads to new insights. “It is the disorder of the scientific community—the laminated, finite, partially independent strata supporting one another; it is the dis unification of science— the intercalation of different patterns of argument—that is responsible for its strength and coherence” writes Galison ².

In my design and IT-focused examples, designers might learn how to structure their designs for large scale systems, as learned from developer’s use of central styles and principles, but reinterpret it in the light of their concern for consistency for users. Similarly, interpretation of designer’s needs might lead to developers inventing systems component libraries, font systems or style sheets as developer-interpretations of designer’s needs.

Thus, I am critical of e.g. the idea that design tools should allow design to be isomorphic to code representations: the style of working in code is different than working in design and attempting to make it the same (but with a visual interface) abandons a lot of the affordances that are unique for design, like direct manipulation and immediate feedback; Same goes for the attempts to introduce some sort of version control for designs, in which the state of text-based files are tracked. The several-files-with-different-names in a folder might be amusing (“haha, they lack a system like git!”), but allow quick work with different parallel versions of a design, not to mention that developer’s version control systems are made for line-based, plain-text languages and thus do not only fail to work well with visual data of designers but also anything that is not line-based and plain-text ³.

The idea that designer’s work should be more programmer-like can seen as advocating for a particular a way to see the worlds as through particular abstractions, typical for computing ¹, as well as simply as a power-move to ease life for developers; in either case it ignores the usefully diverse work practices between developers and designer opting for a simple tight-coupling via same-ness over a loose coupling via differences.

Notes:

• Related: “On violating the standards of one’s occupation ”, “Logo Competitions in Open Source Software Projects ” cover related topics.