Creeping Featuritis

Kathy Sierra over at Creating Passionate Users recently wrote an article Featuritis vs. the Happy User Peak which I’m sure will resonate with everyone reading this. Kathy wants companies to stop adding features to products, for features sake, even if that means losing some potential customers.

Some excerpts:

* Stereos (or other consumer electronics and appliances) that use “modal” controls so that you cannot obviously figure out how to make it do the most BASIC FRICKIN’ THINGS ; (

* Software that keeps adding feature upon feature until the simple things you used to do are no longer simple, and the whole thing feels overwhelming.

Kathy is so on the money here. When I started thinking about Surfulater some 3 years ago now, I knew right from the outset that I wanted a program that would be as simple as possible to use, one that wasn’t bloated with 5 different ways to accomplish the same basic task, and one that didn’t have functions like create child node, promote to parent, next sibling and other “my brain is going to explode” commands.

I’ve been writing software for long enough now, looked at more than my fair share of other programs, read enough text books on User Interface design and spent plenty of time with my users, to get a pretty good feel for what makes a program easy to learn and quick to adopt versus what might be a program with great potential but is so poorly designed the frustration of using it, is too unbearable to consider. Now I don’t for a second consider I’m an expert in anything, but I do sincerely hope I’m striking a reasonable balance of ease of use vs. functionality with Surfulater.

Kathy goes on to suggest that companies should hold back on continually adding features just because customers ask for them, even if this means losing customers. Again this is a balancing act, but in general terms I have to agree. Products that don’t have every bell and whistle known to mankind are not only easier to use, but they’re cheaper to build and maintain. This is particularly true of software, where adding a new feature can break something elsewhere in the program.

Surfulater is a new and evolving product. People are using it for all sorts of tasks, and of course there is a steady stream of requests for new features and capabilities. In fact we go out of our way to encourage people to tell us what they want and need from the software we develop. We carefully consider each request, look at how many people are requesting the same thing and see if it fits in with where we see the product going. We also need to determine if the feature is of broad interest to our users, or maybe something that only power users want. Then we need to work out the cost of development and try and guesstimate whether we’ll recoup our investment. And finally will this new feature make the product more complex than we want. Only after all these measures can we decide on whether a particular feature should be added to the program.

Tied up with creeping featuritis are the expectations that users have, that there will be an ongoing stream of new releases to further excite them. After all, everyone wants new toys to play with. If software companies don’t meet these expectations, there is the possibility that their users will think something is wrong at the ranch and that product development has ceased. So we have to somehow keep bringing out new releases, without them suffering from creeping featuritis. This is no easy game to play, I can assure you.

Well that’s enough from me for this post. You can go on over and read Kathy’s piece now. As always your comments are welcome, but try not to ask for new features. 😉