---
title: "Decision, Simplicity & Familiarity"
source: "/reference/decision-simplicity-familiarity"
description: "Rules for structuring choices, managing complexity, using familiar conventions, and helping users reach correct decisions without unnecessary interpretation."
---
# Decision, Simplicity & Familiarity

Rules for structuring choices, managing complexity, using familiar conventions, and helping users reach correct decisions without unnecessary interpretation.

> Rules for structuring choices, managing complexity, using familiar conventions, and helping users reach correct decisions without unnecessary interpretation.

Good decision design is mostly information architecture. Users need to understand what choices exist, how those choices differ, which ones matter now, and what will happen after selection. Raw option count is only one part of the problem.

Layr should look for decision cost created by ambiguous labels, competing priority, unfamiliar conventions, redundant mechanisms, implementation-driven complexity, and premature configuration. Familiar patterns reduce learning cost, while well-placed novelty can still be valuable when it improves the task enough to justify learning it.

This category also defines a strict boundary around "simplicity." Simpler interfaces are not automatically better. A design is simpler when it removes unnecessary concepts and work while preserving the information and controls required for correct, informed action.

## Principles in this category

- [Choice Overload](/__layr/pages/reference/choice-overload.md) — A large or poorly structured set of alternatives can make selection slower, more stressful, or easier to abandon.
- [Hick's Law](/__layr/pages/reference/hicks-law.md) — Decision time tends to increase as the number of plausible choices and the uncertainty between them increase.
- [Jakob's Law](/__layr/pages/reference/jakobs-law.md) — Users bring expectations learned from other products and usually benefit when familiar conventions continue to behave in familiar ways.
- [Occam's Razor](/__layr/pages/reference/occams-razor.md) — When several designs solve the same problem equally well, prefer the one that introduces fewer assumptions, mechanisms, and moving parts.
- [Pareto Principle](/__layr/pages/reference/pareto-principle.md) — A minority of features, actions, or causes often account for a disproportionate share of use or outcomes; the exact ratio is context-dependent.
- [Paradox of the Active User](/__layr/pages/reference/paradox-of-the-active-user.md) — People often prefer to begin doing the task immediately rather than first investing time in manuals or complete instruction.
- [Tesler's Law](/__layr/pages/reference/teslers-law.md) — Some complexity belongs to the problem itself; design determines where that complexity is handled and who must carry it.

## Category model

Decision quality depends on how alternatives are structured. The user needs enough information to understand the available paths, eliminate irrelevant options, compare meaningful differences, and predict the consequence of choosing. Good design shortens this reasoning without withholding material context.

For Layr, “simple” should mean fewer unnecessary concepts and less unnecessary work. It should never mean fewer capabilities by default. A dense expert interface may be simple for its audience because the structure is stable, familiar, and direct. A sparse onboarding screen may be complex if every label requires interpretation.

### Agent evidence hierarchy

When reviewing decisions, prioritize observable choice structure, labels, action priority, defaults, navigation cost, frequency data, and consequence. Avoid recommendations based on option count alone. When familiarity is part of the finding, cite the relevant platform, domain, or product convention rather than assuming universal behavior.

## Category review questions

- Which choices are truly competing at this moment, and can users distinguish them quickly?
- Are common tasks represented with familiar labels and interaction patterns?
- Has necessary domain complexity been organized, or merely hidden?
- Do high-frequency or high-impact actions receive appropriate priority?
- Can a new user begin productive work without consuming unnecessary instruction first?

## How agents should use this file

Treat these rules as review criteria, not as automatic violations. A finding is valid only when the interface provides observable evidence that the principle applies and that the current implementation creates a meaningful usability, comprehension, accessibility, or interaction cost.

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

```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
```

A clean interface can legitimately produce zero findings.

## Agent routing hints

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.