I’m currently reading Designing the Obvious, and I’ve also read Rework before that, along with a few other web design and usability books. This by no means makes me an expert on the subject, but even someone new to the field can discern some main trends just from reading these few books. Most books advocate keeping things simple, reducing features, and the “less is more” philosophy (or, as 37Signals would say, “less is less“).
I don’t have a problem with this in principle. I think it’s an admirable goal, and it certainly makes everybody’s life easier when an app is easy to use and straightforward.
But I also wonder if the proponents of this simplification dogma are not, well, over-simplifying the problem.
For example, one of the most common piece of advice is reducing the number of features, until you’re left with only the ones that are absolutely vital to the application or website. This way the app will be both faster to develop and easier to use, and you’ll be well on your way to holding $1,000 a seat workshops. Sounds good, but how does this hold up to reality?
Not very well, it turns out. Most clients don’t hire you to tell them to drop half of their app’s features. They’ve already spent thousands of dollars developing these features, or maybe a big clients of theirs has requested them. Or maybe, and this is the most common scenario, those features are actually vital to the app but you just don’t have the experience in that particular field to know that.
Yes, there’s a world besides project management software and sign-up forms. A big part of design happens behind closed doors, on intranets or highly specialized applications for fields like medicine or finance. How can you be sure which feature is core to the application and which isn’t really needed? Is the decision even yours to make?
The real challenge of design lies in taking an app full of confusing features —including a few that you might not even understand yourself— and still make it usable.
And don’t believe those who tell you that you shouldn’t compete on features. A product with two features will always lose to a similar product with three well-implemented features. People might want “simple”, but they don’t want “dumb”. And in a lot of case, they don’t even want simple at all.
The other issue with this line of thinking is that you might start to always try to “out-dumb” your users. You’ll to think up the dumbest thing someone could do with your app, and end up designing for the lowest common denominator. And this leads to the inhibition of creativity and risk-taking.
Once you’re designing for the least computer-savvy users possible (the ones who try to log in to Facebook on ReadWriteWeb) there’s no way you’ll ever try anything new.
Ironically, people tell you to stick to user interface conventions to avoid confusing users, but they forget that in order to create those conventions, someone, somewhere had to once try out something that worked better than what was there before.
Thankfully, not everyone is buying into this. A perfect example would be the new Twitter for iPad app. Are the sliding panels absolutely necessary? No, none of the other Twitter apps use them. Do they make you think? Yes, they take some time getting used to. Do they make the app more enjoyable to use than any of the other, “simpler” Twitter apps? Absolutely.
So in conclusion, I think we should all trust our clients and our users a little more. Sure, most people hate computers and can’t tell their browser from their operating system. But our goal shouldn’t be to cater to their ignorance. It should be to take them by the hand, and make it easy and painless for them to get better at the Internet.
If they did, they’ll absolutely have to find out what the requirements are and work to implement them through a usable interface.
Icoach
Hi, I agree with you in some points you are making, but I think it highly depends on context in which you are designing the app. If you design your own application, keeping things simple will protect your sanity
You would go crazy to well implement all features in the first release.
On the other hand, if a client hire you to build complex app, you can’t tell him to reduce features unless they are not making any sense. The client should know, which features are vital and which are unnecessary.