Designing for Groups
Designing for groups will become a primary survival technique in our networked world… I was recently setting up a chat session with someone and the inevitable question came up: what chat service to use? You want to chat on Skype?, I was asked. Or iChat? Do you have an GTalk handle? The answer was a […]
Designing for groups will become a primary survival technique in our networked world…
I was recently setting up a chat session with someone and the inevitable question came up: what chat service to use? You want to chat on Skype?, I was asked. Or iChat? Do you have an GTalk handle?
The answer was a group decision. We went back and forth for a minute and chose Skype.
So the question becomes: how can Skype or other chat software help us make that decision? This is part of the design…just getting people to use the thing. Are there group affordances that they could put in place that would make the choice easier? Are there certain features that appeal to groups? Are there things that an individual might not notice that a group would?
We’ve hit a point (at least here in the states), where people are becoming comfortable enough with software so that the biggest problems aren’t really usability problems. People can get around software pretty well. Once they decide to use it, they can muddle through and get things done.
How many pieces of software will be built this year without attracting an audience? How many millions of dollars did Walmart spend on their already-failed MySpace competitor? How many millions of dollars did Google spend on their video product that couldn’t catch up to YouTube? How many millions of dollars will be spent trying to build web-based office software? And the funny thing is, this software might not be half bad. But people’s attention was elsewhere.
The biggest problems in design are not code validation problems. Nor are they visual design problems. Nor interaction design problems. (although these are all very real, important problems)
No, the biggest barrier in the networked world is convincing groups of people, not just individuals, simply to use (or even try!) your software. The design needs to convince people to use it. Or, more likely, the design needs the users it has to sell it to others.
The issues: Persuasion. Motivation. Social Life. Sharing. Group Effects. All that arises when people get together, form groups, and behave differently than when they’re alone. Our group decision about which chat program to use is different than the one I would make myself (I would use iChat). And all the brainstorming in the world can’t predict what people do when they’re in groups. Hell, I don’t even know why we chose Skype…we just did.
Banks now need to consider how families, not just individual bank members, use their online account software. Amazon needs to consider what happens when people shop for other family members and want to keep it private. Or make it public. Facebook needs to consider how their features affect individual and group privacy. Netflix now has a multiple queues features whereby people in the same family can each have their own. I can hide bookmarks in Del.icio.us (I’m not hiding them from myself). I can share photos with friends on Flickr. I can invite people to collaborate on Writely. I can video chat with three people in iChat.
Gone are the days of traditional usability testing. Almost all testing assumes that 1) people want to use your software and 2) people use your software alone. Each of these things is becoming less true every day. There’s so much software! A much bigger problem, at this point in time, is how to get people and the social groups of which they are a part interested and keep them interested in your software.
You’re not convincing just one person, you’re convincing one person and all their friends.