If there is one disease that affects nearly all design projects, it’s feature creep. It is the deadly affliction in which design teams gradually add feature after feature, like straws on a camel’s back, until they ultimately overload their interface and make the software difficult to use.
Feature creep happens when there is a lack of sustained focus on what’s most important. Instead of deciding on a few core features to support, the team ends up trying to support too many. The software inevitably becomes harder to use, as features compete with each other within the interface.
To prevent feature creep, designers need to answer several questions early on in the design process. What is the primary activity our software is supporting? What features do we need to effectively support that activity? And, perhaps most importantly, what features can we leave out?
A lack of design focus can result from factors that seem, at first glance, out of the designer’s control:
Competing interests. Is marketing pushing one way, engineering another, and management yet another? When each part of a machine is geared to moving in its own direction, it hinders coordinated effort toward a common goal.
Political infighting. Is arguing and disagreement stalling progress? Do team members disagree on major issues and refuse to budge? Do personalities clash?
Lack of audience clarity. Do you know who to design for? Are you talking with them to find out exactly what their problems are?
Fuzzy strategy. Does the strategic plan sound more like buzzword bingo? If you substituted someone else’s strategy, would it change the way you do things?
No vision for success. Do you know what success looks like? What has to happen to make you successful?
These issues constantly plague design teams. They serve to shift focus away from the design problem and cause frustration. Worst of all, they prevent designers from doing their best work.
What design teams need is a way to prioritize and assess the value of proposed features. They need to know if a feature is worth the time and energy to implement and support. A prioritization scheme would help address the questions:
Where should our design team focus its time and energy?
What features should we consider adding? Improving? Removing?
Will this feature set support our overall strategy?
How do we get away from politics and competing interests and onto questions about the design itself?
This chapter describes a simple prioritization scheme for designing social web applications that I call the AOF Method. AOF stands for Activities, Objects, and Features.
The AOF Method is made up of three general steps.
Focus on the primary Activity. The first question you must answer (and always abide by while designing) is: What is your audience doing?
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.
Choose your core 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?
As a designer, it has been drilled into your head to “know your users.” This sounds like great advice: pay attention to the people you’re designing for. But when we actually start to do that, it becomes pretty clear that the number of things we could pay attention to is never-ending. If we were to actually know our users in the true sense of that phrase, we would have to follow them home, stay overnight at their house, and hang out with them on the weekend.
More important than knowing all about the people we design for, we should have a deep understanding of the specific activity we’re supporting with our design. 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.[2] The time people spend using our design is the time they are doing some well-defined activity. The rest of their time on Earth, while interesting, doesn’t affect our design very much.
For example, imagine we’re designing software for photographers. What is helpful from a design standpoint are the similarities in what photographers do, not what makes them unique human beings. Many digital photographers want to upload and share their pictures immediately upon shooting. While they may each be shooting different subjects in different contexts, the activity of uploading and sharing is remarkably similar for each of them.
Thus the most important question we can ask is not “who is using your software?” but “what are people using your software doing?”
Think about the software applications you use daily, the ones you rely on most. The most successful ones are focused applications that support one specific activity. Right?
Chances are you use email, chat, a word processor, a calendar, music player, photo editor, a spreadsheet, or some combination of those. You probably also use a web browser a lot. When you do go online, you probably encounter web applications supporting specific activities like banking, shopping, or managing your photos.
Simply put:
The applications people find most compelling allow them to excel at a single activity.
Consider the immensely popular site Flickr, which is focused on the activity of photo sharing. In personal terms, Flickr enables you to upload photos to share with family and friends. The designers at Flickr have added lots of features over the years, but they continue to focus on the same primary activity of photo sharing.
Another well-loved site is Etsy, which focuses on the activity of buying and selling homemade goods. Created as an antidote to eBay, the designers of Etsy focused on cultivating real relationships with the people who make the goods. All of the site’s features revolve around that idea.
The more that sites like Flickr and Etsy focus on their primary activity, the more people seem to like them.
Kathy Sierra talks about this as the “I Rule” effect. The “I Rule” effect is when people start ignoring the software they’re using and start to feel like an expert in what the software enables. You start to get a feeling like “I Rule!”
By focusing your software on a single activity, you make it much easier for the “I Rule” effect to happen. When your software is good at supporting its primary activity, like Flickr and Etsy are, then the person using it starts to feel great, not about your software, but about themselves. In Kathy’s parlance, they become passionate users.
Unfortunately, identifying your primary activity isn’t always easy. Try to answer this question:
What do people have to do in order for us to be successful?
If we were Amazon, we might answer: “purchasing goods.” If we were Netflix, we might answer: “choosing movies to watch.” If we were YouTube, we might answer: “uploading videos.” These are the things that have to happen for these services to continue to be successful. But they are far from all that happens on these sites. They are critical tasks that make possible the larger activity. On Amazon, that larger activity is shopping. On Netflix, it’s renting movies. On YouTube, it’s sharing videos.
It is 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.
This table distinguishes between goals, activities, and tasks:
Service | Goals | Activities | Tasks |
|---|---|---|---|
Amazon | Procuring basic goods | Shopping | Adding to shopping cart, performing a product search, comparing products |
Netflix | Entertainment | Renting movies | Rating movies, adding a movie to the queue, discussing movies with our partner |
Monster | Making money | Finding a job | Searching for a job, sending a resume |
Basecamp | Getting work done on time | Managing a project | Adding milestones, delegating tasks to others |
Menuism | Eating well | Finding great places to eat | Rating and reviewing restaurants, reading others’ reviews, making reservations, choosing a place to eat |
Flickr | Staying up-to-date with family | Sharing photos | Uploading a picture, sending a URL via email to our mother |
Thinking on the level of activities allows us focus on both the details of tasks as well as the overall goals of the people who use our 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.
A few important points about activities:
Activities are important because they reveal the process. Activities allow us to discover the steps people take toward reaching their goals. People go through a series of tasks, and while doing so they rely on others for help. By looking at this on the activity level, we recognize all of these important pieces.
Many activities are about managing information. This is no accident, as many activities are inherently disorganized. If activities weren’t messy, we might not need software to help us! People use software increasingly to manage activities.
Describe the activity in terms of the people you design for. Try not to describe the activity in terms of you, the designer. The activity is not “giving us money” or “using our stuff.” These are simply byproducts (hopefully) of the activity itself.
Many research methods help us discover the details we need to know about activities. Most likely, design teams will have different ways of conducting research.
The important thing about research is that you get over any initial assumptions about the activity, which will be too broad. The following research methods are ways to get more insight into the activities you’re designing for:
Interviews. Interviews are powerful yet simple ways to get an insight into how people perform activities. When performing interviews, focus on what people do, not their opinions about what they do.
Usability testing. You can set up usability tests in which you observe people using either competing software or an existing version of your software. This will give you insight into how people currently perform the activity and what parts of that activity aren’t well-supported.
On-site observation. Going to where the work you’re supporting is actually done is a great way to dive into the details of the activity. This is called “contextual research,” and it means that you do research in the context of work.
Observing yourself. Observing yourself doing an activity can give you unique insight into the details of it. However, people are notoriously bad at observing themselves objectively, so it’s best to combine any self-observation with observation of others.
Listening to people. With features like product message boards, phone line support, and simple feedback forms, you can gain tremendous insight into the activity you’re supporting.
The purpose of all of these research methods is to find out what is happening, why it is happening, and who it is happening among.[3]
After you do the research digging into the details of the activity you’re supporting, you can inform future design more confidently. Don’t be afraid to change your notions based on research! The key to any research effort is to observe and learn. As long as you are learning from real observations, you’ll be ahead of the game.
Let’s illustrate the value of research by doing an exercise. Let’s imagine that you’re building software that is going to support the primary activity of shopping. So start by writing down a description of the steps involved in shopping. Try to answer the question: what happens when someone shops? Don’t read further until you have your list.
Actually make the list now.
In describing the activity of shopping, most people will list four or five steps. Here is a list that I came up with off the top of my head. Let’s call it the “normal” view of shopping.
Recognize a need
Consider the different choices of product that fulfills the need
Choose a product
Optionally, shop around for the best price
Purchase the product
Your list will be slightly different, of course. But something like this is a basic shopping framework that most of us would come up with. Since most of us don’t think about the activity of shopping in great detail, the steps we describe are high-level.
Ethnographers are people who study human activity. They know that you can’t trust what people say, you have to observe what they do. They do fieldwork to understand what it is that people really do.
An ethnographer goes out into the wild and reports back. Here is what they might report when they observe someone shopping:
We studied a woman (Betsy) who had several talks with her husband about upgrading their TV service to HD. He was all for it, but she was skeptical. Their conversations happened over the span of several months. She then heard about an HD TV from a close friend who had nothing but positive things to say. She started to seriously consider buying one, thinking that in addition to her husband’s sports, an HD TV sounded like a better way to watch the nature shows that her children loved. She thought the product might be useful to her and her family. Betsy then decided that the family’s 18-year-old TV had had enough. She and her husband made the decision to replace their aging TV with one of the HD TVs they heard about.
The ethnographer might ask who Betsy heard about the TV from. It was Betsy’s friend Rachel, who recommended the 40″ Sony HD TV she recently bought.
While Betsy’s husband is gung-ho, Betsy is the financial organizer of the household. Therefore, she does much of the research on projects like this. She starts doing research on this particular product, to find out more about it and see if it might fit their needs and desires. Part of her research is going online and reading about it. She goes to Amazon.com, BestBuy.com, and Sears.com. She finds out that there are more screen sizes, qualities, and price ranges than she had expected. She makes a list of items that seem comparable. She is quite confused by all the choices. This is a big hurdle for her.
Another part of her research is talking to her close friends and other people she knows to have HD TVs, to see if they are familiar with the one she is considering. She trusts Rachel, but Rachel tends to recommend everything she has. Betsy wants second opinions. Have her other friends had good or bad experiences? Would they recommend the same TV? What other issues are there to consider? What should she watch out for? Are there alternative brands that she should look at?
One of Betsy’s other friends then tells her that buying the TV is only half of the issue. The other half is getting all the gear and cables to hook it up. Rachel hadn’t mentioned these issues. Betsy is quite discouraged at this point. The old TV was so simple: you just plug it in and it works.
At this point Betsy is in full research mode, with a lot of technical information swimming about in her head that wasn’t there a week or two ago.
Betsy and her husband think that the 40″ is perfect for their needs and they don’t want to buy a smaller one at this time. They consider if a particular HD TV fits within their budget. They decide that it’s more than they want to pay, so they’ll wait to see if it goes on sale.
The family waits for a couple of weeks and then receives a coupon from Sears in the mail. They would rather pick it up than have to pay the shipping costs. They go to a store to purchase it.
Note the extreme difference in detail between the two views. The first view imagines a five-step, generic activity called shopping. The second view is a whirlwind of indecision, still called shopping, but more like a large project to find a TV that works well for the family. And, also note that this second view is only one example of shopping. Each shopping experience has the potential to have this much detail!
This second view is what most activities are like: longer than we think, messier than we think, and with much more detail than we realize. While not all of these details will translate directly to design, many will.
This is the value of real research into activities. It uncovers those things we just don’t think of, but are all familiar with.
As the shopping example showed, people rarely make a decision without involving others in some way. Though most activities are social, much of the software designed today doesn’t take advantage of the social interaction of the people who use it. This results from thinking about activities in over-simplistic ways, like we did in the earlier view of the shopping activity. What actually happens in activities is always much more complex than our conception of it.
Once you start describing activities, you’ll be struck by how big a role objects play in them. For example, in our table above each activity we mentioned had an associated object: movies, restaurants, projects, jobs, photos. A huge part of our activity is managing these objects and the social interactions that happen around them.
Social objects, as we may call the objects that mediate social activities, are often overlooked in the excitement about social software, in particular, social networking sites like MySpace and Facebook. Jyri Engeström, the founder of the social messaging software Jaiku, laments that too much focus in social design is on networking, and not the ever-present social objects that connect us all together:
The term “social networking” makes little sense if we leave out the objects that mediate the ties between people. Think about the object as the reason why people affiliate with each specific other and not just anyone. For instance, if the object is a job, it will connect me to one set of people whereas a date will link me to a radically different group. This is common sense but unfortunately it’s not included in the image of the network diagram that most people imagine when they hear the term “social network.” The fallacy is to think that social networks are just made up of people.[4]
Discovering and modeling these social objects, and our interactions in and around them, is a major part in social design.
Sometimes, you can even model real-life artifacts as objects in your design. Here are three that have replicated a physical object in software:
Facebook. The Facebook is an actual book given out to Harvard students containing pictures and bios of all incoming freshmen, so they can enjoy finding out about their new classmates.
Amazon’s Wish List. Amazon’s wish list is modeled after actual wish lists that people make and share with others.
Remember the Milk. Remember the Milk is a list management tool that models the lists we make as we head out to do some shopping or roll up our sleeves to begin our chores.
Social objects within your web application don’t have to be exact representations of physical objects (like videos, photos, or dogs). They can be abstract.
For example, jobs and dates—the two objects Engeström mentions—are not physical in the sense that a table is, yet we easily deal with them on a daily basis. Projects and events are also abstract, but we organize our activities around them effortlessly.
What’s important is not that you have a single, physical object to focus on, but that you focus on a social object in the same way the people who use your software do. If people are organizing around funky objects like projects, then that’s an object you can design for.
To demonstrate the proven success of social objects earlier in this chapter, I listed a number of services that contain unique objects. There are distinct advantages to giving an object a URL:
URLs make objects sharable
URLs make objects easier to find and re-find
URLs allow people to link to the object directly
Search engines like URLs
The success of the photo-sharing site Flickr is tied closely with their decision to give photos a unique URL. Team member Eric Costello describes their transition from allowing people to share photos over chat to allowing people to archive photos at a URL.
Before URLs:
When we first launched Flickr, it was a Flash application that was mainly just a chat environment with real-time photo sharing. So it was quite limited in what you could do.
It wasn’t a photo sharing site, so much as it was a place where you could go to chat and talk about photos. But none of that activity was stored in any asynchronous way.
After URLs:
As we started adding features to the site itself, like pages that hosted the photos so that people could visit them at a unique URL, we had a lot more success with that. People responded to it, and the site began to grow.[5]
So once Flickr identified photos as their object and gave them a unique URL, their service started taking off. This makes sense: objects are unique, and giving them a unique URL allows people to treat them like freestanding objects. Once photos had a unique URL, they became addressable by anyone and everyone.
After identifying the primary activity and the objects people interact with, you’re ready to start creating your core feature set. Your core feature set is the set of possible actions that people can do in your application. They define what activity goes on, the possible interactions between people, what can and—sometimes just as importantly—cannot occur. Choosing features is one of the most important steps in defining what a web site is going to be.
In the beginning of this chapter we mentioned feature creep, the disease that afflicts so many design projects. So how do you avoid feature creep when creating and adding features? Start with your objects, your nouns. Observe all the actions people do with/perform on those objects, and those are possible features for your application.
Jyri Engeström calls this step “finding your verbs.” Given a noun, what actions are associated? The answer, as our high school English teachers would point out, is indeed a list of verbs.
Here are some examples of finding verbs:
Nouns (objects) | Verbs (actions) |
|---|---|
Videos | play, stop, edit, store, upload, share, comment on, embed in blog |
Articles | read, archive for later, quote, link to, share, comment on, annotate |
Photos | store, view, add to favorites, digitally edit, link to, make prints, share, comment on, embed in blogs, tag |
Books | read, add to cart, purchase, add to wish list, share, add to wedding registry, comment on, rate, tag, discuss, review |
Many of these verbs translate directly into features. If you’re building a video site, for example, you’ll likely have features to upload a video, play the video, and share the video. This simple step is where the most valuable features come from!
Also, notice that the verbs are both personal and social. This is to be expected, as we interact with objects both on a personal level and a social level.
Pay attention to any collections of objects. They can often become valuable features. One important collection is lists. Are people making lists? What of? How are they organizing and managing information? Here are some common ways that people collect things:
Wish lists
Shopping carts
Favorites
Shared items
My stuff (restaurants, reviews, bookmarks, etc.)
Friend’s stuff
Projects
Once you have an idea of the collections that people make, give them ways to manage the collection. What actions (verbs) do they perform on the collection? This will probably mean providing people with ways to add, edit, and delete items from the collection, and perhaps even treating the collection as an object itself, with features such as sharing and a permalink.
Let’s explore the social features on the Amazon site in light of the AOF method. As you can see, Amazon has a tremendous number of social features to help make shopping easier.
We can see that most of the actions support the most important object, the product. Amazon has focused most of their time and energy there. But they have also identified other important objects central to the activity of shopping, and include features to support those.
If we were designing with a common-sense notion of shopping, without doing any research, we would design a very different web site than we would with an ethnographer’s detailed study in our hands. It would be difficult to come up with the social features at Amazon from team meetings and common sense. It is only by paying close attention to how people shop, the reasons why they make lists, their heavy reliance on customer reviews, and their tendency to look at sales numbers, that we would be able to come up with these interface features. Sweat the details!
Once you start thinking about features as actions to be done on objects, it becomes clear how the most successful services figure out which features to add. They simply answer the question: What are people doing with the objects?
The table that follows looks at Amazon’s core features in this way.
Social Features (actions) | |
|---|---|
Products | Rate product |
Tag product | |
Review product | |
Customers who bought this also bought | |
Submit a product manual | |
Tell a friend | |
Share product images | |
Amazon sales rank | |
Add to cart | |
Wish list | Add items |
Create new list | |
Share list | |
Make public/private | |
Sort list | |
Customer reviews | Add review |
Comment on review | |
Was this review helpful? | |
Sort reviews |
As we have noted, features can get out of hand quickly. Here are a few guidelines to keep in mind when designing that help you deal with features reasonably.
There is no way around it: each feature in your web site adds complexity. The process of introducing it, shifting other things around, re-prioritizing things is complex. When this is done well, people adapt quickly. When this is done poorly, the interface becomes more complex and you start hearing complaints.
One way to counteract adding too many features is to simply say “No” to them. Accept only the most important features, and keep the others on the back burner until they are truly necessary.
There is a great story about the building of iTunes that applies here. Steve Jobs was talking to music industry people about the direction the software was going. They had all sorts of ideas for what the software could possibly do. After a while Steve got tired of the queries, and said:
I know you have a thousand ideas for all the cool features iTunes *could* have. So do we. But we don’t want a thousand features. That would be ugly. Innovation is not about saying yes to everything. It’s about saying NO to all but the most crucial features.[6]
One client I worked with would copy features that looked useful from their competitors. They said they didn’t have time to fully research features themselves. Later, I ended up speaking with someone from the design team of that competitor, and it turns out they did the same thing! They simply copied their features from somewhere else!
The Emerson quote at the beginning of this chapter is relevant here. It’s easy to simply copy features when everyone is looking at you. Your site looks like everyone else’s and people assume you know what you’re doing. It’s also easy to go your own way when nobody is looking at you. But it is the most difficult (yet most successful) when you can do your own research and innovate in the face of scrutiny. That’s why the best designs stand out...because they go their own way.
At some point all design teams struggle with a lack of focus. There are many reasons why. It helps to have a prioritization scheme like the Activities, Objects, Features method (AOF) to keep things focused. By keeping an eye on the primary activity and the objects related to it, designers can come up with a robust feature set that really does support what people are trying to do.
But as exciting as it is to get features in place, it is only the beginning of the battle in creating a social web site. You still have to motivate people to actually use the features you’ve created! That’s what we cover in the rest of the book, focusing on the major hurdles of usage that affect all projects.
[2] Don Norman has advocated for activity-centered design, even suggesting that human-centered design is harmful: http://www.jnd.org/dn.mss/humancentered_design.html
[3] A great resource on research methods is the book Contextual Design by Hugh Beyer and Karen Holtzblatt
[4] Please read Jyri’s now classic post on object-centered sociality: http://www.zengestrom.com/blog/2005/04/why_some_social.html