Here’s a counter-intuitive fact: Chances are all those features you've been adding to your design are hurting your user experience. Every feature that’s squeezed in, in the name of giving your design a competitive edge, has been making your design less competitive.
Some people seem to misunderstand the definition of the word "fact." No, this is NOT a fact. If you have to say "chances are" in the definition of your "fact," you're citing something that can change; it's not a fact, it's an observation (and in this case not even a well-supported one, often verifiable though we might find it).
No, new features do NOT necessarily make your design "less competitive." What that even means varies vastly and indefinably between almost any two given projects. Any given feature may be implementable in ways that do or don't improve usability/competitiveness, or that simply don't affect it, and even those perceived differences are likely to vary from user to user.
How a feature is added to the interface, how the interface is structured, who it's built for and what they expect and are familiar with, whether it's intended to attract people outside of a single strict target demographic, whether all features are available to all users... these are relevant facets that make this "fact" absolute crap.
This article starts begins with an assumption and draws inevitable conclusions that are all out of whack.
The reason a TV remote is overly complex is because, while you might not need the "control caption" button, there is a subset of users for which it's critically important, and it is not practical to produce 15 variants of the remote. Google Docs is experiencing massive uptake is because it's online, linked to your gmail account and convenient to use - but it has got a long way to go before it displaces Word as a professional document publishing app (ever tried to get a print version of a good doc that was exactly the same as what you had on screen?). And FFS - has OP used Salesforce.com? Look up 'feature bloat' in the dictionary and you should get a link to it.
Of course there is always friction between features and user experience, but it's the designers job to marry the two. A designer who always says no is not going to be a designer much longer.
User experience designer here. I think the point of the article is that it's the business owner's job to say 'no'. The designer can make recommendations and provide best practices, but he or she should never be held accountable for requirements and feature sets.
Funny how many "blame the designer" comments I'm reading here. I'm a UX designer very accustomed to dealing with the kinds of feature creep issues Jared addresses. Allow me to give you my perspective.
Given the opportunity, any competent interaction designer will give you a great user experience, IF they've been allowed to practice User Centered Design (user research and modeling, rapid prototyping, user testing). That's a big "if."
In reality, we have to balance user needs with business drivers (mainly keeping up with competition), marketing, technological constraints and of course legal and compliance. Each situation is different, but most of the time, whoever holds the purse strings gets final say. The end user almost always gets thrown under the bus.
Oh, I scream and holler and hold up extensive research to back up my rationale. But ultimately decisions get made by risk-adverse middle-managers who are more concerned with protecting their department's status quo than actually taking their customer's real needs into account.
I hate these kinds of articles. He gives the example of a TV remote with never-ending complexity like pause, record, slow motion, rewind, and so on. However, what is the solution? Saying that one should say "no" to all but essential features is a nice platitude but, after saying "no" all those times and whittling the features down to the bare essentials, what are the underlying principles with which one can present those essential features to the user without over-complicating the user experience?
I'd like to see a case study taking all the complexity that a modern remote has and yielding simplicity. Would you go from a 50 button remote down to the Apple TV remote which has only three buttons and a four-way directional pad?
What would Jared Spool's properly designed remote control look like?
You raise a good question, and it's really annoying to read articles that tease out specific examples and never offer the alternative. However, I'd say you answered your own question. The TV remote really needs to be nothing more than a D pad, select button, and back button (could probably even dispense with that). You then just work on the software which is context aware and presents you the simple 2-3 choices you need within each context.
If you're offloading buttons from the remote into a context-aware software interface, the interface now becomes an integral part of the UX. And avoiding an additional button on the remote control in favor of a software menu may, in fact, degrade the experience. Having a "swap to previous channel" button is likely a better experience than making someone access that functionality via a software menu.
This is great. Even more important for apps, where only little real-estate is available and your app has to nail that one use case (because if you try to do two use cases, your users will move away to two apps who do either use case much better than your app).
In my opinion, this is one of the things that is keeping Eclipse from progressing. I still use it when programming Java because of the 3-4 awesome time-saving features it provides that a text editor couldn't handle, but I just can't be bothered to learn where it hides the rest of the functionality that might make it more generally useful.
It took me to the end of the first paragraph to realize that "Experience" was an adjective not a verb in this situation. (i.e. I read it like "Experience Mexico!" not "Usability Rot")
Some people seem to misunderstand the definition of the word "fact." No, this is NOT a fact. If you have to say "chances are" in the definition of your "fact," you're citing something that can change; it's not a fact, it's an observation (and in this case not even a well-supported one, often verifiable though we might find it).
No, new features do NOT necessarily make your design "less competitive." What that even means varies vastly and indefinably between almost any two given projects. Any given feature may be implementable in ways that do or don't improve usability/competitiveness, or that simply don't affect it, and even those perceived differences are likely to vary from user to user.
How a feature is added to the interface, how the interface is structured, who it's built for and what they expect and are familiar with, whether it's intended to attract people outside of a single strict target demographic, whether all features are available to all users... these are relevant facets that make this "fact" absolute crap.