May 05, 2002

Bloatware: Good or Evil?
Joel wrote a nice piece on why usability and featuritis are often at odds. Here are a couple excerpts:
"Featuritis sells products, but choices reduce usability. The really great designs are the ones that appear to eliminate a choice. You know you're doing your job as a designer when you figure out a way to take a complicated feature and make it simpler."

"It usually takes a lot more code to make a simpler interface."


But then I noticed an older post from Joel about Bloatware:
"Remember, kids, the trouble with the "everyone only uses 20% of the features" myth is that everybody uses a slightly different 20%"

"No matter how much it bothers you neat freaks, the market always votes for bloatware."


I think Joel's right on both points --- and it creates a paradox. What is better: do right by your users by keeping your product simple, or do right by your company by helping them win market share, adding features? The obvious and tricky answer is that you have to find a balance. If the feature you add is actually used by 20% of your users, that might be good enough to justify putting it in your product. Sometimes it may only be used by 1% of your users, and used rarely, but it may still be worth adding. Need an example? How about Disk Defragmenter in Windows? Few people actually know what it does, but it can be very important to getting a system working better. Of course Joel's second post make me think that things like defragmentation should just be handled automatically, behind the scenes, so that's a bad example. A better example might be a system administration feature for an ecommerce system like IBM WebSphere. Something like a system rollback option that restores a system to a prior state might be used rarely, and by relatively few people, but it adds a lot of value when it is needed. And, if no other competitor has that feature, it now becomes a wedge that marketing can use to create distance between your product and the competition.

It then becomes our jobs as designers to figure out how to add new features without overloading new users with too much complexity or confusing existing users by moving legacy features around. That's why we get paid the big bucks. :-) ...and that's why we have our methods toolbox full of things we can use to deal with that challenge.

No comments: