When one designs social software, they are forced to make pseudo-governmental decisions about how the contained ecosystem will behave. Examples of these decisions include limits on friending behavior, limits on how information in a profile can be displayed, and how access to information is restricted in the ecosystem. These rules create and inform the structural aspects of the ecosystem, causing participants in the ecosystem to behave a specific way.
The practice of software development, and particularly design considerations in software development, have changed drastically over the last decade. Whereas the imperative in software design used to be task-solving and efficiency, we now design software that amuses, entertains, and connects people – all the while wasting as much time as possible. Indeed, the paradigm has shifted – but have the assumptions we take into the design process changed?
To further this point, lets explore how social software has changed over the last decade. A core assumption in the early social literature was that an individual would take on a persona when they used social software. For example, one was supposed to create a new identity when they joined a MUD or MOO – there was a discrete line between the person and the persona. However, today’s social software is about continuous identity – the idea that my online persona effectively and willingly enmeshes with my offline persona. Facebook, Myspace, LinkedIN – all of these extremely popular service deal in real identity, not constructed identity.
In that sense, the social software that we use becomes an augmentative part of our lives. We use Facebook to connect with classmates and find out about events. We go see a band because we’ve experienced their work previously on their Myspace page. Our real social worlds are mediated through social software – and in doing so, they are picking up the structural rules that the designers of social software have built into the system.
Let’s look at an illustrative example. In the Facebook, users can enforce strict rules on who can see their information. For example, if a user has high privacy settings and announces a party on the Facebook, only those in her privacy network will be able to see the party invitation. This is quite different from if she announced her party to the class, or posted a flyer in her department, where friends and non-friends could get the information. In this context, there is a very clear interaction between the enforced rules in the social technology and our societal context.
We can look at this situation in two ways. The first viewpoint is that the social network delivered social value to the party-thrower because it denied access to information to non-friends. Rather than having to risk embarrassment by selectively not inviting people to her party, the user displaced the social context onto the social network, and relied on the structural aspects of the social networks to enforce her will. The second viewpoint is that the social network reduced social value to the party-thrower because it excluded access to non-participants and prevented invitation of non-friends who might better the party. Indeed, the social network has enforced her will, but it has also limited her opportunity.
As we use social software more, and social software more neatly integrates with our lives, a greater portion of our social rules will come to be enforced by the will of software designers. Of course, this isn’t new – when we elected to use email, we agree to buy into the social consequences of email. Perhaps because we are so used to making tradeoffs when we adopt social technology, we don’t notice them anymore. However, as social technology adopts a greater role in mediating our social experience, it will become very important to take a critical perspective in analyzing how the will of designers change us.
Two things got me thinking about this. First was a post on the O’Reilly Radar blog about homophily in social software. Homophily is the phenomenon where we associate with like individuals because we share like experience. As homophily is largely a social construct associated with mobility, the web can “break” homophily because there are very few barriers to mobility on the net. The author proposes that designers must think as homophily as either a feature or a bug – something to be destroyed.
Second is a recent discussion I was part of. In the discussion, I asked two senior executives at social networking websites how they incorporate feedback from their users. The first executive outlined a number of careful steps regarding how they used and integrated user feedback. The second executive stated that they didn’t pay attention to feedback because users don’t know what they want. Obviously, there isn’t a right or wrong here, but there is a mentality that causes these types of judgments.
The dichotomy of the responses illustrated two perspectives on social software design. The first is the cultural adaptive process, one in while designers of the social system design to their ecosystem. danah boyd covers this process in an article about Glocation and Web 2.0. The second perspective is none less than colonialist – users don’t know better, therefore the social system must enforce a strict and top-down perspective. Therefore, the decision to break or retain homophily is colonialist – and illustrative of the many like decisions designers make each day when constructing social software.
It might be simple to rationalize that designers of social software adopt a colonialist perspective because they do feel “better” than their users. Software developers are an interesting set of the technical population – and often times they do have a “know better” mentality. This mentality informs the perspective, but I don’t feel it is the prime reason for the mentality. The simple fact is it is easier to adopt the colonialist mentality. When social software is designed, it is much easier to take the internal logic that informs the designers perspective and operationalize that in the software. It isn’t so much that users don’t know what they need, it is that designers don’t know what users don’t know they need. Therefore, it is much simpler to hope that the community conforms to the structure the designers have put in place.
It is this process that leads to breaches of community like the Facebook Feeds. This is a particularly telling example, as the designers of the software enforced the will of their CEO onto the general population. This will is Mark Zuckerberg’s libertarian view of the world (that information flow is a societal equalizer). However, this will was not shared by the population of the Facebook, who reacted strongly to having new social rules enforced from the de-facto oligarch of the society.
As social technology becomes a larger augmentative part of our social experience, we must look critically at how the will of the designers are shaping our lives. We will take social expectations from our experience in social software – social software will change us just like any other change agent. That social software has tremendous potential to affect our experience makes this all the more important.
As we are connected by this new technology, there are new rules, contexts and structures that will inform our social experience. It is important, therefore, that designers realize this – that they realize the role their technology plays in mediating real social relationships.
