A new web discipline: Social Functionality Design

I’ve been thinking a lot recently about what makes a website social, and how different types of social functionality could fit together to create a satisfying experience for the people who use the website. Partly this is because I’m working closely with a Canadian publishing start-up called Book Oven to do just that – design their social functionality. We are still at the very early stages of website development, with a very small pre-alpha test going on at the moment which should lead into a fuller-featured alpha in the next few months.

What is interesting and, to my mind admirable too, is that they started thinking holistically about the social aspects of the site from the very beginning, so that sociability is built right into its fabric, rather than being treated as a bolt-on afterwards. So often I see otherwise promising sites fail to reach their potential because they’ve simply tacked on some forums, and maybe a half-baked messaging system, and leave their social functionality at that. Communities will still form, but they miss out on lots of interaction that could otherwise really enrich the user’s experience.

So what sort of things are we thinking through when we’re considering social functionality design? My first focus was to think about the social objects around which people might want to communicate, and what implications that would have for different modes of communication. Obviously, members’ activities (and I’m being deliberately vague about what they are for now!) are one set of social objects, but so are the members themselves, so the tools have to allow people to aggregate conversations around each object separately – I don’t just want one big bucket with all the conversations in, but will need to have multiple ways to slice and dice the conversation so that it makes sense for me at that moment, in that context.

I have also been considering the way in which people develop relationships with each other, and the effect that the architecture of the site may have on the way people build trust. This is all intimately related to privacy gradients, understanding the way that people can move through a site, and what access to different areas of the site signifies. People have different ways of forming relationships online. Some like to watch and learn what someone is like from observation, others jump straight into conversation, and yet others will plunge into intimate relationships at what might seem like an alarming speed! How does the site design facilitate (or hinder) these behaviour patterns?

And what about people’s motivations for using the site? Why will they visit us? What will they want to do there? How will they do it? Understanding the different ways that people may wish to interact with the site and each other is essential to understanding how to structure it, and it’s not just about traditional information architecture or user experience, but also about understanding the possible influences of human cognitive biases.

Once we start looking more deeply at people’s motivations, the dark side of human nature reveals itself, and we have to consider conflict resolution. The community can do a lot to self-police, if you give them the tools to do so, but there is always a need to understand what the worst case scenario might be. What you could do to prevent your site or tool being used by one user as a big stick to beat another user with? My personal feeling here is that the site should remain as neutral as possible, and let users sort out their problems off-site, but there are design and functionality implications even in that solution that should not be ignored.

And then there’s reputation management. Hierarchies emerge in all communities – it’s human nature to rank oneself against one’s peers, and to rank them against each other. How explicit does one make reputational tools? How could the reputation system be gamed? And how do you keep people honest? After all, whenever there is a reputation system, us humans do so love to game it.

I think there’s a new web discipline here, that of Social Functionality Design, that should sit alongside User Experience, Accessibility, and Information Architecture as key issues that website and application designers need to understand and apply. People are getting much more sophisticated in the way that they use the internet and their expectations of the social experience of being online are getting more and more nuanced. It’s just not enough anymore to only have forums or a messaging system.

When I look at the web, I am constantly disappointed that sites I love and use regularly seem to have put so little thought into just how their members are going to interact. Supporting sociability isn’t optional anymore. Sites need to think very hard about what they are doing and how, and they need to crack this nut sooner rather than later, because otherwise they are leaving their lunch out for someone else to eat.

4 thoughts on “A new web discipline: Social Functionality Design

  1. Suw, good thinking here!

    I think this is also closely allied to having to design the actual social graph / dynamic social network structure according to its desired functions.

    I also think the whole arena of fitting the relevant Network design to the desired UE is another emerging area that needs lots more study – we are only beginning to understand how the choice of assymetry vs symmetry, real time vs persistent etc changes the dynamic of the social net, and influences that way transactions over social objects occur.

  2. well, firstly it’s been great fun working with you suw, and it’s exciting to have this kind of thoughtfulness brought to bear on a project.

    my experience with LibriVox was really interesting in this context: since we started with a wacky idea (an open source audiobook project) with no money, we cobbled together cheap available tools slowly as the project grew. with 25 members and 5 projects we were just using a wordpress blog, by 250 members and 25 projects we were on a phpBB forum, then we added a wiki … but it wasn’t until more than a year into the project, by which time we were running some 300 projects at a time, an publishing 5-10 books a week that we introduced anything except off the shelf software.

    we built a custom project management/catalog software to handle our workflow.

    the reason this is interesting is that we had defined the practical & social mechanisms by which we got things done *before* we built any software … so the software did, more or less, exactly what we needed it to do. it has it’s quirks, but it was built based on established workflows, with the express purpose of relieving the particular pain points of our process.

    often it seems that software is built before its understood where the pain point are, and without understanding the social ramifications of change … which has huge impact on the ability to get things done.

    all that to say: i’m all for this new discipline of: social function design.

  3. Pingback: louise ventris » Blog Archive » links for 2009-01-13

Comments are closed.