---
title: "Law of Prägnanz"
source: "/reference/law-of-pragnanz"
description: "When a visual structure is ambiguous, people tend to resolve it into the simplest coherent interpretation available."
---
# Law of Prägnanz

When a visual structure is ambiguous, people tend to resolve it into the simplest coherent interpretation available.



### Principle

When a visual structure is ambiguous, people tend to resolve it into the simplest coherent interpretation available.

### Why it matters

Interfaces are easier to parse when shapes, grouping, labels, and interaction patterns form an obvious structure. Ambiguous ornament, irregular alignment, overlapping affordances, and unnecessary shape variation force users to interpret the composition before acting. Simplicity here means perceptual clarity, not an absence of features.

### Deeper design interpretation

People prefer visual structures that can be interpreted quickly and coherently. In product interfaces, this means users should be able to form a stable explanation of the composition without decoding unnecessary shape variation, decoration, or ambiguous geometry. The principle is about perceptual economy: the interface should spend visual complexity where that complexity communicates something real.

A common misuse is to equate perceptual simplicity with removing information. A professional dashboard may contain many controls and still be perceptually clear when those controls follow a consistent grammar. Conversely, a sparse page can be perceptually complex when every element uses a different shape, alignment rule, or interaction treatment.

Layr should therefore ask whether the interface offers one obvious structural interpretation. When several visual explanations are plausible, users spend time deciding which pattern to trust.

### What the agent should reason about

Inspect alignment, geometry, repeated shapes, borders, state transitions, and whether decorative elements can be mistaken for interactive ones. The agent should prefer simplification of the visual grammar before recommending feature removal.

When a component changes shape across states, verify that the change communicates state rather than introducing a new pattern. Consistency across state transitions is often more important than absolute minimalism.

### Common failure patterns

- Decorative pills resemble filters or status chips.
- A card changes layout dramatically when selected, making it appear like a different component.
- Similar data is represented through unrelated visual forms on the same screen.
- Multiple border styles imply levels of hierarchy that do not exist.
- Icons and ornaments require explanatory text because their meaning is visually ambiguous.

### Audit questions

- What is the simplest coherent interpretation of the screen?
- Are there visual elements that suggest relationships or actions that do not exist?
- Can repeated components be recognized across states?
- Is complexity coming from the domain or from the interface grammar itself?

### Example agent finding

> **Low — Status pills and filter chips are visually indistinguishable.** Both use the same rounded shape, fill, and hover treatment, but only filters are interactive. Give the two roles distinct interaction cues so the page has one stable interpretation for “clickable chip” versus “informational status.”

### Agent directive

> Prefer the clearest coherent visual interpretation. Reduce ambiguity in shapes, grouping, alignment, and state before removing useful functionality.

### Apply this when

- Complex dashboards, data visualizations, onboarding illustrations, navigation, diagrams, dense control panels, and empty states.
- Interfaces with several competing visual grammars or decorative geometries.

### Observable signals

- Decorative elements can be mistaken for controls or status indicators.
- Multiple shapes or containers imply structure that does not match the content model.
- Irregular alignment makes repeated components look unrelated.
- A component needs explanatory copy because its visible structure is ambiguous.
- State changes alter geometry so strongly that users must relearn the component.

### Recommended actions

- Simplify the visual grammar while retaining required information.
- Use consistent shapes and alignment for repeated semantics.
- Remove decorative boundaries or geometry that create false groups.
- Make interactive and non-interactive objects visibly distinct.

### Do not over-apply

Do not equate simplicity with minimalism. A complex professional task may need dense controls, labels, and status information. Preserve necessary complexity when removing it would make decisions harder.

### Example

**Weak:** A project card uses three different pill shapes, an unlabeled circular status control, and a decorative border that looks selectable.

**Stronger:** Status, metadata, and actions use consistent visual roles, so the card can be understood without decoding decorative elements.

### Evaluation notes

- **Default severity:** Medium when ambiguity changes behavior; low when it adds only perceptual friction.
- **Typical confidence:** Medium; some ambiguity requires contextual judgment.
- **Primary evidence:** Visual grammar, component states, repeated patterns, user task context.
- **Related rules:** Occam's Razor, Tesler's Law, Law of Similarity, Cognitive Load

### References

- [Laws of UX — Law of Prägnanz](https://lawsofux.com/law-of-pragnanz/)

## Related rules

- [Occam's Razor](/__layr/pages/reference/occams-razor.md)
- [Tesler's Law](/__layr/pages/reference/teslers-law.md)
- [Law of Similarity](/__layr/pages/reference/law-of-similarity.md)
- [Cognitive Load](/__layr/pages/reference/cognitive-load.md)

## Agent guidance

Review criteria, the finding contract a report must use, and worked examples.

Established principle; Layr interpretation and agent guidance. Category: Perception & Visual Hierarchy.

## Retrieve
- Canonical page: https://layr.design/reference/law-of-pragnanz
- Markdown for agents: https://layr.design/__layr/pages/reference/law-of-pragnanz.md
- Reference map: https://layr.design/llms.txt
- Route index: https://layr.design/__layr/routes.toon

## Rule object
```yaml
rule:
  id: "law-of-pragnanz"
  title: "Law of Prägnanz"
  category: "Perception & Visual Hierarchy"
  origin: established
  canonical_url: "https://layr.design/reference/law-of-pragnanz"
  principle: "When a visual structure is ambiguous, people tend to resolve it into the simplest coherent interpretation available."
  directive: "Prefer the clearest coherent visual interpretation. Reduce ambiguity in shapes, grouping, alignment, and state before removing useful functionality."
  applies_when:
    - "Complex dashboards, data visualizations, onboarding illustrations, navigation, diagrams, dense control panels, and empty states."
    - "Interfaces with several competing visual grammars or decorative geometries."
  observable_signals:
    - "Decorative elements can be mistaken for controls or status indicators."
    - "Multiple shapes or containers imply structure that does not match the content model."
    - "Irregular alignment makes repeated components look unrelated."
    - "A component needs explanatory copy because its visible structure is ambiguous."
    - "State changes alter geometry so strongly that users must relearn the component."
  audit_questions:
    - "What is the simplest coherent interpretation of the screen?"
    - "Are there visual elements that suggest relationships or actions that do not exist?"
    - "Can repeated components be recognized across states?"
    - "Is complexity coming from the domain or from the interface grammar itself?"
  recommended_actions:
    - "Simplify the visual grammar while retaining required information."
    - "Use consistent shapes and alignment for repeated semantics."
    - "Remove decorative boundaries or geometry that create false groups."
    - "Make interactive and non-interactive objects visibly distinct."
  avoid_when:
    - "Do not equate simplicity with minimalism. A complex professional task may need dense controls, labels, and status information. Preserve necessary complexity when removing it would make decisions harder."
  common_failure_patterns:
    - "Decorative pills resemble filters or status chips."
    - "A card changes layout dramatically when selected, making it appear like a different component."
    - "Similar data is represented through unrelated visual forms on the same screen."
    - "Multiple border styles imply levels of hierarchy that do not exist."
    - "Icons and ornaments require explanatory text because their meaning is visually ambiguous."
  evidence_types:
    - "Visual grammar"
    - "component states"
    - "repeated patterns"
    - "user task context"
  default_severity: "Medium when ambiguity changes behavior; low when it adds only perceptual friction."
  typical_confidence: "Medium; some ambiguity requires contextual judgment."
  related_rules:
    - { id: "occams-razor", title: "Occam's Razor", url: "https://layr.design/reference/occams-razor" }
    - { id: "teslers-law", title: "Tesler's Law", url: "https://layr.design/reference/teslers-law" }
    - { id: "law-of-similarity", title: "Law of Similarity", url: "https://layr.design/reference/law-of-similarity" }
    - { id: "cognitive-load", title: "Cognitive Load", url: "https://layr.design/reference/cognitive-load" }
```

## What to reason about
Inspect alignment, geometry, repeated shapes, borders, state transitions, and whether decorative elements can be mistaken for interactive ones. The agent should prefer simplification of the visual grammar before recommending feature removal. When a component changes shape across states, verify that the change communicates state rather than introducing a new pattern. Consistency across state transitions is often more important than absolute minimalism.

## Routing
Route a review here when the evidence is primarily visual: grouping, emphasis, state differentiation, alignment, salience, relationship, or scan hierarchy. Pair these rules with accessibility checks when color, contrast, focus, or motion affects perception.

## 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 — Status pills and filter chips are visually indistinguishable. Both use the same rounded shape, fill, and hover treatment, but only filters are interactive. Give the two roles distinct interaction cues so the page has one stable interpretation for “clickable chip” versus “informational status.”

## Code reference

The same principle as markup. Compare the structure, not the class names.

```html
<!-- weak -->
<div class="example-ui example-ui-weak">
  <div class="scene-chrome">
    <span class="scene-chrome-app">Projects</span>
    <span class="scene-chrome-view">Board</span>
  </div>
  <div class="scene-body">
    <div class="scene-panel scene-panel-decorated">
      <div class="scene-row">
        <span class="scene-shape-pill">Open</span>
        <span class="scene-shape-rect">New</span>
        <span class="scene-shape-cut">Q3</span>
        <span class="scene-shape-dot"></span>
      </div>
      <span class="scene-buried-title">Atlas redesign</span>
      <div class="scene-row scene-row-muted">
        <span class="scene-meta">Updated 12 min ago</span>
        <span class="scene-shape-frame">⋯</span>
      </div>
    </div>
    <div class="scene-panel scene-panel-decorated">
      <div class="scene-row">
        <span class="scene-shape-cut">Blocked</span>
        <span class="scene-shape-dot"></span>
        <span class="scene-shape-rect">P1</span>
      </div>
      <span class="scene-buried-title">Billing migration</span>
      <div class="scene-row scene-row-muted">
        <span class="scene-meta">Updated 2 days ago</span>
        <span class="scene-shape-frame">⋯</span>
      </div>
    </div>
    <span class="scene-note">4 shape families · 2 unlabelled controls · the card border looks selectable</span>
  </div>
</div>
```

```html
<!-- stronger -->
<div class="example-ui example-ui-strong">
  <div class="scene-chrome">
    <span class="scene-chrome-app">Projects</span>
    <span class="scene-chrome-view">Board</span>
  </div>
  <div class="scene-body">
    <div class="scene-panel">
      <span class="scene-panel-title">Atlas redesign</span>
      <div class="scene-row">
        <span class="scene-tag scene-tag-neutral">In progress</span>
        <span class="scene-meta">Q3 · 8 open tasks</span>
      </div>
      <div class="scene-row scene-row-muted">
        <span class="scene-meta">Updated 12 min ago</span>
      </div>
      <span class="scene-action">Open project</span>
    </div>
    <div class="scene-panel scene-panel-quiet">
      <span class="scene-panel-title">Billing migration</span>
      <div class="scene-row">
        <span class="scene-tag scene-tag-warning">Blocked</span>
        <span class="scene-meta">P1 · 3 open tasks</span>
      </div>
      <div class="scene-row scene-row-muted">
        <span class="scene-meta">Updated 2 days ago</span>
      </div>
      <span class="scene-action">Open project</span>
    </div>
    <span class="scene-note">One shape per role: status, metadata, action</span>
  </div>
</div>
```

```css
/* declarations these studies depend on */
.example-ui { display: grid; grid-template-rows: auto minmax(0, 1fr); min-width: 0; min-height: 17rem; overflow: hidden; border: var(--border-thin) solid var(--color-border-strong); background: var(--color-background); color: var(--color-text); font-size: var(--text-xs); line-height: var(--leading-snug); }
.example-ui .scene-chrome { display: flex; flex-wrap: wrap; align-items: baseline; gap: var(--space-1) var(--space-2); padding: var(--space-2) var(--space-3); border-bottom: var(--border-thin) solid var(--color-border-strong); background: var(--color-surface); }
.example-ui .scene-chrome-app { font-size: var(--text-2xs); font-weight: 600; letter-spacing: var(--tracking-label); text-transform: uppercase; }
.example-ui .scene-chrome-view { color: var(--color-text-tertiary); font-size: var(--text-2xs); }
.example-ui .scene-body { display: grid; align-content: start; gap: var(--space-3); min-width: 0; padding: var(--space-3); }
.example-ui .scene-body:has(> .scene-panel:only-child) { align-content: stretch; }
.example-ui .scene-panel { display: grid; align-content: start; justify-items: start; gap: var(--space-2); min-width: 0; padding: var(--space-3); border: var(--border-thin) solid var(--color-border-strong); background: var(--color-surface-raised); }
.example-ui .scene-panel-quiet { border-color: var(--color-border-subtle); background: var(--color-surface); }
.example-ui .scene-panel-decorated { border-width: 2px; border-radius: var(--radius-lg); }
.example-ui .scene-panel-title { font-size: var(--text-sm); font-weight: 600; letter-spacing: var(--tracking-heading); }
.example-ui .scene-row { display: flex; flex-wrap: wrap; justify-content: space-between; align-items: center; gap: var(--space-1) var(--space-2); width: 100%; min-width: 0; padding-block: var(--space-1); }
.example-ui .scene-panel > .scene-row + .scene-row { border-top: var(--border-thin) solid var(--color-border-subtle); }
.example-ui .scene-row-muted { color: var(--color-text-tertiary); }
.example-ui .scene-meta { color: var(--color-text-tertiary); font-size: var(--text-2xs); }
.example-ui .scene-note { width: 100%; padding-top: var(--space-2); border-top: var(--border-thin) solid var(--color-border-subtle); color: var(--color-text-tertiary); font-family: var(--font-mono); font-size: var(--text-2xs); line-height: var(--leading-snug); }
.example-ui .scene-action { display: inline-flex; align-items: center; justify-content: center; min-height: var(--space-8); padding-inline: var(--space-3); border: var(--border-thin) solid var(--color-border-strong); border-radius: var(--radius-xs); background: var(--color-surface-raised); color: var(--color-text); font-size: var(--text-xs); font-weight: 550; white-space: nowrap; }
.example-ui .scene-tag { display: inline-block; padding: 0 var(--space-2); border: var(--border-thin) solid var(--color-border-strong); color: var(--color-text-secondary); font-size: var(--text-2xs); line-height: 1.6; white-space: nowrap; }
.example-ui .scene-tag-neutral { border-color: var(--color-border-strong); }
.example-ui .scene-tag-warning { border-color: var(--color-caution); color: var(--color-caution); }
.example-ui .scene-shape-pill { padding: 0 var(--space-2); border: var(--border-thin) solid var(--color-border-strong); border-radius: var(--radius-lg); font-size: var(--text-2xs); }
.example-ui .scene-shape-rect { padding: 0 var(--space-2); border: 2px solid var(--color-border-strong); font-size: var(--text-2xs); }
.example-ui .scene-shape-cut { padding: 0 var(--space-2); border: var(--border-thin) solid var(--color-border-strong); border-radius: var(--radius-lg) var(--radius-xs); font-size: var(--text-2xs); }
.example-ui .scene-shape-dot { width: var(--space-5); height: var(--space-5); border: var(--border-thin) solid var(--color-border-strong); border-radius: 50%; }
.example-ui .scene-shape-frame { display: inline-grid; place-items: center; width: var(--space-6); height: var(--space-6); border: var(--border-thin) dashed var(--color-border-strong); border-radius: var(--radius-md); }
.example-ui .scene-buried-title { font-size: var(--text-sm); font-weight: 600; }
.example-ui { min-height: 15rem; }

/* resolved values */
:root {
  --border-thin: 1px;
  --font-mono: "Geist Mono", "SFMono-Regular", Consolas, "Liberation Mono", monospace;
  --leading-snug: 1.35;
  --radius-lg: 10px;
  --radius-md: 6px;
  --radius-xs: 2px;
  --space-1: 0.25rem;
  --space-2: 0.5rem;
  --space-3: 0.75rem;
  --space-5: 1.25rem;
  --space-6: 1.5rem;
  --space-8: 2rem;
  --text-2xs: 0.6875rem;
  --text-sm: 0.875rem;
  --text-xs: 0.75rem;
  --tracking-heading: -0.025em;
  --tracking-label: 0.06em;
}
```

## Weak vs stronger
- Weak: A project card uses three different pill shapes, an unlabeled circular status control, and a decorative border that looks selectable.
- Stronger: Status, metadata, and actions use consistent visual roles, so the card can be understood without decoding decorative elements.

## Reporting rules
- Report only what the interface shows as observable evidence; phrase psychological or motivational effects as possible consequences.
- Returning no finding is a valid result when evidence is insufficient.
