Deprecated: Assigning the return value of new by reference is deprecated in /nfs/c03/h01/mnt/52932/domains/ on line 472

Deprecated: Assigning the return value of new by reference is deprecated in /nfs/c03/h01/mnt/52932/domains/ on line 487

Deprecated: Assigning the return value of new by reference is deprecated in /nfs/c03/h01/mnt/52932/domains/ on line 494

Deprecated: Assigning the return value of new by reference is deprecated in /nfs/c03/h01/mnt/52932/domains/ on line 530

Deprecated: Assigning the return value of new by reference is deprecated in /nfs/c03/h01/mnt/52932/domains/ on line 103

Deprecated: Assigning the return value of new by reference is deprecated in /nfs/c03/h01/mnt/52932/domains/ on line 21

Deprecated: Assigning the return value of new by reference is deprecated in /nfs/c03/h01/mnt/52932/domains/ on line 623 » Feature Pressure

nerd nouveau

Feature Pressure

Recently, I’ve written a post about feature-sparse applications vs. feature-rich ones. To follow up on it, let’s talk about another negative effect feature-rich applications can have on the user: The overload caused by them, and the anxiety of a user when faced with extremely powerful (and thusly complex) applications or devices. I call this feeling “feature pressure”.

Applications with a simple structure and only a few features are easy to use. There is almost no learning curve. However, when adding features to an application, a point will quickly be reached at which the learning curve gets unproportionally steep. Even worse, your application suddenly looks intimidating, too, and to round it off, some users may not even need or use the additional features. In short, when an application is extremely feature-rich, users will generally experience at least one (more possibly, a combination) of the following effects:

  • Intimidation: For example, 1-3 toolbar icons are a piece of cake, 4-8 need some getting used to, 9-15 are a lot and 16+ are just plain intimidating (ahem, MS Word or UltraEdit, anyone?)
  • High learning curve: Remembering what a load of menu items does takes a lot of time. A lot.
  • Having overbought: A customer purchasing your 100-features software, but only actively using 2 of them, might easily feel like having overbought, no matter how expensive your application actually is. Next time, they’ll be looking for a simpler tool.
  • Not getting your app’s philosophy: If your application offers too many tools, the philosophy (i.e. the use-cases you had in mind) are getting increasingly hard for the user to understand.
  • It’s not flexibility, it’s bloat: Users don’t like bloated software. If they only need a subset of your features, they might swap your app for a competitor that offers just that.
  • Not feeling like it’s “for them”: If your users find themselves not using half of your app’s features, they’ll feel like the app has not been designed for them, but for somebody else. Consequently, they might go looking for something that feels like it has been made just for them, not a disperse crowd.

Naturally, these points might sound incredibly abstract if they are not backed up with a good example. So here is one: My cellphone. There’s only a handful of things I expect from a good handset: Of course, I want to be able to (easily) call people and receive calls, same for text messages. Also, I want to have a clock on the main display. I want an email reader (writer is not so important), too. Also, synchronization with my computer is a must-have. Those are basically the most important features for me, i.e. the ones that I use 90% of the time.

My current phone, a Motorola RAZR V3i, does all that, but also much, much more. There’s a camera, a media player with playlist capabilities, a browser, a calendar, a video player, even a little ringtone composition tool… The list goes on and on.

The first time I was toying around with it, I was overwhelmed with features to explore. There’s so much more than I would ever need. Not only did it take me a while to understand how all the mini-applications work (and I still haven’t figured out how to create a playlist in the media player), but I’m still not even using half of the features. Ever. I mean, I’ve used the browser once or twice, but it’s not sophisticated enough to provide for an adequate user experience. It’s slow, and the navigation sucks. I’ve snapped a few pictures, but they are too low-quality to be a replacement for a dedicated camera. And when do you ever feel like composing a ringtone on the go? No, the phone feels incredibly bloated to me. Other, less tech-savvy users will find it intimidating. Purists may feel like it’s not for them, being way too feature-rich. Price-conscious users may feel like having overbought. People who want to use it to the fullest will surely feel overwhelmed with the learning load.

Sure, if the features were better integrated with each other, like Apple’s upcoming iPhone is promising, they are perceived less as individual features and more as parts of a single, well-rounded application. This is clearly not the case with my current phone, where the individual features are scattered all over the place.

As the example of my phone shows, the worst thing to do is mash a lot of individual features together in a loose way. Much better, integrate them well with each other so that they are easy to understand and complement each other in meaningful ways. Even better, hide rarely used features from users that don’t need them by placing them in reasonably named sub-menus. Best, just don’t implement them in the first place. If it’s a mobile phone, it doesn’t need to be a radio receiver, too. If it’s a text editor, it doesn’t need to have graphics editing functions. As a rule of thumb, rather than accepting a new feature all too easily, let it prove itself first. For every reason not to implement it, try to find at least 3 good reasons that justify its implementation. But most importantly, don’t equate the quantity of features with flexibility. After all, flexibility is a qualitative aspect!


Hi, how are you? My name is Georg Kaindl, and I'm a twenty-something from Vienna, Austria. During the day, I'm a CS student at the Vienna University of Technology, but at night, I turn into an independent software developer for the Macintosh platform, social nerd, lazy entrepreneur and intuitive researcher.

I like to write about everything that matters to considerate technology enthusiasts, but humbly retain the right to go off-topic from time to time.

My posts are licensed under a Creative Commons Attribution 3.0 License.


You can reach me by email if you have something to say that's not related to a blog post or that you don't want to have publicly available as a comment to a post.

However, you'll have to prove that you are human! Even though I personally like robots very much, I'm less of fan of SPAM. It's just a simple riddle to solve, but a SPAM bot won't cut it!

To get my email address, take the word before the .com in my domain name first (Hint: The word you are looking for starts with a "g" and ends with an "l"). Next, simply attach to this word.

Boom, there's my email address. Simple, isn't it?

Powered by WordPress

Comments RSS

Entries RSS