---
title: "Occam's Razor"
source: "/reference/occams-razor"
description: "When several designs solve the same problem equally well, prefer the one that introduces fewer assumptions, mechanisms, and moving parts."
---
# Occam's Razor
When several designs solve the same problem equally well, prefer the one that introduces fewer assumptions, mechanisms, and moving parts.
### Principle
When several designs solve the same problem equally well, prefer the one that introduces fewer assumptions, mechanisms, and moving parts.
### Why it matters
In product design, simplicity is valuable when it removes unnecessary concepts, states, steps, or special cases while preserving capability. The principle is comparative: it helps choose between solutions that perform equally well. A simpler-looking UI can still hide greater operational complexity or reduce user control.
### Deeper design interpretation
Occam's Razor is useful when comparing solutions that satisfy the same requirements. The preferable design is the one that introduces fewer concepts, exceptions, states, and mechanisms without losing capability or correctness. This is especially relevant in design systems, where historical duplication can create several ways to solve the same problem.
Simplicity should be evaluated across the product lifecycle, not only the rendered screen. A visually minimal interaction may hide complicated behavior, surprise users, or require more maintenance. Conversely, a slightly richer control can make state and consequence much clearer.
Layr should therefore evaluate conceptual simplicity, interaction simplicity, and implementation simplicity together when enough evidence is available.
### What the agent should reason about
Identify duplicated concepts, redundant states, repeated steps, and special-case components. Verify that a proposed consolidation preserves the domain distinctions that matter. The agent should explain which complexity disappears and which capability remains.
Do not recommend reuse merely because two components look similar; their semantics may require separate primitives.
### Common failure patterns
- Separate component families exist for nearly identical interaction structures.
- Flows contain steps with no unique information, decision, or safety value.
- New terminology duplicates an existing concept.
- Historical edge cases become permanent UI branches.
- Decorative abstraction makes a direct action harder to understand.
### Audit questions
- Are there multiple mechanisms solving the same user problem?
- Does each state or step contribute unique value?
- Would consolidation preserve semantics and accessibility?
- Is the “simpler” design actually simpler for users, implementation, and maintenance?
### Example agent finding
> **Low — Three modal primitives implement the same interaction contract.** Confirmation, warning, and review dialogs differ mainly in icon and tone but maintain separate focus and sizing logic. Consolidate them into one accessible dialog primitive with explicit semantic variants while preserving their distinct content requirements.
### Agent directive
> Prefer the least complicated solution that fully satisfies the user, accessibility, and system requirements. Do not simplify by deleting necessary capability or context.
### Apply this when
- Information architecture, component variants, flow design, settings, navigation, modal sequences, onboarding, and design-system consolidation.
### Observable signals
- Two components solve the same job with different APIs or interaction models.
- A flow contains steps that collect no unique information or provide no decision value.
- Special-case UI exists because of implementation history rather than user need.
- A new concept is introduced where an existing product concept could represent the same thing.
- A decorative layer adds explanation requirements without adding task value.
### Recommended actions
- Remove redundant states, screens, controls, and component variants.
- Reuse existing concepts where their semantics fit.
- Combine duplicated interaction patterns after verifying edge cases.
- Prefer direct language and explicit outcomes over clever abstractions.
### Do not over-apply
Do not collapse distinct concepts merely because they look similar. The simpler solution must still model the domain correctly.
### Example
**Weak:** A product has separate modal systems for confirmation, warning, and review even though the interaction structure is the same and only content/severity differs.
**Stronger:** One accessible dialog primitive supports well-defined variants while preserving the distinct semantics of each use case.
### Evaluation notes
- **Default severity:** Low to medium; high when complexity causes recurring errors or maintenance-driven inconsistency.
- **Typical confidence:** High for duplicated mechanisms; medium for architectural simplification.
- **Primary evidence:** Component inventory, flow steps, state machines, duplicated concepts, requirements.
- **Related rules:** Law of Prägnanz, Tesler's Law, Cognitive Load, Pareto Principle
### References
- [Laws of UX — Occam's Razor](https://lawsofux.com/occams-razor/)
## Related rules
- [Law of Prägnanz](/__layr/pages/reference/law-of-pragnanz.md)
- [Tesler's Law](/__layr/pages/reference/teslers-law.md)
- [Cognitive Load](/__layr/pages/reference/cognitive-load.md)
- [Pareto Principle](/__layr/pages/reference/pareto-principle.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/occams-razor
- Markdown for agents: https://layr.design/__layr/pages/reference/occams-razor.md
- Reference map: https://layr.design/llms.txt
- Route index: https://layr.design/__layr/routes.toon
## Rule object
```yaml
rule:
id: "occams-razor"
title: "Occam's Razor"
category: "Decision, Simplicity & Familiarity"
origin: established
canonical_url: "https://layr.design/reference/occams-razor"
principle: "When several designs solve the same problem equally well, prefer the one that introduces fewer assumptions, mechanisms, and moving parts."
directive: "Prefer the least complicated solution that fully satisfies the user, accessibility, and system requirements. Do not simplify by deleting necessary capability or context."
applies_when:
- "Information architecture, component variants, flow design, settings, navigation, modal sequences, onboarding, and design-system consolidation."
observable_signals:
- "Two components solve the same job with different APIs or interaction models."
- "A flow contains steps that collect no unique information or provide no decision value."
- "Special-case UI exists because of implementation history rather than user need."
- "A new concept is introduced where an existing product concept could represent the same thing."
- "A decorative layer adds explanation requirements without adding task value."
audit_questions:
- "Are there multiple mechanisms solving the same user problem?"
- "Does each state or step contribute unique value?"
- "Would consolidation preserve semantics and accessibility?"
- "Is the “simpler” design actually simpler for users, implementation, and maintenance?"
recommended_actions:
- "Remove redundant states, screens, controls, and component variants."
- "Reuse existing concepts where their semantics fit."
- "Combine duplicated interaction patterns after verifying edge cases."
- "Prefer direct language and explicit outcomes over clever abstractions."
avoid_when:
- "Do not collapse distinct concepts merely because they look similar. The simpler solution must still model the domain correctly."
common_failure_patterns:
- "Separate component families exist for nearly identical interaction structures."
- "Flows contain steps with no unique information, decision, or safety value."
- "New terminology duplicates an existing concept."
- "Historical edge cases become permanent UI branches."
- "Decorative abstraction makes a direct action harder to understand."
evidence_types:
- "Component inventory"
- "flow steps"
- "state machines"
- "duplicated concepts"
- "requirements"
default_severity: "Low to medium; high when complexity causes recurring errors or maintenance-driven inconsistency."
typical_confidence: "High for duplicated mechanisms; medium for architectural simplification."
related_rules:
- { id: "law-of-pragnanz", title: "Law of Prägnanz", url: "https://layr.design/reference/law-of-pragnanz" }
- { id: "teslers-law", title: "Tesler's Law", url: "https://layr.design/reference/teslers-law" }
- { id: "cognitive-load", title: "Cognitive Load", url: "https://layr.design/reference/cognitive-load" }
- { id: "pareto-principle", title: "Pareto Principle", url: "https://layr.design/reference/pareto-principle" }
```
## What to reason about
Identify duplicated concepts, redundant states, repeated steps, and special-case components. Verify that a proposed consolidation preserves the domain distinctions that matter. The agent should explain which complexity disappears and which capability remains. Do not recommend reuse merely because two components look similar; their semantics may require separate primitives.
## 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
Low — Three modal primitives implement the same interaction contract. Confirmation, warning, and review dialogs differ mainly in icon and tone but maintain separate focus and sizing logic. Consolidate them into one accessible dialog primitive with explicit semantic variants while preserving their distinct content requirements.
## Code reference
The same principle as markup. Compare the structure, not the class names.
```html
Design systemDialog components
ConfirmContinue?OK
Warning!Please review.Proceed
ReviewCheck details.Confirm
3 component families · 1 interaction structure
```
```html
Design systemDialog
Archive this project?Members keep read access. You can restore it from the archive at any time.