A coworker recently forwarded around this article from the New Yorker that talks about feature creep and consumer behavior:
You might think, then, that companies could avoid feature creep by just paying attention to what customers really want. But that’s where the trouble begins, because although consumers find overloaded gadgets unmanageable, they also find them attractive. It turns out that when we look at a new product in a store we tend to think that the more features there are, the better. It’s only once we get the product home and try to use it that we realize the virtues of simplicity.
It’s a succinct summary of some of the many challenges in developing software – e.g. the mantra of “We are not our users so we can’t just design for ourselves”, and the traps you can fall into by paying attention to only that mantra.
Another related article is Donald Norman’s “Simplicity is Highly Overrated”:
Make it simple and people won’t buy. Given a choice, they will take the item that does more. Features win over simplicity, even when people realize that it is accompanied by more complexity. You do it too, I bet. Haven’t you ever compared two products side by side, comparing the features of each, preferring the one that did more? Why shame on you, you are behaving, well, behaving like a normal person. […] The complex expensive toaster? I bet it sells well.
And of course, my favorite software writer Joel on Software says this:
I think it is a misattribution to say, for example, that the iPod is successful because it lacks features. If you start to believe that, you’ll believe, among other things, that you should take out features to increase your product’s success. With six years of experience running my own software company I can tell you that nothing we have ever done at Fog Creek has increased our revenue more than releasing a new version with more features. Nothing.
So what’s a software development team to do? That’s a key part of what my job is these days, User Experience Manager for Exchange. Sometimes it seems like it’s half science, half black magic. My team does a lot of usability testing, surveys, focus groups and other forms of research to really get at the heart of what users want that they know they want, and even trickier – what users need but don’t know they need.
For example, we have spent a fair amount of time observing IT pro’s or end users (and recently even developers) as they go about their job. Some of the things we learn are fairly obvious – the user will sit back and say “See this here, this annoys me…” and proceed to show us a cumbersome task they have to achieve today using our software. So that’s a pretty obvious learning for us to take back and optimize that scenario. But sometimes, users perform repetitive tasks without even realizing that it would be possible to automate or remove the necessity for that task – and that’s one of the real challenges of the role, to figure out what those things are.
On a related note, I have an opening for an interaction designer and a user researcher on my team. If you don’t already know what those roles are, then you don’t qualify. 🙂 But if you do have a background or degree in some form of interaction design or user research/human factors/human-computer interaction/experimental psychology/etc and are looking, drop me a line at kclemson AT microsoft DOT com. Unfortunately I can’t share too many details (yet) of the work that will be owned by the people we hire for these roles because it’s still NDA, but I can promise you it’s super super super supa cool stuff.
 And I use the term ‘users’ here instead of ‘customers’ very specifically because the set may include users who do not currently own my product, but who I of course want to own and use and love it 🙂
 Experience with visual design or web site design is a plus, but the focus of the job is on interaction, not visuals.