Published: Apr 28, 2010
The history of social interface design can be divided into two periods: Before Flickr and after Flickr. In the first period, any social interface functionality was added as an afterthought to the design—something to layer on top of the core functionality. In the after Flickr period, teams were now considering social components as core to their design's value.
This was most evident in Flickr's home market: photo web sites. Before Flickr, the major players in that market, including Photoworks and Ofoto (which would soon become Kodak's site), were about picture printing and services. Users would upload their digital images to create high quality prints. While these sites had the capability to share photos with friends and family members, the functionality was obviously not part of the designs' core, making it clumsy and frustrating to use.
The Flickr team's approach to design put sharing in the center of the design. Every aspect of the design had a social approach baked in.
For example, the site's business model had sharing at its core. Once hooked, users could remove bandwidth limitations, increase their storage, and keep their pictures longer by paying a small monthly fee.
Their central focus on sharing showed in the smallest of details, such as defaulting any uploaded pictures to being public. Of course, users could override this setting, but the default meant it was easy to explore the latest uploads of other users.
Early on, you could designate contacts—people whose images you wanted to follow. Users typing in the www.flickr.com URL immediately saw their contacts' latest contributions, making it easy to track what was happening.
These social features were integral to how Flickr's users experienced the site. Unlike its contemporaries, the features were all baked right in. The integrated social aspect spoke to its users, making Flickr a huge success story.
Incorporating these social features into the design wasn't easy for the Flickr team. They had no models to go by. No other site had created an experience like this, so there was nothing to emulate or reflect on. They were truly making it up as they went along.
Fortunately, the founders had assembled an exceptionally bright and ambitious team. They pushed out frequent design changes, often multiple times per day, trying to hone in on the best methods to solve the big problems.
Today's teams don't need to be pioneers; at least, not when it comes to integrating social interfaces into the design. Flickr's success subsequently inspired many designers, who have riffed and innovated on the original concepts. Now, we have many examples to go by.
In fact, we have so many examples, both good and bad, that it's hard to keep track of them. That's why we were excited when Christian Crumlish and Erin Malone released their new book, Designing Social Interfaces. Weighing in at more than 400 pages, it's a comprehensive pattern library of all the current trends in social interface design. We think it's a must-have resource for anybody designing an application that has social components, which is to say, any application.
Christian and Erin have tirelessly studied dozens of sites with social components. They carefully organized and categorized each type of component, giving us interesting perspectives on different ways to tackle the same concept. The results are a beautifully described set of patterns, chock-full of interesting examples, along with a nice commentary on many different approaches to solving common problems.
How would a design team use a resource like Designing Social Interfaces? Well, let's pretend we're on a team. We're creating a new system to help our organization's employees take advantage of their health insurance benefits. We want the employees and their family members to have full access to their benefits, recommend their favorite local health providers, and share ideas for staying fit and healthy. (After all, healthy employees reduce insurance costs and keep our organization productive.)
For this hypothetical project, we could use Designing Social Interfaces to help us explore the social components we might want to have. By perusing the sections of the book, we can generate ideas for our design.
Generate New Ideas
For example, we know we'll need to have accounts, so we'll need to explore the types of data associated with the accounts. We'll want employees to add their family members into the system, so that means we'll need an invitation capability. We want users to contribute and share ideas for local services and events. We'd like to have users rate the various services and events, to help others learn what's popular.
Explore Specific Options
A good pattern library helps us by giving us a jumping off point. Looking through Christian and Erin's book, we can quickly see areas we'd like to explore for the design. We can look at specific features and ask ourselves, "Would this pattern help us make our users' experience better?"
For example, we can explore the different patterns for sharing, which includes both private sharing and public sharing. We might choose private sharing if we felt the information would be something the user would want to control (such as specifics about doctors or test results). On the other hand, we might think about public sharing for healthy recipes or exercising ideas. The book goes into the pros and cons of each, helping us decide when each is most appropriate.
Discovering Interactions Between Elements
Like all good pattern libraries, Christian and Erin's includes related patterns as part of the pattern descriptions. These details help us understand what else we need to explore.
For example, we might want a discussion forum where our users can ask and resolve questions they have about their insurance coverage, medical procedures, and healthy lifestyles. Because of the depth of the pattern library, we can quickly assess what's involved in implementing the forum, with the necessary components of moderation and "Flag as inappropriate" functionality.
Identify the Subtleties
We'd love our users to indicate how they feel about various services or events posted on our site. However, there are many options: we can use a simple thumbs up/down indicator. We can have them assign a star-based rating. We can have them provide a detailed review.
Christian and Erin have done a fabulous job of describing the subtle implications of choosing one of these solutions over the other. Exploring these nuances will help ensure we pick the right solution that best meets our users needs.
I think Christian and Erin have given us a wonderful gift with their work. Teams that start with their book will have a huge jump on baking the social components into the design.
Public patterns, such as these, help us get the details right, so that we meet the expectations that users bring with them. This speeds the development process and lets the team focus on those parts where innovation pays off—the core functionality that provides the real value.
Have you been employing social components in your design? Where did you find your inspiration? Share your thoughts at the UIE Brain Sparks blog. We'd love to hear from you.
Read related articles: