[IP] Group as User: Flaming and the Design of Social Software
Begin forwarded message:
From: Monty Solomon <monty@xxxxxxxxxx>
Date: November 5, 2004 4:12:38 PM EST
To: undisclosed-recipient: ;
Subject: Group as User: Flaming and the Design of Social Software
http://shirky.com/writings/group_user.html
Group as User: Flaming and the Design of Social Software
Clay Shirky
November 5, 2004
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.
There is enormous value to be gotten in closing that gap, and it
doesn't require complicated new tools. It just requires new ways of
looking at old problems. Indeed, much of the most important work in
social software has been technically simple but socially complex.
...
http://shirky.com/writings/group_user.html
-------------------------------------
You are subscribed as roessler@xxxxxxxxxxxxxxxxxx
To manage your subscription, go to
http://v2.listbox.com/member/?listname=ip
Archives at: http://www.interesting-people.org/archives/interesting-people/