The prototyping process takes projects through full iterative cycles.

The first step of the process is to understand target users. Who are they, what are their goals, and how are they currently using technologies to meet their goals. A broad range of methods may be used to collect user data, including ethnographic and quantitative studies conducted online, in the laboratory, the mall, urban environments, parks, and the home. It is important to cast a wide net in user studies because people use social technologies very differently depending on factors such as their personality characteristics, their life stage, and their culture.

One may also perform more experimental studies designed to more rigorously address specific questions. One such example is a study of Xbox users, wherein (Riegelsberg et al ????) experimentally manipulated the presence of profile text, voice, or photos to explore whether these profile features would prove meaningful in helping people find gaming partners. They found that photos provided the most discriminating information for users in helping them chose partners, but only for socially oriented gamers. One of the more difficult challenges in experimental, laboratory research is the sheer cost in studying multi-user systems. The best approach is to answer questions through online questionnaire studies or through rapid prototyping and deployment.

We then engage in the design process for our prototypes. We first brainstorm new projects, drawing inspiration from our knowledge as social scientists, but also what we observe in our target users, what we observe in the research community, in the wilds of the Internet, and on the cutting edge of art and design. We track new, emerging technologies with the idea of exploiting their new affordances, and we turn to the product groups to find out what are their current hard problems.

We then develop user scenarios, sketch out user interface (UI) mockups, and create Photoshop and Director prototypes, always ideally with a particular research question or social goal strongly in mind. We perform UI working sessions where we are our own worst critics. At this time we sometimes seek out user feedback on paper or screen shot mock ups. At this phase of the cycle we decide whether it is worth the commitment to continue with a project. It is not uncommon that we feel we have learned all that we needed by thinking it through, or that the potential lessons learned are too incremental for the investment required to carry it through to the next step.

At the design phase, we pay much more attention to the look and feel of the socially-oriented applications than the more task-oriented applications. Much as lighting might impact a person’s expectations about how to behave at a social gathering (low, frenetic lighting at a dance party, and soft, candle lighting at a romantic dinner), the design of social software impacts expectations about who is expected to use it and how they are expected use it. One might have more saturated colors and a busy user interface for a younger population seeking to socialize with friends, but muted colors with a simpler user interface for an older population in a social support community.

The next step is to rapidly prototype our applications. When developing our prototypes we prioritize both using the application ourselves and deploying the application to test users as quickly as possible. A lot of the more obvious flaws or lessons to be learned can be done through our own use or through the observation of a small number of users. Given the nature of social software, we cannot even begin to assess problems and successes of the prototype until two or more people are using the system to interact with each other. We then perform larger scale deployments that allow us to study specific research questions and to explore the emergent social behaviors that occur in our social systems. In contrast to much of HCI research, where the unit of analysis is one person interacting with one computer system, for much of Social Computing the unit of analysis is dyads, groups, communities, and social networks. We often find in our deployments that certain behaviors do not emerge in a system until it is occupied by a large number of users. When we deployed Wallop, for example, it was not until we had over a thousand users that we began to encounter certain bad behaviors in the system, and had to rethink some of our solutions to managing such behaviors. In addition, it is only through large scale deployments that we can begin to understand the differences that occur due to personality, life stage, or cultural differences.

When assessing our prototypes, we systematically evaluate the success of the application through user studies, questionnaire responses, and through analyses of user behavioral data. Our measures of success are distinct from measures of success in other fields, depending on the user goals we are trying to support. CSCW, for example, tends to measure success for collaboration in terms of successful task completion in a timely manner. For our Social Computing projects we measure success more in terms of emotional responses to the system and the users’ subjective assessment of whether the projects helps them meet their social goals. For example, in a study of shared browsing (Farnham, Zaner, & Cheng, 2001) found people reported the most satisfaction when they had a synchronized shared screen, rather than asynchronized screens, though they reported it was harder coordinate web browsing tasks. We measure other subjective variables such as sense of fun, a sense of social presence (that the other person feels very real and close), and group cohesion. We also explore usage statistics such as return rates, conversational thread depth, and longevity to develop more indirect measures of community health and user liking.

References

Farnham, S., Zaner, M., Cheng, L. (2001). Designing for Sociability in Shared Browsers. In Proceedings of Interact 2001, Tokyo, July, 2001.