Putting the Del.icio.us Lesson into Practice, Part II: Feature Creep
Date : 2007 08 08 Category : Design & Usability
Bokardo - Social Design by Joshua PorterIn Part I of Putting the Del.icio.us Lesson into Practice we talked about how the Cold-Start problem affects social web applications that tend to focus on social value. In this part we talk about the problem of feature creep and why it happens.
The way to overcome the Cold-Start Problem (which we talked about in Part I) is to focus on personal value first when designing your social web application. Unfortunately, this isn’t always easy to do, given the state of design teams and current practices in building software. One of the biggest problems, of course, is feature creep. It is incredibly hard to focus on personal value when you’re afflicted with feature creep!
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 HappensThere 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 ObjectivityThe 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 FutureGood 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 CheapSince 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 JustifyBecause 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.
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
Add Comment