# Capabilities over features

> The range of things a product can do, or its capabilities, and how many features a product has are separate matters.

The range of things a product can do, or its capabilities, and how many features a product has are separate matters.

## Features and capabilities

I believe that a good product should create the greatest possible capabilities with the fewest possible features. One way to achieve this is to make features as orthogonal as possible and increase the combinability between features.

Many planners endlessly add "features" and think about "features," but I wish they would focus on capabilities rather than features. That is how you can make a product that is easy to learn. This is one of the elements necessary to achieve [excellent usability](https://wiki.g15e.com/en/pages/Exceptional%20usability.txt).

## Usability damaged by features

Features are the main culprit that harms usability.

- It is easy to add a new feature, but hard to remove an existing one. That is because a feature is a promise to users. Therefore, adding features must be decided with extreme caution.
- In general, the more features there are, the more there is to learn, so learnability declines. This is one of the main things that interferes with achieving [excellent usability](https://wiki.g15e.com/en/pages/Exceptional%20usability.txt).
- The people making a product are already familiar with the features the current product has, so they often believe that adding just one more feature will not be a problem. But users encountering the product for the first time are often overwhelmed by an excessive number of features. (A similar phenomenon to how the brutal difficulty of a game full of entrenched veterans blocks new-user entry.)
- Once features with low orthogonality keep getting attached, users have to agonize over which of several methods for accomplishing the same task they should choose. I like Obsidian, but I do not like that [Obsidian](https://wiki.g15e.com/pages/Obsidian.txt) has folders, tags, and links all at once. Not only does this make countless users wonder in which situations they should use folders, tags, and links respectively, it also permits wrong choices and often leads users into pitfalls. This violates <monotony in design>. (For reference, I do not use folders because I believe [information architecture is not a tree](https://wiki.g15e.com/pages/It%20is%20not%20a%20tree.txt), and I do not use tags either because I think the advantages of tags disappear as the amount of material grows. See also: [wiki gardening rules](https://wiki.g15e.com/en/pages/Wiki%20gardening%20rules.txt))

## References

- What first prompted me to think about the distinction between capabilities and features: [Simplicity is not the answer](https://wiki.g15e.com/pages/Simplicity%20is%20not%20the%20answer.txt) by <Donald Norman>