My TV remote has twenty nine buttons I’ve never used; the VCR has thirty; the DVD player twenty six. And before you ask - yes I really did count them all.

There’s a name for this kind of excess: it’s called featuritis, and it pops up in all sorts of design failures. I stumbled across an interesting article on The Featuritis Curve the other day that goes a long way to explaining why we have to endure this.

Good designs are obvious. When aesthetic and functional beauty combine, the result is not just pleasing to the eye, but a pleasure to use. This is why the iPod is so popular. Chances are it’s not the best value for money - there are probably other music players that produce a better sound, have a longer battery life, or have a whole raft of additional features - but the iPod looks like a work of art and is simple and straight forward to use.

When have you ever heard someone boast that they couldn’t program their iPod?

So who should we be designing for anyway? The 98% who use a small number of features all the time, or the 2% who use advanced features once a week? Wouldn’t it be a whole lot simpler if my TV remote had a single advanced button that opened a menu for all those quirky, unused features?

Make no mistake here - you’ve never used those mysterious buttons either, and you probably don’t know anyone who has.

Software is often designed in the same way, for the same 2% of users. Feature after feature is added, each just as prominent as the one before, with little thought given to the complexity this adds to the product as a whole.

At the nine to five over the past few weeks, we’ve been putting the finishing touches to a new product aimed at the business market. It’s the sum of eighteen months work for four programmers - plenty of time and resources to produce a first class piece of work. But it’s not first class. Dialog after dialog contains features, options, and checkboxes that no one really understands. The poor unfortunate writing the help file has to suffer every time he asks for an explanation of feature X. In some cases, even the person who designed the feature can’t explain it without re-reading his own code, and even then the explanation can be patchy.

This isn’t funny, it’s critical. Complexity like this is nothing to be proud of. But why does it happen?

You can chant ‘keep it simple‘ until you’re blue in the face, and everyone around you will nod their head in agreement. The problem is, we all have a different perception of what simple means. Programmers are geeks; they belong to the 2% who use all those weird buttons on the TV remote, and for many of them these features are absolutely essential. The sales and marketing types want to be able to say that their product is better than the competition because it can also be used to fry an egg, or do your kid’s homework. But that does not make it better.

Features are not important, it’s the product as a whole that matters. Does it do what it was designed to do, and does it do it fantastically well? Does it look good, run smoothly, and behave intuitively? If it doesn’t, then all the features in the world will not save you.

More features does not equal more sales. More features does not make for happier customers. More features will not make your product better than the competition.

PageFour has reached the stage where featuritis first raises its head. Over the past couple of weeks I’ve been putting together a future development plan, and my focus throughout has been on identifying those mysterious buttons that so few of us ever use. Only time will tell if I’ve succeeded.