August 8th, 2007

Putting the Del.icio.us Lesson into Practice, Part II: Feature Creep

by Joshua Porter  |   7 Comments

4 Reasons why feature creep happens and why it’s an even tougher problem when designing social web applications.

(This is part II of a series on Putting the Del.icio.us Lesson into Practice. Part I dealt with the Cold-Start Problem)

Feature creep affects almost all design projects. We’re all familiar with the bazillion features in Microsoft Word, the countless buttons on our remote control, and the acute difficulty of setting an alarm clock.

When building social web applications, feature creep is especially difficult because there are so many possibilities for social features! We’re always captivated by the potential social value of what we’re building. If we add tags here then people will be able to do that there! …etc. When we begin to imagine the possible social features it becomes doubly tough to focus on personal value, as The Del.icio.us Lesson would suggest.

Less than the Sum of its Parts

So what is feature creep? Feature creep is the process of slowly adding features to a product or interface over time. The result is a design that is less than the sum of its parts. The features may have added functionality, but the overall effect is negative. The complexity brought on by the features has, instead of adding value, made the design undesirable and a pain to use. Simply put:

Feature creep happens when the design team underestimates the burden each additional feature puts on the person using it.

To prevent feature creep from happening, it is useful to explore why it happens in the first place. By looking at the reasons why it happens, we can get a better idea of how to avoid it happening to us.

Why Feature Creep Happens

There are several reasons why feature creep happens. Most of the reasons have everything to do with the mindset of the designer/design team, not the actual features or the goal of the design itself.

1) Lack of Objectivity

The people adding features to a site are intimately familiar with the software. This means that not only do they know how to use it very well, but they spend a disproportionate amount of their time thinking about it. They get around the interface with no problem. It’s their job to do so.

The biggest outcome of the developer’s familiarity with software is that they can’t think about the interface objectively. They can’t imagine what it is like to be a new user of the software. They can’t imagine what it is like for someone who doesn’t quite understand the value of a new feature.

This isn’t for lack of trying, though. Many people try to imagine what it is like for their users. But a core part of being human is that this is an incredibly difficult thing to do. The problem is that most of us think we can overcome this problem. The reality is that most of us can’t.

As a result, features get added without the team gathering any feedback about how much more difficult they just made the interface. Even if the team is on board with the idea of testing, there is rarely enough time for it.

Each feature, no matter how smooth or easy-to-use, adds complexity. For social features this is doubly worse because those features are probably not only getting in the way of social activity on the site, but also in the way of personal value as well.

2) Planning too much for the Future

Good entrepreneurs and project managers are always looking to the future. They’re playing a game of chess: imagining how people will use their software 5 or 10 moves ahead. So much of what they do is to lay groundwork for that future, and in many cases this means that they add all the features they think will be valuable in the future…right now.

In social software, however, the future is as uncertain as ever. Because things are changing so fast there is really very little we can know about what will happen. Some social applications, most notably Flickr, started out as something completely different than what they ended up with. It was only a realization that the future wasn’t what they thought it was going to be that allowed the Flickr team to make the changes necessary to stay afloat.

3) Adding Features is Cheap

Since adding features to software is relatively cheap, adding features becomes one of the most common activities. This results from the fact that it is pretty easy to estimate how long adding features will take…developers can usually say “that will take X number of hours”. The common assumption is that building the feature translates directly into use…if you build it they will come.

But there are additional costs to adding features in addition to developer hours. With each new feature, the interface changes in some way. This adds up for the user. It may not be the 2nd or 3rd feature that gets them, but the 4th one might.

In addition, many users dislike changes at all. Some users hate change so much that they give up on software once it is changed as they see no use in having to re-learn an interface they already knew. Redesigns are the worst in this respect.

4) Easy to Justify

Because features are added one by one, it becomes much easier to justify each one. This is the slippery slope of feature creep. You add a feature here and a feature there and pretty soon you have a web of features competing for the user’s attention. You’re not asking “let’s add 20 new features and see what happens”, you’re asking “let’s add this little ol thing” 20 times over many weeks. That makes it very difficult to argue against…its like adding a straw to the back of the camel.

So those are some of the reasons why feature creep happens. It’s a big part of design in almost all circles, and definitely affects those designing for personal use. In the next installment of Putting the Del.icio.us Lesson into Practice we’ll talk about strategies to overcome feature creep.

This is part II in a series. Read Putting the Del.icio.us Lesson into Practice, Part I: The Cold-Start Problem

Grab the RSS Feed