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 itthat's for surebut 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).
Human-centered approaches to industrial and interaction design have long focused on studying human behavior to create informed and appropriate designs. 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.
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.1the first massively successful social tools to clearly get something rightbut 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 interfacesoften 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.
As products become more interactive, the focus shifts to the psychological. And with the networking of devices together, we see yet another shiftthis 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.
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 objectsquestions 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 shiftthis 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.
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.
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:
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?
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.
Of course, these are the same sorts of questions any ethnographer asksin 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.
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 studythe kind that produces a book several inches thickmight 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.)
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.)
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?
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.
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 itselfnothing 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.
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 startedit launches with this articleso 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.