Cut Back on Features!

“Don’t take away features from users. If they want to do something, even if it lets them shoot themselves in the foot, let them.” warnerja from forum.java.sun.com

I’ve been playing with this article for a while now and it’s been sitting in my drafts list for nearly two weeks. I’m sick of looking at it, so I’m hoping it spurs some other interesting topic.
“Less is more.” Technology is supposed to make things easier. I’ve worked in technical support, managed distributed support personnel, trained non-technical users, and worked with enough clients to fill a hundred canvas sacks. In my purely anecdotal experience, more features means more frustration.

Check out this phone from Jitterbug, developed by Samsung. The selling point is the lack of features. No camera, no games, no crazy ringtones. No mini-keyboard, no text messaging, no web browsing.

It’s just a phone.

While this particular product is aimed at seniors and an aging, still-wary-of-technology segment of the population, I can’t help but think this is a good idea for a lot more than my wife’s grandparents.

With all the hoopla around the iPhone, I have to wonder: Where’s the phone that just works? Not the one that plays my mp3s and lets me hack into NORAD, but the phone that I can rely on – the one that connects when I want and answers when I want?

Does it matter that the frosting is pretty if the cake tastes like cardboard?

For the past few years, I’ve built websites that can be maintained using Macromedia Contribute. It’s like the little brother of Macromedia Dreamweaver. I call it the “Fisher-Price of Web Development.” You can’t do anything serious with it, and that’s good. Update content, even create pages. But it’s hard to mess things up. For non-technical users (e.g., an administrative assistant that needs to make the occasional update), it’s sufficient.

That word there is “sufficient.” Your product has to get the job done. But it doesn’t have to do a lot more than that. That’s because we reward success – not excess. Plenty of products are feature-rich but break down when we need them most. Don’t you wonder why the developers spent so much time on added value while the core functionality (the reason you rely on this thing) doesn’t work?

There are two issues here. First, there’s the goal of producing a great product by focusing on the core features. Second, there’s the issue of making it better by making it harder to mess up. The quote from above suggests that you should let users shoot themselves in the foot if they want. If you make it easy for your customer to shoot himself in the foot, your customer will shoot himself in the foot. And he won’t be happy.