Thursday, July 5, 2007

Social Software: Common Issues and Pitfalls Of Social Media Tools

Common Pitfalls of Building Social Web Applications and How to Avoid Them

by Joshua Porter

In the last several years we've seen the rise and fall of many social web applications. While most of our attention gets paid to the hugely successful ones like YouTube and Facebook, we can also learn a lot from those that have failed. Here are some of the common pitfalls that lead to failure when building social web applications.

1) Underestimating The Cold Start Problem

If you build and release your social web site and nobody uses it, you have the cold start problem. This problem affects most social sites, and directly results from designing for the network. The effect of the network is that nodes on the network (web sites) have attention momentum. We pay attention to certain nodes (sites) already, and so if you're trying to add one to the network then you have to build your own attention momentum over time. This is not easy.

Too often, though, this hurdle is underestimated. The first step is to admit there's a problem. Say "This is not working. Our early users are not using the site how we want them to". You would be surprised at how often this doesn't happen. Instead, what often happens is that more money is pushed into features or marketing, which is precisely the wrong move.

Strong social sites build value one user at a time. If one user finds value, then they're much more likely to tell others or invite their friends. Strong sites don't succeed by attracting "markets", satisfying entire groups of people with a certain feature set. Instead, they succeed on a smaller level, really focusing on individuals and their immediate social network. Then they can branch outward. One strategy in particular is to design for your friends, get the system working well for them, and then release it to a broader audience.

2) Focusing on Too Many Things

I got this email in my inbox the other day from a well-meaning entrepreneur who was building a new social web site:

"(our site) aims to combine the best elements of Digg, Del.icio.us and StumbleUpon, as a mechanism of social discovery and personal expression - but with the unique element of real-time."

I get so many of these it's not funny. This is a clear case of focusing on too many things. If you can't describe what your site does with a single, clear idea then you're trying to do too much. In addition, a comparison to other sites in this way is a bad idea, because they've already beat you. They already have a strong brand while you have a weak one.

The ease of adding social features makes overload likely. Development frameworks make adding friends, tags, profiles, blogs, or a host of other social features much easier than it was even a couple years ago. This is the opposite to a barrier to entry, where the hard part is building something at all. Instead, the ease of adding social features is a barrier to focus. If you have every feature under the sun you're probably not focused as well as you could be.

So focus on one thing that isn't being addressed. It can't be something like "the unique element of real-time". It has to be something inherently valuable, like a common frustrating activity. Nail that one thing to the ground, and show people how you do that one thing better than anybody else.

Think of the most successful social sites out there. They usually focus on a single thing. YouTube (video), Netflix (movies), eBay (auctions), MySpace (friends), Flickr (photos), Del.icio.us (bookmarks) and most of the social features on those sites are aimed at making that one activity better. These are just the giants. There are many more niches that are successfully designed for that are even more focused. Threadless focuses on t-shirts. Last.fm on music. etc...

3) Lack of Sustained Execution

What makes Google so terrifying to their competitors is that they never stop getting better. They're executing each and every day to make their software the best it can be. For example, in September of last year they did the unthinkable: they completely killed off the interface paradigm of a solid, growing product: their Google Reader software. But they replaced it with an even better interface that was universally acclaimed.

It's too easy to fall into the desktop software mindset of build, release, and wait for the next cycle. But with social software, you don't have the opportunity to stop improving. Your community is always growing and changing and so your management has to as well. There will always be things to do, screens to improve, questions to answer, and wording to tweak, support docs to update.

This can seem daunting, but I think it's mostly about mindset. If you see it as a sustained problem, then it will be one. If you see it as an opportunity for continual improvement, your outlook will be more positive.

4) Pointing the Finger when Missteps Happen

When you mess up on a social web app, as you undoubtedly will, you have to come completely clean or your users will smell your fear and hate you for it. Social sites are not typical software...they ebb and flow depending on the community and how it evolves over time. You, as the manager of a community, must act accordingly.

Consider the recent Digg dustup in which the Digg community pushed back on the site after they tried to remove a certain DVD-cracking code from user-submitted entries. At first, Digg tried to explain the situation away by saying they were legally obligated to as the result of a cease-and-desist letter. The basic message was "our hands are tied".

But then the Digg community overwhelmed the site and got the DVD crack code up anyway. The failure of Digg management to stand up for their users initially resulted in the user's aggregate behavior. Digg didn't lose out, however, as this community passion provided an opportunity for them to ride the wave, so to speak, reversing their course and standing up to the cease-and-desist. Their apology letter and reversal suggests they quickly realized that pointing the finger wasn't the right course. Only by accepting responsibility for their user base could Digg keep their respect.

Here's a template for how to say you're sorry.

5) Not Appointing a Full-time Community Manager

No matter how prescient your designers and how well thought out your design strategy, there is no way to design a perfect social web site that doesn't need ongoing management. Yet, some social start-ups fail to recognize this and launch their app without a designated caretaker. The result is a slow failure... the worst kind of failure because it's not immediately apparent that it's happening.

In any decent social app, use and users are always changing, always adapting and pushing the limits of your software. So as Matt Haughey, founder of Metafilter, says in his excellent Community Tips for 2007, "Moderation is a full-time job".

The success of many social start-ups proves this to be true. Flickr co-founder Stewart Butterfield, when asked about making online communities work, admitted there is no silver bullet, but added:

"A lot of our success came from George (Oates), the lead designer, and Caterina (Fake). Both of them spent a lot of time in the early days greeting individual users as they came in, encouraging them and leaving comments on their photos. There was a lot of dialogue between the people who were developing Flickr and their users to get feedback on how they wanted Flickr to develop. That interaction made the initial community very strong and then that seed was there for new people who joined to make the community experience strong for them too."

Stewart's description is exactly how George described it to me when I met her at SXSW. She could not over-emphasize the value of her and Caterina spending so much time with users... 24 hours a day greeting them, showing them how to use Flickr, and generally saying "Hi". It was clear to her that a huge part of the early success of Flickr resulted from that personal attention, that personal connection that someone on the other end cares about what's going on. A full-time community manager is crucial to providing this level of attention.

6) Not Building Archived Knowledge

When your social app begins to grow and you start to attract more and more new people to the fold, you begin to see trends in their initial confrontation with the software. The same issues crop up repeatedly. People have the same problems over and over again and the community manager spends more and more time answering the same questions.

For example, uploading that first batch of photos might be intimidating for those folks who have never done it before. Let's imagine they all run into the same problem: how do you get photos out of iPhoto and into your Flickr account? There are certain steps to do this, but it is not entirely clear, especially if you've never had to export pictures out of iPhoto before.

It's the community manager's role to help people at this stage. They'll chat and email with the person to help them along. But their role should also include figuring out when archiving common problems will make a big difference to a large group of users. If the process of exporting from iPhoto is archived at a URL, then the community manager only has to point people to the brand new "exporting from iPhoto" page instead of explaining it over and over again.

One strategy to avoid repeating the same things over and over again is to use these interactions to feed a FAQ or a user's guide. Whenever you start to see trends in help, add it to your FAQ and add a section to the user's guide. This will allow the community manager to focus on the latest, more unique problems without having to rehash older issues again and again.

This seems pretty obvious now that we've talked about a general case. But it's not so obvious when you're in the heat of battle and these issues are cropping up unstructured for the first time. The secret is to observe patterns in the questions people ask but also in the underlying cause of the questions while leaving enough design time dedicated to creating a healthy set of resources that can serve future users.

7) An Over-Focus on Social Value

This may sound counter-intuitive, but it is possible to focus too much on social value when creating social web applications. Why is that? Well, because much of the motivation within social sites is actually rooted in personal value, or answering the question: "what's in it for me?". I've dubbed this the Del.icio.us Lesson because it was Del.icio.us who gained so much attention for the social value of tagging but it was really the personal value of saving bookmarks that drove the site.

At the beginning, when you're building the service, is not the time to focus on social value. There is no social value because there is no user base. So adding tags in the hopes that people will discover new things is probably premature at this stage, for example. Instead, focus on how a single person can use your service even if others don't share or tag anything.

Think about YouTube, a killer social app. Even at the very beginning YouTube was providing personal value: hosting your videos for free. If they had been charging for this feature, no social design in the world could have caused the growth that free video hosting did. So while YouTube excels at getting viral growth out of the sharing of videos, they're providing a valuable, personal service at the same time.

It should also be noted that altruistic people, or people who do things for the good of the group regardless of personal benefit, are incredibly rare. They're so rare, in fact, that they make a very poor population to design for. There just aren't enough of them to make up a significant population in any area. Even Wikipedians, who have been called altruistic at times, are mostly driven by reputation...the reputation they gain from their peers and other Wikipedians.

Original article by Joshua Porter published on June 2007 as "Common Pitfalls of Building Social Web Applications and How to Avoid Them" - Part I and Part II" on Bokardo.

About the author

Joshua Porter is the editor of Bokardo, a site about social web design. He is currently the Director of Web Development at User Interface Engineering, a behavioral research company based in North Andover, Massachusetts. There he conducts world-class research on how people actually use web sites and products. He also holds the annual User Interface Conference, one of the most successful design conferences in the industry.

Photo credits

Scissors: Marc Dietrich
Pointing fingers: David Franklin
Painting: kameel4u
Pointing finger: Tan Kian Khoon
Community manager: Dimitrije Paunovic
Books: Ryan Pike
Hands circle: Pavel Losevsky