---
title: "Hick's Law"
source: "/reference/hicks-law"
description: "Decision time tends to increase as the number of plausible choices and the uncertainty between them increase."
---
# Hick's Law
Decision time tends to increase as the number of plausible choices and the uncertainty between them increase.
### Principle
Decision time tends to increase as the number of plausible choices and the uncertainty between them increase.
### Why it matters
Hick's Law is useful for interaction design when users must select among alternatives. The strongest design response is often to improve information architecture, defaults, prioritization, or filtering rather than simply delete options. Familiarity and unequal probability also matter: a common action can remain fast to find inside a large set when placement and labeling are stable.
### Deeper design interpretation
Hick's Law describes the relationship between choice uncertainty and decision time. In interface work, its most useful implication is that simultaneous competition matters. Ten actions distributed across clear categories can be easier than five unrelated actions presented with equal prominence.
The design response should optimize the decision path as a whole. Hiding actions behind additional menus can reduce the visible choice set while increasing navigation, memory, and discovery cost. Familiarity and probability also matter: a common action remains easy to find inside a large set when placement and labeling are stable.
Layr should therefore identify the real decision point before recommending consolidation.
### What the agent should reason about
Count only plausible alternatives competing in the current context. Use analytics or workflow evidence when available to distinguish frequent from rare actions. Evaluate whether categories, defaults, labels, and priority reduce uncertainty.
The agent should avoid “too many buttons” findings unless it can explain how the simultaneous alternatives slow or confuse the current task.
### Common failure patterns
- Every row action is permanently visible with equal weight.
- Rare and frequent commands compete in the same toolbar.
- Long menus have no grouping despite stable categories.
- Labels are so similar that users must read descriptions before choosing.
- Overflow menus are used excessively, forcing repeated extra navigation for common actions.
### Audit questions
- Which choices are truly competing right now?
- Are common actions visually and spatially prioritized?
- Could grouping or labeling reduce uncertainty without hiding capability?
- Does the proposed simplification reduce total task time or only clean the screenshot?
### Example agent finding
> **Medium — Nine row actions compete with equal prominence.** The table exposes nine unlabeled icons even though usage data identifies “Open” and “Assign” as the dominant actions. Keep those two direct, group the remaining low-frequency commands in a labeled overflow menu, and preserve keyboard access.
### Agent directive
> Optimize the decision structure, not the option count in isolation. Identify which choices are genuinely competing at the same moment.
### Apply this when
- Menus, navigation, command surfaces, filter panels, onboarding decisions, pricing, action menus, and branching workflows.
### Observable signals
- Many actions are presented with equal prominence.
- Rare and common actions compete in the same primary surface.
- A menu is long and ungrouped despite stable categories.
- Users must read explanatory text for each option before distinguishing them.
- Several choices lead to nearly identical outcomes.
### Recommended actions
- Prioritize frequent and contextually relevant actions.
- Group alternatives into recognizable categories.
- Move rare actions into secondary menus without making them undiscoverable.
- Use defaults, search, and filters when they reduce uncertainty.
- Merge truly redundant choices.
### Do not over-apply
Do not use Hick's Law to justify hiding everything behind menus. Additional navigation steps add their own cost. Optimize the full task, not one screen.
### Example
**Weak:** A table row exposes nine equal icon buttons, several of which are rarely used and visually ambiguous.
**Stronger:** The two frequent actions remain visible and labeled when space allows; less common actions live in a clearly named overflow menu.
### Evaluation notes
- **Default severity:** Medium; high when decision delay or wrong action affects core workflows.
- **Typical confidence:** High when simultaneous choice sets are observable.
- **Primary evidence:** Action count, frequency data when available, labels, hierarchy, task context.
- **Related rules:** Choice Overload, Selective Attention, Pareto Principle, Fitts's Law
### References
- [Laws of UX — Hick's Law](https://lawsofux.com/hicks-law/)
## Related rules
- [Choice Overload](/__layr/pages/reference/choice-overload.md)
- [Selective Attention](/__layr/pages/reference/selective-attention.md)
- [Pareto Principle](/__layr/pages/reference/pareto-principle.md)
- [Fitts's Law](/__layr/pages/reference/fitts-law.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/hicks-law
- Markdown for agents: https://layr.design/__layr/pages/reference/hicks-law.md
- Reference map: https://layr.design/llms.txt
- Route index: https://layr.design/__layr/routes.toon
## Rule object
```yaml
rule:
id: "hicks-law"
title: "Hick's Law"
category: "Decision, Simplicity & Familiarity"
origin: established
canonical_url: "https://layr.design/reference/hicks-law"
principle: "Decision time tends to increase as the number of plausible choices and the uncertainty between them increase."
directive: "Optimize the decision structure, not the option count in isolation. Identify which choices are genuinely competing at the same moment."
applies_when:
- "Menus, navigation, command surfaces, filter panels, onboarding decisions, pricing, action menus, and branching workflows."
observable_signals:
- "Many actions are presented with equal prominence."
- "Rare and common actions compete in the same primary surface."
- "A menu is long and ungrouped despite stable categories."
- "Users must read explanatory text for each option before distinguishing them."
- "Several choices lead to nearly identical outcomes."
audit_questions:
- "Which choices are truly competing right now?"
- "Are common actions visually and spatially prioritized?"
- "Could grouping or labeling reduce uncertainty without hiding capability?"
- "Does the proposed simplification reduce total task time or only clean the screenshot?"
recommended_actions:
- "Prioritize frequent and contextually relevant actions."
- "Group alternatives into recognizable categories."
- "Move rare actions into secondary menus without making them undiscoverable."
- "Use defaults, search, and filters when they reduce uncertainty."
- "Merge truly redundant choices."
avoid_when:
- "Do not use Hick's Law to justify hiding everything behind menus. Additional navigation steps add their own cost. Optimize the full task, not one screen."
common_failure_patterns:
- "Every row action is permanently visible with equal weight."
- "Rare and frequent commands compete in the same toolbar."
- "Long menus have no grouping despite stable categories."
- "Labels are so similar that users must read descriptions before choosing."
- "Overflow menus are used excessively, forcing repeated extra navigation for common actions."
evidence_types:
- "Action count"
- "frequency data when available"
- "labels"
- "hierarchy"
- "task context"
default_severity: "Medium; high when decision delay or wrong action affects core workflows."
typical_confidence: "High when simultaneous choice sets are observable."
related_rules:
- { id: "choice-overload", title: "Choice Overload", url: "https://layr.design/reference/choice-overload" }
- { id: "selective-attention", title: "Selective Attention", url: "https://layr.design/reference/selective-attention" }
- { id: "pareto-principle", title: "Pareto Principle", url: "https://layr.design/reference/pareto-principle" }
- { id: "fitts-law", title: "Fitts's Law", url: "https://layr.design/reference/fitts-law" }
```
## What to reason about
Count only plausible alternatives competing in the current context. Use analytics or workflow evidence when available to distinguish frequent from rare actions. Evaluate whether categories, defaults, labels, and priority reduce uncertainty. The agent should avoid “too many buttons” findings unless it can explain how the simultaneous alternatives slow or confuse the current task.
## 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 — Nine row actions compete with equal prominence. The table exposes nine unlabeled icons even though usage data identifies “Open” and “Assign” as the dominant actions. Keep those two direct, group the remaining low-frequency commands in a labeled overflow menu, and preserve keyboard access.
## Code reference
The same principle as markup. Compare the structure, not the class names.
```html