---
title: "Mental Model"
source: "/reference/mental-model"
description: "People operate a product through an internal explanation of what the system is, what its objects mean, and what actions will cause."
---
# Mental Model
People operate a product through an internal explanation of what the system is, what its objects mean, and what actions will cause.
### Principle
People operate a product through an internal explanation of what the system is, what its objects mean, and what actions will cause.
### Why it matters
A mental model lets users predict behavior without relearning every screen. Object names, navigation, state transitions, cause-and-effect, and persistence rules all contribute to that model. Conflicts are expensive: if 'archive' sometimes hides an item and sometimes deletes access, or if a workspace behaves differently depending on an invisible backend state, users cannot make reliable predictions.
### Deeper design interpretation
A mental model is the user's working explanation of how the product behaves. It includes objects, ownership, cause and effect, persistence, permissions, navigation, and the meaning of actions. Once that model becomes reliable, users can predict behavior without reading instructions for every screen.
Mental-model failures occur when the product's visible structure conflicts with its underlying behavior. A button called “disconnect” may sound reversible while actually deleting imported data. A workspace may appear to own a record that is globally shared. A toggle may look local while changing organization-wide policy. These mismatches produce errors because the user acts rationally according to the model the interface taught them.
Layr should inspect consistency across routes and states, not only within one screen. Many mental-model problems appear when the same concept behaves differently in two parts of the product.
### What the agent should reason about
Map visible nouns and verbs to real data entities and state transitions. Compare action labels with actual consequences. Look for hidden conditions that alter behavior without being surfaced to the user.
The agent should prefer outcome language over implementation language. “Stop future sync” is often clearer than “disconnect connector” when the latter has ambiguous data consequences.
### Common failure patterns
- One object is called by several names in different areas.
- Actions with the same label have different consequences.
- Ownership boundaries in the UI do not match permissions or data scope.
- Backend concepts leak into labels that users must decode.
- Consequential hidden state changes what an otherwise familiar action will do.
### Audit questions
- What model of the system is this screen teaching?
- Can users predict the result of each action from its label and context?
- Are object ownership and persistence rules visible where they matter?
- Does the same concept behave consistently across the product?
### Example agent finding
> **High — “Disconnect” has incompatible meanings across integrations.** In the CRM connector it only stops future sync; in the billing connector it also deletes imported records. Use outcome-specific labels and confirmation copy so users do not transfer the safer mental model from one integration to the other.
### Agent directive
> Evaluate whether labels, structure, and behavior support a stable model that a user can carry across the product.
### Apply this when
- Navigation, data models, permissions, workflows, editors, multi-workspace products, sync, imports, destructive actions, and settings.
### Observable signals
- The same object has different names on different routes.
- An action has different consequences depending on hidden state.
- UI hierarchy does not match object ownership or data relationships.
- Users must understand backend implementation details to predict behavior.
- A control's label describes implementation rather than user outcome.
### Recommended actions
- Choose product language around user-recognizable entities and outcomes.
- Keep object ownership and relationships visible where they affect behavior.
- Use consistent action semantics across surfaces.
- Expose consequential hidden state before users act.
### Do not over-apply
Users can hold several mental models for different contexts. Do not force identical behavior across genuinely different domains; make the distinction explicit.
### Example
**Weak:** A button labeled 'Disconnect' deletes imported records in one integration but only stops future sync in another.
**Stronger:** Actions state their outcome consistently, and any integration-specific consequence is explained before confirmation.
### Evaluation notes
- **Default severity:** High when mismatches cause data loss, permission mistakes, or repeated errors; medium otherwise.
- **Typical confidence:** High when inconsistent semantics are observable.
- **Primary evidence:** Labels, data relationships, action handlers, state changes, navigation structure.
- **Related rules:** Jakob's Law, Law of Similarity, Tesler's Law, Paradox of the Active User
### References
- [Laws of UX — Mental Model](https://lawsofux.com/mental-model/)
- [Nielsen Norman Group — Mental Models and User Experience Design](https://www.nngroup.com/articles/mental-models/)
## Related rules
- [Jakob's Law](/__layr/pages/reference/jakobs-law.md)
- [Law of Similarity](/__layr/pages/reference/law-of-similarity.md)
- [Tesler's Law](/__layr/pages/reference/teslers-law.md)
- [Paradox of the Active User](/__layr/pages/reference/paradox-of-the-active-user.md)
## Agent guidance
Review criteria, the finding contract a report must use, and worked examples.
Established principle; Layr interpretation and agent guidance. Category: Memory & Cognition.
## Retrieve
- Canonical page: https://layr.design/reference/mental-model
- Markdown for agents: https://layr.design/__layr/pages/reference/mental-model.md
- Reference map: https://layr.design/llms.txt
- Route index: https://layr.design/__layr/routes.toon
## Rule object
```yaml
rule:
id: "mental-model"
title: "Mental Model"
category: "Memory & Cognition"
origin: established
canonical_url: "https://layr.design/reference/mental-model"
principle: "People operate a product through an internal explanation of what the system is, what its objects mean, and what actions will cause."
directive: "Evaluate whether labels, structure, and behavior support a stable model that a user can carry across the product."
applies_when:
- "Navigation, data models, permissions, workflows, editors, multi-workspace products, sync, imports, destructive actions, and settings."
observable_signals:
- "The same object has different names on different routes."
- "An action has different consequences depending on hidden state."
- "UI hierarchy does not match object ownership or data relationships."
- "Users must understand backend implementation details to predict behavior."
- "A control's label describes implementation rather than user outcome."
audit_questions:
- "What model of the system is this screen teaching?"
- "Can users predict the result of each action from its label and context?"
- "Are object ownership and persistence rules visible where they matter?"
- "Does the same concept behave consistently across the product?"
recommended_actions:
- "Choose product language around user-recognizable entities and outcomes."
- "Keep object ownership and relationships visible where they affect behavior."
- "Use consistent action semantics across surfaces."
- "Expose consequential hidden state before users act."
avoid_when:
- "Users can hold several mental models for different contexts. Do not force identical behavior across genuinely different domains; make the distinction explicit."
common_failure_patterns:
- "One object is called by several names in different areas."
- "Actions with the same label have different consequences."
- "Ownership boundaries in the UI do not match permissions or data scope."
- "Backend concepts leak into labels that users must decode."
- "Consequential hidden state changes what an otherwise familiar action will do."
evidence_types:
- "Labels"
- "data relationships"
- "action handlers"
- "state changes"
- "navigation structure"
default_severity: "High when mismatches cause data loss, permission mistakes, or repeated errors; medium otherwise."
typical_confidence: "High when inconsistent semantics are observable."
related_rules:
- { id: "jakobs-law", title: "Jakob's Law", url: "https://layr.design/reference/jakobs-law" }
- { id: "law-of-similarity", title: "Law of Similarity", url: "https://layr.design/reference/law-of-similarity" }
- { id: "teslers-law", title: "Tesler's Law", url: "https://layr.design/reference/teslers-law" }
- { id: "paradox-of-the-active-user", title: "Paradox of the Active User", url: "https://layr.design/reference/paradox-of-the-active-user" }
```
## What to reason about
Map visible nouns and verbs to real data entities and state transitions. Compare action labels with actual consequences. Look for hidden conditions that alter behavior without being surfaced to the user. The agent should prefer outcome language over implementation language. “Stop future sync” is often clearer than “disconnect connector” when the latter has ambiguous data consequences.
## Routing
Route a review here when the user must remember, infer, translate, reconcile, or reconstruct information. These rules are especially relevant when the system already possesses context that the interface fails to expose.
## 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
High — “Disconnect” has incompatible meanings across integrations. In the CRM connector it only stops future sync; in the billing connector it also deletes imported records. Use outcome-specific labels and confirmation copy so users do not transfer the safer mental model from one integration to the other.
## Code reference
The same principle as markup. Compare the structure, not the class names.
```html
SettingsConnected tools
Integrations
Calendar syncDisconnect
actually: stops future sync
CRM importDisconnect
actually: deletes 4,182 records
One label · two consequences · hidden state decides
```
```html
SettingsConnected tools
Integrations
Calendar syncStop future sync
Past events stay in the workspace.
CRM importRemove imported data
Deletes 4,182 records. Asks for confirmation first.