#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