#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