---
title: "Pareto Principle"
source: "/reference/pareto-principle"
description: "A minority of features, actions, or causes often account for a disproportionate share of use or outcomes; the exact ratio is context-dependent."
---
# Pareto Principle
A minority of features, actions, or causes often account for a disproportionate share of use or outcomes; the exact ratio is context-dependent.
### Principle
A minority of features, actions, or causes often account for a disproportionate share of use or outcomes; the exact ratio is context-dependent.
### Why it matters
The familiar 80/20 phrasing is a heuristic, not a guaranteed distribution. In UX, the useful move is to identify high-frequency or high-impact tasks and ensure they receive direct, reliable paths. Analytics and workflow knowledge should guide the conclusion whenever available.
### Deeper design interpretation
The Pareto principle is useful as a prioritization heuristic: usage and outcome are often unevenly distributed. In products, a small set of workflows may account for a large share of daily activity, support burden, latency cost, or business impact. The exact ratio is empirical and should never be assumed.
For design, the implication is that interface prominence and optimization effort should reflect observed value. High-frequency actions deserve reliable, short paths. High-impact low-frequency actions may also deserve prominence or safeguards despite limited volume.
Layr should combine frequency with consequence. This prevents a purely usage-driven design from burying security, export, recovery, or administrative capabilities that are rare yet essential.
### What the agent should reason about
Use analytics, event logs, support data, role information, or documented workflow priority when available. When frequency is inferred only from placement, reduce confidence. Separate frequency from risk and business criticality.
The agent can also use the principle to prioritize performance work: optimizing the routes and interactions that dominate real usage often produces larger gains than uniform micro-optimization.
### Common failure patterns
- Monthly admin actions occupy prime toolbar space while daily actions are hidden.
- Performance optimization targets rarely visited routes while the core workflow remains slow.
- Repeated high-frequency tasks require unnecessary navigation.
- Product decisions assume an 80/20 split without measurement.
- Rare but critical recovery actions are removed because they are infrequent.
### Audit questions
- Which tasks dominate real usage or outcome?
- Which rare tasks carry disproportionate risk or importance?
- Does interface priority reflect both frequency and consequence?
- Is there evidence for the assumed distribution?
### Example agent finding
> **Medium — Daily creation is hidden while monthly administration is primary.** Event telemetry shows “Create record” is the most frequent action, yet it sits in a secondary menu while five admin controls occupy the persistent toolbar. Promote creation to the direct toolbar and move low-frequency administration into the stable secondary menu.
### Agent directive
> Prioritize observed high-frequency and high-impact tasks. Never assume an 80/20 distribution without evidence.
### Apply this when
- Navigation, dashboards, toolbars, command menus, mobile layouts, onboarding, performance work, and design-system prioritization.
### Observable signals
- Rare actions occupy the most prominent area while frequent actions are hidden.
- Performance effort is spread evenly across routes despite a small set of dominant workflows.
- The same high-frequency task requires repeated navigation through low-value screens.
- Product analytics show concentrated usage that the interface hierarchy does not reflect.
### Recommended actions
- Keep frequent actions easy to reach and stable.
- Allocate optimization effort according to measured usage and consequence.
- Move rare controls to secondary surfaces while preserving discoverability.
- Use telemetry, support data, or task research when available.
### Do not over-apply
Do not use frequency to suppress critical low-frequency actions such as security, data export, emergency controls, or accessibility needs. Impact matters alongside volume.
### Example
**Weak:** A dashboard reserves its primary toolbar for five administrative actions used monthly while the daily create and search actions are hidden in menus.
**Stronger:** Daily actions are directly available; administrative tools remain accessible in a predictable secondary location.
### Evaluation notes
- **Default severity:** Medium when hierarchy works against repeated tasks; high for high-impact workflows.
- **Typical confidence:** High with telemetry; low to medium when frequency is inferred.
- **Primary evidence:** Analytics, event frequency, task research, support data, navigation hierarchy.
- **Related rules:** Hick's Law, Fitts's Law, Selective Attention, Doherty Threshold
### References
- [Laws of UX — Pareto Principle](https://lawsofux.com/pareto-principle/)
## Related rules
- [Hick's Law](/__layr/pages/reference/hicks-law.md)
- [Fitts's Law](/__layr/pages/reference/fitts-law.md)
- [Selective Attention](/__layr/pages/reference/selective-attention.md)
- [Doherty Threshold](/__layr/pages/reference/doherty-threshold.md)
## Agent guidance
Review criteria, the finding contract a report must use, and worked examples.
Established principle; Layr interpretation and agent guidance. Category: Decision, Simplicity & Familiarity.
## Retrieve
- Canonical page: https://layr.design/reference/pareto-principle
- Markdown for agents: https://layr.design/__layr/pages/reference/pareto-principle.md
- Reference map: https://layr.design/llms.txt
- Route index: https://layr.design/__layr/routes.toon
## Rule object
```yaml
rule:
id: "pareto-principle"
title: "Pareto Principle"
category: "Decision, Simplicity & Familiarity"
origin: established
canonical_url: "https://layr.design/reference/pareto-principle"
principle: "A minority of features, actions, or causes often account for a disproportionate share of use or outcomes; the exact ratio is context-dependent."
directive: "Prioritize observed high-frequency and high-impact tasks. Never assume an 80/20 distribution without evidence."
applies_when:
- "Navigation, dashboards, toolbars, command menus, mobile layouts, onboarding, performance work, and design-system prioritization."
observable_signals:
- "Rare actions occupy the most prominent area while frequent actions are hidden."
- "Performance effort is spread evenly across routes despite a small set of dominant workflows."
- "The same high-frequency task requires repeated navigation through low-value screens."
- "Product analytics show concentrated usage that the interface hierarchy does not reflect."
audit_questions:
- "Which tasks dominate real usage or outcome?"
- "Which rare tasks carry disproportionate risk or importance?"
- "Does interface priority reflect both frequency and consequence?"
- "Is there evidence for the assumed distribution?"
recommended_actions:
- "Keep frequent actions easy to reach and stable."
- "Allocate optimization effort according to measured usage and consequence."
- "Move rare controls to secondary surfaces while preserving discoverability."
- "Use telemetry, support data, or task research when available."
avoid_when:
- "Do not use frequency to suppress critical low-frequency actions such as security, data export, emergency controls, or accessibility needs. Impact matters alongside volume."
common_failure_patterns:
- "Monthly admin actions occupy prime toolbar space while daily actions are hidden."
- "Performance optimization targets rarely visited routes while the core workflow remains slow."
- "Repeated high-frequency tasks require unnecessary navigation."
- "Product decisions assume an 80/20 split without measurement."
- "Rare but critical recovery actions are removed because they are infrequent."
evidence_types:
- "Analytics"
- "event frequency"
- "task research"
- "support data"
- "navigation hierarchy"
default_severity: "Medium when hierarchy works against repeated tasks; high for high-impact workflows."
typical_confidence: "High with telemetry; low to medium when frequency is inferred."
related_rules:
- { id: "hicks-law", title: "Hick's Law", url: "https://layr.design/reference/hicks-law" }
- { id: "fitts-law", title: "Fitts's Law", url: "https://layr.design/reference/fitts-law" }
- { id: "selective-attention", title: "Selective Attention", url: "https://layr.design/reference/selective-attention" }
- { id: "doherty-threshold", title: "Doherty Threshold", url: "https://layr.design/reference/doherty-threshold" }
```
## What to reason about
Use analytics, event logs, support data, role information, or documented workflow priority when available. When frequency is inferred only from placement, reduce confidence. Separate frequency from risk and business criticality. The agent can also use the principle to prioritize performance work: optimizing the routes and interactions that dominate real usage often produces larger gains than uniform micro-optimization.
## Routing
Route a review here when the user must choose between alternatives, learn an unfamiliar control, navigate competing actions, or configure a system before reaching value. Inspect the structure of the decision before recommending fewer options.
## Review procedure
For every finding:
1. Identify the exact component, state, route, or interaction.
2. State the observable evidence.
3. Name the principle that applies.
4. Explain the user consequence in the current context.
5. Estimate severity from the consequence, frequency, and reversibility.
6. Recommend the smallest change that addresses the issue while preserving the product's existing design system.
7. Lower confidence when intent, frequency, audience, device, or product constraints must be inferred.
8. Do not produce generic advice such as "improve hierarchy" or "make this clearer" without specifying what is wrong and why.
## Finding contract — emit exactly this shape
```yaml
finding:
rule_id: string
location: string
evidence:
- observable fact
impact: string
severity: low | medium | high | critical
confidence: low | medium | high
recommendation:
change: string
rationale: string
preserve:
- existing design-system behavior
- valid product constraints
```
## Example finding for this rule
Medium — Daily creation is hidden while monthly administration is primary. Event telemetry shows “Create record” is the most frequent action, yet it sits in a secondary menu while five admin controls occupy the persistent toolbar. Promote creation to the direct toolbar and move low-frequency administration into the stable secondary menu.
## Code reference
The same principle as markup. Compare the structure, not the class names.
```html