Gravity7: Social Interaction Design SxD By Adrian Chan

Reading Notes: Social Systems and Niklas Luhmann
The complete pdf is available here

• Double contingency is a fact of meaning, and the domain in which social software must be situated is a meaning-based domain: each individual must come to understand what others’ communication and action means. This fundamental point seems to have eluded a lot of what I find in the literature on social software. Authors, designers, and critics alike tend to view meaning-based events such as communication, transactions, exchanges, and interactions as straight-ahead and straight-up phenomena. What happens on one side (with one user) happens equally on the other (Other user). As Luhmann points out—and he’s only drawing on the hermeneutic foundation of contemporary sociology; this is not his own invention—each actor’s interpretation is implicated in the Other’s actions and vice versa. This double contingency throws a wrench the works of any simplistic views of social systems.
• It is easy to confuse terms here: social system as Luhmann uses it is an application of systems theory to societal systems. It is not a “technical system.” As we’re many of us designers and engineers, we have to keep this in mind, if we’re to use Luhmann’s approach.
• Luhmann’s modification of communication theory is brilliant. He notes that we need to ask whether society comes out of communication or action, and ultimately, he combines both by integrating action theory into communication theory. His steps are this: that communication first involves understanding (each actor must understand what is said); this creates the possibility of a yes/no response. It is the response that integrates action into communication, and which furthers the interaction, thus creating and limiting further communication/action.
• Luhmann’s distinction between communication and action leads to a distinction between communication and interaction. The meaning, and the process of understanding meaning, is distinct from the production of a linguistic utterance. This is critical in my approach because I view most of these social software systems as talk systems. The production of talk (e.g. speech in the form of text) should be viewed as communication; the handling of talk, and speaking (IM’ing, emailing) actors should be viewed as interaction. Each sets up its own needs. The distinction is powerful in that it provides ground on which to separate communication tools and interaction tools, along with the necessary design and use constraints belonging to each.
• Ambiguity, which naturally accompanies any conversation or speech situation, is exacerbated in talk systems or social software systems by the intervention of technology itself. Not only the technical design and interface but also the user practices built around it substantially impact users’ means of going forward with communication and interaction. In talk systems, software facilitates (even while it puts its own stamp on) these linguistic and interactional proceedings. Now we can proceed to describe the user competencies required of a social software system. In other words, standard HCI and human factors stuff, as well as sociological, linguistic, and interactional stuff.
• I’ve been wanting to ground social interaction design in practices, rather than in design, cognitive science-based user analysis and modeling, or engineering. My claim that practices are first and foremost social and sociological works only if I can show that all social software is embedded in social practice. These practices assimilate technical solutions—they are not determined by them. We never leave the social domain.