Defining Requirements for Social Web Applications – Part 2: The Framework

This is the 2nd post in a series on Defining Requirements for Social Web Applications. Click on the following links to access previous post in this series:

• Part 1: An Introduction

Introduction

This post will present a general approach for defining requirements for Social Web applications. As with the other posts in this series, the content is largely borrowed from Joshua Porter‘s book Designing for the Social Web. Porter’s book is a gem, and if the topic of social web design is of interest to you, I highly recommend you pick up a copy.

The single most important factor in specifying requirements for any product or application is to focus on how your users will use the application. This includes both the core use cases (or user scenarios), as well as the key requirements for user interaction.

Chapter 2 of Porter’s book introduces a framework for Social Web Design. He starts out by emphasizing the importance of staying focused on the “core” use cases for the social application, and being careful to avoid scope creep, and saddling your application with a whack of non-essential features. This involves prioritizing the overall feature list, and focusing on the essentials.

The AOF Method

Porter provides a very nice framework for identifying core social application requirements which he calls the AOF method, where AOF stands for Activities, Objects, and Features.

The AOF Method is comprised of 3 key steps:

1. Focus on the primary Activity

– The first question you must answer is what is your audience doing?

2. Identify your social Objects

– Once you’ve got the activity down, you have to identify the objects that people interact with while doing that activity.

3. Choose your Feature set

– From the activity and objects you can derive a core feature set, answering the question: What are the actions people perform on the objects, and which are important enough to support in the web application?

Focus on the Core Activities

Porter communicates that a common refrain when doing requirements analysis is “know your users?” He points out, however, that more important that knowing all about the people who will be using a social application is having a deep understanding of the specific activities that the solution will enable.

Actually, Porter advocates focusing on a “single” core activity – for example, with Amazon, it might be “shopping for books”, with Flickr it’s photo sharing, and so on. But I’m going to allow for some leeway here, and allow for a small set of core activities that the site might support.

Once you’ve defined your small set of core activities, you should focus deeping on the tasks your users will take to succeed in accomplishing these activities.
Quoting Porter:

We should know all the steps taken in performing the activity, the decisions people need to make at each step, the influencing factors in those decisions, and what types of roles people are in when making them.

Goals, Tasks, and Activities

Porter writes:

It’s helpful to distinguish between goals, activities, and tasks. Goals are end conditions people are striving for. Activities are the set of tasks people do to achieve their goals.

Many times we focus too much on tasks instead of the larger activity. Instead of focusing on the task of “purchasing goods”, it is more beneficial for design purposes to focus on the activity of shopping, as it better describes what’s really going on.

Thinking on the level of activities allows us to focus on both the details of tasks as well as the overall goals of the people who use are software. Activities also allow us to take into consideration the social interactions we participate in when we solve problems, whether getting recommendations from trusted people or asking perfect strangers what they would do.

Here’s a nice chart provided by Porter that distinguishes between goals, activities, and tasks for some popular social websites:

While Porter is talking about identifying key social application activities here in the context of developing applications, the same analysis should go into acquiring packaged applications to deliver valued user experiences. If you don’t carefully consider the key activities that your application must support, and the user experience of how those activities are fulfilled, there’s very little chance that you’ll deliver experiences to your users that delight them.

Next up, Social Objects

Having established a method for defining user requirements for your social application, the next post in this series will delve into the heart of the matter – identifying and describing your Social Objects.

Stay tuned.

glenn

Also in this series

• Defining Requirements for Social Web Applications – Part 1: Overview
• Defining Requirements for Social Web Applications – Part 3: Social Objects
• Defining Requirements for Social Web Applications – Part 4: Defining Core User Actions
• Defining Requirements for Social Web Applications – Part 5: Motivations for User Participation
• Defining Requirements for Social Web Applications – Part 6: Collective Intelligence
• Defining Requirements for Social Web Applications – Part 7: Enabling Sharing