Are More Choices Really Better?

A. Bosch writes to mention that Joel Spolsky of Fog Creek software has a commentary that examines the need for choices in software. From the article: "This highlights a style of software design shared by Microsoft and the open source movement, in both cases driven by a desire for consensus and for 'Making Everybody Happy,' but it's based on the misconceived notion that lots of choices make people happy, which we really need to rethink." With software steadily becoming more sophisticated, are more choices really necessarily better?

Comments

What does this have to do with anything?

[0racle]

With software steadily becoming more sophisticated, are more choices really necessarily better?

What does one have to do with the other? Choices are only good when all your options are simple? It's better to have one that works in a very complex, impressive manner then several that work better for different people?

I don't have time to find the article right now

[jgalun]

Just enough time to post about it. :) Harvard Business Review carried an article within the last year which talked about the difficulty of designing simple products for consumers. One of the problems they found was that consumers always SAY that they want more features, but then IN PRACTICE are happier with products that are simple to use and do a few features well.

This may seem common sense, but there was actually a study done to confirm this bias, and, frankly, common sense isn't always so common. That goes a long way to explaining why Apple is doing well again - Jobs is basically dictating how you use the computer, and although that does not seem like a good thing, most users actually appreciate the elimination of the extra complexity they don't need.

There's a 90/10 rule at work here

[jimfrost]

I have a friend (this guy) who starts off a class on GUI design by asking for a show of hands from the class.

The question is, "Who here prefers a manual transmission car to an automatic?" I have been in probably a half dozen classes of programmers when he did this, and every time he gets about 50% of the audience to raise their hands. Privately he tells me that it's almost always 50%, give or take a couple of percentage points.

After he gets the count of hands and shows that it's about half of the audience, he points out that the public as a whole (at least in the U.S.) prefers automatics to standards by a margin of at least 9:1.

His point in doing this is to show that the kinds of interfaces that programmers like (lots of knobs for extra control) are not necessarily the kinds of interfaces that most people -- which is to say "the people who buy your software" -- want. The vast majority would prefer simplicity; in fact, they will pay extra for simplicity.

Building in a lot of options makes about one tenth of the audience happy, but annoys or confuses the heck out of the other ninety percent. It is not good software design; it makes for more difficult training and much more difficult technical support. If you feel you must do it, it's best to hide these knobs in an expert mode ... but by and large you're better off by not providing a lot of knobs in the first place. Spend your time carefully designing your software so that you make the right choices so that your users don't have to figure out how to fix what you did wrong.

Re:That depends upon the severity of mistakes.

[cmat]

Who cares as long as it is ready to operate when I come back?

Actually, I think that's exactly what the author of the TFA is trying to hit home. There are some times when multiple options are unavoidable. For everything else, there should be simplicity where mainstream software is concerned (and I would be willing to argue even specialized software can benefit from this mode of thought as well).