Core77

T-shirt by Simon Crowley

Depending on how you see it, social software is either all the rage or so 2008. You know the stuff: Facebook, MySpace, Twitter, YouTube, Flickr, Foursquare.... There's no talking about the web these days without it—that's for sure—but social software tools are quickly becoming an integral part of the way we run our day-to-day lives.

It's not just in the consumer space, either. Companies and large organizations are catching on to the benefits of social networking and improved collaboration tools. They want their intranets to be more like Facebook. They want to use crowdsourcing to leverage employee perspectives and wikis to help people help themselves. They want Twitter for the organization, (or at least they think they do).

So there's a lot of budding social software out there, and a lot of opportunity to design the stuff. But for all of the press and fanfare, most social software is, well, socially awkward.

Take, for example, the satirized look at Facebook by the British improv troupe Idiots of Ants above. Idiots of Ants (the pun only emerges if you say that name with a British accent) pushes the social behaviors of Facebook to the extreme, but it's hardly the only piece of software they could pick on. Twitter, another massively successful tool, began as an attempt to facilitate text messaging among friends and has morphed into a platform for broad, ad-hoc real-time communication. But while the tool is great for flash mob conversations and celebrity tracking, the one-channel-for-everyone design is profoundly awkward for more nuanced social interaction.

A Different Kind of Design
To be fair, we're in the early days of social software. Facebook and Twitter are the modern-day equivalent of Windows 3.1—the first massively successful social tools to clearly get something right—but few people would argue that they are mature.

Today we take our operating system for granted, but that wasn't always the case. Between those early days of Unix, DOS, and Windows, and the operating systems of today, there has been a long process of maturation. Collectively, as a body of interface designers and interface users, we developed a set of shared expectations about how the desktop GUI should work. And while today's offerings by Apple and Microsoft differ in many ways, they are much more alike one another than either of them are like Windows 3.

By contrast, social software is pretty far from mature, and much of what people are trying to do with these tools has never been done before. In most cases there are no well-established rules for interfaces—often there are no precedents at all. That's exciting because there is ample opportunity to produce something truly new. But these challenges come with new constraints, and require different skills than those employed traditionally in software design.

Software that Works on Multiple Levels
With social software, the design of intuitive, usable, or visually pleasing interfaces is not enough. Though a bit of a simplification, we might describe early software as being primarily about data manipulation: the Mac OS is used to manage applications, Microsoft Word helps write documents, and Adobe Photoshop modifies photos, for example. These are tools in which the user manipulates information within the world of the computer. But in the arena of social software, the computer is primarily a medium facilitating human-to-human interaction. The software supports, or enables, interpersonal collaboration and communication at scales or complexities not otherwise possible.

This increase in complexity is something that Bill Moggridge talks about in Designing Interactions. His hierarchy of design complexity provides us with a nice way of making sense of this shift in design focus and its consequences for the design process:

For Moggridge, interaction design is simplest in the arena of standalone products and artifacts. Here the designer is tasked with the questions of how people best interact with these physical objects—questions of anthropometrics. As products become more interactive (through the advent of software interfaces), the focus shifts to the psychological: human-computer-interaction emerges as an application of cognitive science. And with the networking of devices together, we see yet another shift—this time towards the sociological and anthropological. Now the designer must understand not only anthropometrics and cognitive science, but also ethnography and sociology, for an effective design must 'work' at all of these levels at once.

From this perspective, it isn't difficult to see where most social software falls short: many tools have pleasant, user-friendly interfaces and take advantage of well-designed physical devices (i.e., they're easy to use from a human-computer-interaction perspective). But it's in the sociological and anthropological arenas where they run into trouble: most social software tools are clumsy and ineffective at smoothly facilitating interpersonal interaction.

Social Interaction Design
Designing software for human-human interaction, then, is about more than user-friendly interfaces. Does the system encourage or facilitate appropriate behaviors from its users? Does it 'speak' using appropriate cultural language and social gestures? How do its target users want to interact with one another in the first place?

These are not questions that most social software today answers effectively. How many of your friends on Facebook do you actually consider friends? What does it mean to poke someone? Twitter begins with the question "What are you doing?" but most of the worthwhile tweets don't answer it. And why can't I put my Twitter followers into groups? If given the choice I might say one thing to my (true) friends and another to colleagues and coworkers...but the tool forces the lowest common denominator.

At IDEO we've started using the term "social interaction design" to describe the work of creating tools for both human-computer and human-human-interaction. At the very least, that means the work requires designers or design teams that understand as much about ethnographic methods as they do about information architecture and interface design. But merely adding an anthropologist to a design team to tackle a social software problem isn't enough. Though similar in many ways to more traditional forms of interaction design, the work is unique enough that it has forced us to look at many of our own design processes and adapt them for these new challenges. Here are some of the ways social interaction design is different:

From user-centered to users-centered
Human-centered approaches to industrial and interaction design have long focused on studying human behavior to create informed and appropriate designs. In product-centric contexts, human factors specialists pay close attention to human-artifact interaction and look for opportunities for improvement.

With social software, the object of study is less tangible. A social interaction designer must consider not only people, environment, and existing tools, but also the unseen elements of the system such as social relationships, power dynamics, and cultural rules. Who are the stakeholders in the system and what do each of them want or need? How does information flow and where are the friction points? What does it feel like to be a part of this particular culture?

Of course, these are the same sorts of questions any ethnographer asks—in that sense they are nothing new. But the intensity required to gain this kind of understanding, both in terms of time and level of immersion, is substantially greater than in the more tangible and direct forms of user study. There's a reason most anthropologists spend months to years in the field producing an ethnography: this is complex, time-consuming stuff. Design projects tasked with creating social software should expect to spend the majority of their time in situ with whatever community or organization the tool is meant to serve.

From design-by-principle to ethnography-by-prototype
Human-centered design often begins with a "human factors" research phase that culminates in synthesized concept frameworks and a set of design principles. This is essentially a compressed form of traditional ethnography where understanding is distilled down to key insights. From this clarified perspective the design team then builds a series of prototypes which may be taken into the field for further feedback.

When designing social software, that process requires some adaptation. Because of the complexities that come with understanding a cultural system, a set of design principles simply can't contain enough information to drive effective design on its own. A comprehensive ethnographic study—the kind that produces a book several inches thick—might make an ideal first step, but in practice no one will ever have the time to conduct one.

The best alternative, we've found, is to blend the human factors and prototyping phases through iterative cycles of creating and evaluating software concepts. As early as possible, the team creates rough concepts of a solution and uses them to guide conversations and explorations of the social system they're trying to serve. Conversations about the concepts highlight weaknesses, the concepts are modified accordingly, and the process is repeated. Again, and again, and again.

At one level this seems mundane and obvious, but at another it is profound: what the designer or team is doing is conducting their research in the language of interface. This is ethnography without words. By creating concepts as early as possible and using them to both express and evaluate their understanding, the design team is taking the most direct route they can toward the construction of a socially effective solution.

In practicality, what this means for the designer is that a combination of traditional anthropological and interaction design skills are essential. Throughout the design process the work requires fluency both in the language of interface and the methods of ethnographic research. Such a combination is rare find in a single designer. When the task is left to the team, they will need to be sure to work closely together, involving both skill sets in every step along the way.

From design engagement to a design dialogue
The iterative prototyping process is always a dialogue between the social interaction designer and the social system for which the software is being designed. This process of refinement doesn't end with the software's launch, however. In fact, the launch of social software is really just part of an ongoing design process.

This is a fact that has become almost a given in the internet age. No longer required to reserve new versions for software boxes, today's developers are free to improve their software constantly.

This agile approach to software development, and design, is especially important for the social variety, however, because the human-human interactions the tool is meant to facilitate are themselves subject to change. Social interactions are inherently dynamic. Organizations and communities evolve over time, and the best tools grow accordingly.

And then there are the effects of the software itself: good social software will facilitate and encourage social interactions that were previously difficult, or indeed impossible. Thus the very act of creating the tools may profoundly alter the system that that tool was meant for. The tool changes the community changes the tool.

Unfortunately, the terms of many design engagements aren't set up to support the ongoing work that is actually needed, and in real life the process is often cut short. This is not only bad news for the designer, but for the organization or community the designer is meant to help as well: without this ongoing, iterative design dialog, the value of even the best solutions will wane dramatically over time. (For a great article about this, check out The Agency Problem by Joshua Porter.)

From anthropologist to armchair psychologist
Okay, so maybe this is about playing both an anthropologist and an armchair psychologist, but social interaction design requires taking all that learning about a particular community or organization and augmenting it with a sensitivity towards the more general peculiarities of human nature. Perhaps using this as a short-cut to effective systems, social interaction design can rely upon the knowledge that many aspects of human behavior are consistent across cultural settings.

For instance, altruism and anonymity seldom go hand in hand. Social software should either reward individual participation or publicize the non-compliant (we prefer the first option). People tend to resist change, particularly to their own personal habits and workflow, so how can a system minimize change by integrating into what users already do? Where change is mandatory, how can the transition be made as smooth as possible? And good design often leverages the path of least resistance; most users stick with the default choices. How can you use this to the benefit of the user and the social system at the same time? (Recommended reading: Nudge by Richard Thaler and Cass Sunstein.)

Through a Social Interaction Design Lens
The best way to get a feel for the kinds of issues a social interaction designer wrestles with is to look critically at some real-world examples of social software. Of course, due to the dynamic nature of the medium, both the examples and the landscape around them change quickly, and by the time you read this, the systems below may already be significantly different. But with this caveat, here are a few cases that seem worth a look:

Bragster
If only there were a website where I could be cajoled into screaming out "This is Sparta!" in public or drinking an entire bottle of maple syrup. Well now there is. Bragster, a decidedly juvenile spin on social software, is also a remarkable example of thoughtful social interaction design. Users create dares which they offer to the community. Others upload video responses to those dares and compete for "bragging rights" (points). The value of a particular dare, and of each response, is entirely determined by the community. And from these simple rules emerges the most outlandish, audacious, and (in some cases) nauseating feats of human capability.

Nearly everything about Bragster differs from the kinds of social software needed by a 'typical' organization, yet we can still learn quite a bit from it. Bragster has not only attracted a community, but through a simple set of rules they encourage some truly extravagant acts of participation. Compare getting someone to drink a bottle of maple syrup to, say, asking them to regularly fill out a time card, and you see where I'm going. How is participation rewarded in your (or your client's) organization?

Aardvark
Aardvark (or Vark, as it is commonly known), is an impressive attempt to solve a problem that many other organizations have tried to tame. In the lineage of Google Answers and Yahoo Answers, Aardvark attempts to create a network of experts that can be called upon at a moment's notice to answer questions about anything and everything.

Like those who came before it, Aardvark relies heavily on people's enjoyment of being recognized for their expertise. What makes the system stand out, however, is the way it integrates into existing workflows. Aardvark requires no new applications to download, and no website to remember to visit. Instead, questions come to you over IM, SMS, twitter, or email. If Vark thinks you know the answer to a question, the system finds you and politely asks you if you can be bothered.

Even with the remarkable integration into existing workflows, Aardvark still faces some significant challenges. While the novelty of answering strangers' requests carries early interaction well, that novelty fades quickly. How can my participation over time help me build reputation and respect in the community? And then there's the question of how expertise is defined: quantifying and organizing knowledge is extremely tricky but essential to automatically matching experts with incoming questions. Simple text-based word matching is rarely enough, and so far Vark's matching abilities are primitive at best. This much more complicated social (and epistemological) problem will have to be solved before Vark can become a killer app.

Google Wave
Google should be commended for never shying away from the hard problems, and Wave, its most recent buzz-generating undertaking, sets for itself an ambitious goal: to replace email—a decidedly limited medium for group collaboration—with a synchronous and asynchronous media-rich communications platform.

It's still early for Wave, but the tool has a long way to go before it replaces email. Though most people agree it's a limited collaboration medium, replacing email is one of those problems that are the social equivalent of NP-hard: in order to move away from email, everyone that you email has to move away too. And to get those people to make the move, you're going to have to provide an experience at least as easy and reliable as the medium they're familiar with.

For starters, Wave needs to take a note from Vark and find you. Right now there doesn't seem to be any way to know if a wave has been updated without going to the site itself—nothing is 'calling me back' to my browser to continue the conversation, and most of the time when I visit no one else is around.

But even that may not be enough. Can you 'wave' with your cell phone? Catch up on a backlog of waves on the airplane? Email may indeed be broken as a collaboration tool, but it's going to take more than a slick AJAX interface and a handful of content widgets to fix it.

A Work in Progress
From an historical perspective, we are still in the early days of social interaction design. How can we, collectively, create vastly better social software for communities and society at large? What techniques have you found to be particularly useful? What key points have I left out?

If you've read this far, I invite you to join me in continuing the discussion at http://socialsoftware.org, where we can flush out a better understanding of the emerging techniques and processes of social interaction design. The site is just getting started—it launches with this article—so it will be up to us to generate meaningful content there. But I would appreciate it if you would pay it a visit and help get the conversation going. Thanks, and I look forward to meeting you.

Gentry Underwood focuses on social media and collaborative software at IDEO. He works both internally and with the firm's clients to design and build software people will actually use.