[Cross-posted to my professional blog, The Farm]
Clay Shirky has a great
article titled Group as User:
Flaming and the Design of Social Software
in which he says that one of the misconceptions of designers of social
software is that they see the “user” of a piece of social software is
not a collection of individuals, but a group:
When we hear the word “software,” most of us think of things like
Word, Powerpoint, or Photoshop, tools for individual users. These
tools treat the computer as a box, a self-contained environment in
which the user does things. Much of the current literature and
practice of software design — feature requirements, UI design,
usability testing — targets the individual user, functioning in
isolation.
And yet, when we poll users about what they actually do with their
computers, some form of social interaction always tops the list —
conversation, collaboration, playing games, and so on. The practice of
software design is shot through with computer-as-box assumptions,
while our actual behavior is closer to computer-as-door, treating the
device as an entrance to a social space.
We have grown quite adept at designing interfaces and interactions
between computers and machines, but our social tools — the software
the users actually use most often — remain badly misfit to their
task.
Social interactions are far more complex and unpredictable than
human/computer interaction, and that unpredictability defeats classic
user-centric design. As a result, tools used daily by tens of millions
are either ignored as design challenges, or treated as if the only
possible site of improvement is the user-to-tool interface.
The design gap between
computer-as-box and computer-as-door
persists because of a diminished conception of the user. The user of a
piece of social software is not just a collection of individuals, but
a group. Individual users take on roles that only make sense in
groups: leader, follower, peacemaker, process nazi, and so on. There
are also behaviors that can only occur in groups, from consensus
building to social climbing. And yet, despite these obvious
differences between personal and social behaviors, we have very little
design practice that treats the group as an entity to be designed for.
A related entry: Joel on Social
Software.