Eric Ries, the founder of the lean startup movement, advocates to test heavily before adding a feature. It might be that people will never use it! In fact, if you can mock up the feature, and simply count how many people try to use it, you will get an estimation on whether it’s worth building it or not. However, there are some basic principles that could prevent you from even thinking about poor features.
From Alex Jenter, author of cintanotes we get a rule for when to add a feature:
"features should be organic, effective, discoverable and convenient".
"Organic" means that the feature shouldn’t stick out of the program like an alien body. A non-organic feature IMO is the one that while coming in handy sometimes, still isn’t really connected with the product’s main goal and functionality. (Example of non-organic features: HTML authoring in MS Word, wave editing in Nero Burning ROM)
"Effective" means – should be lightweight and not hurt performance and memory footprint, or be optional to use.
"Discoverable" means – a new user should be able to discover that this feature exists without reading help.
"Convenient" means that a feature is easy to use correctly and hard to misuse, and that a significant number of users will use this feature on a regular basis.
So if the suggested implementation of a third frame will seem to satisfy all these criteria, off we go.
Paul Beckingham, from Task warrior, gives a good rule for when a program feels bloated:
Me: [The features that go unused stay out of the way. We never need to see them. It can seem as simple as we want.]
Paul: That’s been a goal for a long time. Users should not have to "pay" for features they don’t use, in terms of performance or visible complexity.
But this is not an easy balance. For example, let’s say the program has 100 features, but you are aware of only 10. If you want to learn more, but the program doesn’t give you an easy way to find the other 90, then you might consider the software cryptic. Cryptic is a label you might apply if you couldn’t easily figure out some aspect of the software, regardless of how well that may be documented somewhere. If instead the program tries to gently make you aware of more features, then it can become intrusive (remember Clippy?).
At the other end of the scale, if you are aware of the 100 features, but really only need 10, then you might consider the program bloated. Bloated is a label you might apply if you felt there were too many features, and they were getting in your way.
While these two are desktop programs, I think the principles apply for web apps.
