Pareto Principle
A small share of features carries most of the use, which is a prompt to go and measure rather than an excuse to cut.
Definition
The observation, named after Vilfredo Pareto, that outcomes are often unevenly distributed, with roughly eighty percent of effects coming from twenty percent of causes. In product work it is used to focus effort on the small set of features that carries most usage.
Craft convention. True because the industry converged on it. Breaking it costs familiarity, not correctness.
On this page
The dangerous version
Used carelessly, this principle justifies removing the long tail. That is usually wrong. Low-usage features are frequently the ones a small, high-value segment depends on absolutely, and a feature used by two percent of users may be used by eighty percent of your enterprise revenue.
The correct move is usually not removal but demotion: keep the capability, move it out of the primary path, and stop paying design attention proportional to its footprint rather than its value.
Better uses of the principle
- Give the top tasks the shortest paths and the most design attention.
- Demote rarely used features to a secondary surface rather than deleting them.
- Prioritise performance work on the highest-traffic routes.
- Segment usage before concluding a feature is unused. Aggregate percentages hide dependent minorities.
In practice
Toolbar versus overflow menu
EditorsPromoting the four most-used tools to the toolbar and moving the rest to an overflow menu preserves capability while shortening the common path.
Segmenting before deprecating
Enterprise softwareA feature at three percent overall usage turned out to be used by every customer above a certain contract size. Aggregate numbers would have recommended deleting it.
Sources
Where a source establishes something narrower than the popular reading of it, the note says so.
Cours d'économie politique
V. Pareto, 1896
The original observation concerned income distribution, not software features.
Continue from here
Each link says what the connection is, so you can tell a principle from an alternative from a thing people mix this up with.
Applies when you are designing
Why this works
The reasoning this entry rests on.
- Availability HeuristicCognitive bias
- Sunk Cost FallacyCognitive bias
Applied through
Where this shows up as a concrete interface decision.
- Bulk ActionsPattern
- Information ArchitectureResearch method
- Product AnalyticsResearch method
- Prioritising Design WorkWorkflow
Related concept
Connected closely enough to change how you apply this.
- Flexibility and Efficiency of UseHeuristic
- Occam's RazorPrinciple
- Progressive DisclosurePrinciple