You're now watching the second interview with Tom Erickson. Tom is an interaction designer
and researcher. He's working for IBM in the Watson Lab in New York. Here, he's working in
the social computing group, and he's been working here since 1997. Before that, he worked for Apple
for nine years. So, he is an expert on social computing, and today he'll share with us some
of his advice on how we can apply this knowledge when we're designing social computing systems.
So, Tom, can you give us your three favorite pieces
of advice when we're designing social computing systems?
It's always hard to give advice in the abstract, right? So, I guess my first piece of advice
is to find similar situations in the face-to-face world and look very closely at them.
Try to see what social mechanisms are making that system, making that interaction work.
Then you ask yourself, are there ways in which I can
either reproduce those or create analogs to them, or if I can't do that, to compensate for them?
For example,
one type of thing that you often see happening in the face-to-face world is
people are having an interaction, and people who are not part of it are passing by,
notice it, and they get curious. They approach, hear a little bit more about it, and get drawn in.
Clearly, for a lot of the social computing systems we're designing, we'd like that, right? That's how
you make a system sustainable; it brings in new people. So, you might ask, okay, well,
what can I do in this system to help draw people in from the outside? You might not be able to
have the analog of situating the system in a place where other people are naturally coming along—that
might not make sense in the online world. So, you think about, well, what are ways that
fragments of the interaction or things it does can attract other people and pull them in?
Wikipedia is a good example of that. Now that it's become so popular, if you search for anything on
Google, very often very high in the search results will be the Wikipedia article. So,
that self-reinforces Wikipedia; it pulls new people into it.
Okay, so that's one piece. You wanted three pieces of advice.
Yes, please.
Okay, so the second two pieces of advice will contradict one another.
The second piece of advice is to try to deeply understand whatever you're designing for yourself.
Try to understand the experience. If you found a real-world counterpart,
try to go there and be part of that face-to-face interaction. See which bits of it feel
interesting, frightening, provoke your curiosity, or put you off or scare you—just whatever. Try to
really experience it yourself. I'm a very big believer in drawing on one's own experience. So,
that's piece of advice number two. There are a lot of ways you can do that. One is
actually going into the environment and having the experience firsthand. But if you can't do that,
it means talking with lots of people who have that experience and trying
deeply to understand them. It's sort of doing ethnography on a one-to-one basis,
but trying to get the feel for what it's like to be inside that interaction.
Okay, so that's piece of advice number two. Number three is don't rely solely on your own intuition.
Instead, I guess what I like to say is, if you know enough to design something, you know too much
to understand how ordinary people are going to experience it,
which directly contradicts what I just said. But
I just think people also—maybe advice number four is to be comfortable with contradictions. Anyway,
as a designer, you can never really understand how others will experience your system because,
as a designer, you know the entire system. You have the picture; you've got the architecture
in your mind. Somebody new coming into it will only see the little bit they first encounter.
So, what is your advice on how designers can find out what the users experience?
You build the system and put it out there. That's by far the best way. Again,
I'm an advocate of getting things out into public as soon as possible.
What do you consider the three biggest mistakes when
designers understand social computing systems?
I'm not sure it applies just to social computing systems. I think the biggest mistake is being too
immersed in your own idea. You often see people who design something essentially for themselves
and never even imagine that other people might not like it or would want to use it very differently
than they would or use it for different purposes. A second mistake, which is related
to that first one, although I think you can avoid the first one and still fall into the second one,
is as designers, we always have an image of how we believe people will use a system. We think
people will use this to make friends with strangers
or use this set of cues to let you know that people are paying attention when you're speaking.
In fact, sometimes people will do that, but other times they won't. The mistake I see is that people
often project what they imagine the use will be into the language and constructs of the system.
Let me see if I can give an example. In the Babble system, Babble was the multi-channel chat system
where you could enter a chat room and have textual conversations with other people.
In addition, it had what we called the social proxy or the cookie, which was
a visualization that had a small circle and dots. When you logged onto the system,
your dot would show up inside the circle. When you typed a bit, your dot would move into the center.
What we imagined is that when you were having an active conversation,
the dots, because people were typing or clicking or scrolling, everything would
move into the center, and people would feel like they were in a conversation. That indeed happened.
But we also saw some other interesting things. One of the points here is we tried very hard when we
gave help about the system, when we instructed the system, to make it clear that when the dot moved
in, all it really meant was that somebody was typing on their keyboard or moving their mouse. It
was a great temptation to say when the dot moves in, it means somebody is paying attention to you.
In fact, we saw cases where either people would say something, and
I'm not paying attention, but to be polite, I'd hit my space key to move my dot in. So,
I was pretending to pay attention, which you can also do in real life.
Yes, I mean, one of my design principles for social computing
is that you should always allow people to lie. But the real point is to always allow people to
be polite, which sometimes means saying things that you don't believe. At times, when we would
talk to engineers about Babble and talk about the dots moving in whenever you type, somebody would
say, "Wouldn't it be great if you could put EEGs on people's heads and just tell if they're paying
attention and then move the dot in?" My answer is no, that's actually not a good idea because
you want to give people the ability to pretend to pay attention as a way of exhibiting politeness,
even if they're really bored. That's how we manage our social relationships.
So, I'm just nodding now; I'm not listening at all.
Not true. Do you have any other kind of big mistakes we should avoid?
I think the only other one is not trying a system out on strangers who don't care about it.
Developers will very often use the system in the development group, and of course,
everybody in the development group really cares about it. But you really need to get the system
into the hands of people who don't give a damn about you or your system. They just have some ends
that they want to pursue. It might be for fun; it might be for business. But they're not trying
to be helpful to you. They don't care about you. That's the most powerful kind of test you can do.
It's also a hard one because, certainly, in the environment I work in, in the enterprise,
if you give it to a bunch of people who don't care about you, it means they're using it for
real things. If the system crashes, they're going to be mad; it's going to screw things up for them.
If the system works and you try to take it away, they're going to be mad too.
On one hand, it's a great thing to do. On the other hand, when you do it, you're making a lot
of promises, at least implicit promises, about stability—that this is going to be stable enough
so you can really do your work, and we're not going to yank it away from you in six weeks. That
requires a lot of commitment, both from you and from your organization. So, that makes it hard.
Thank you, Tom, for passing on your advice and for sharing some of your guidelines,
as well as knowledge, perspectives, and best practices. It's been wonderful. If
you want to know more about social computing, you should have a look at
the chapter Tom has written. You can find it, of course, at interactiondesign.org.
You can also find other interesting chapters and videos as well. Thanks for watching.