Foundations

Mental Models

How users form internal representations of how a system works, and why your design should match those expectations.

#mental models#expectations#conceptual model#user expectations#familiarity

What is it?

A mental model is the internal representation a user holds about how a system works. When someone uses your product for the first time, they apply their existing mental model — built from prior experience with similar products — to predict how it will behave. When the product matches the mental model, it feels intuitive. When it doesn't, users are confused and need to re-learn.

Why it matters

You cannot change your users' mental models — you can only align with them or fight them. Every time your product violates a user's expectation, you create friction, erode trust, and impose a learning cost. Designing with mental models means users feel immediately capable, which is the fastest path to engagement and adoption.

Best Practices

  • Study how users describe your product space in their own words, not yours. Their language reveals their mental model.
  • Follow platform conventions. iOS users expect swipe-to-go-back. Desktop users expect Ctrl+Z to undo. Violating these is a fight you will lose.
  • Use familiar metaphors: shopping carts, folders, trash cans. These transfer user knowledge directly into your product.
  • When you must deviate from convention, provide clear signposting. Make the unfamiliar familiar through onboarding and progressive disclosure.
  • Test new patterns with real users early. What seems obvious in your team's mental model is often opaque to users.
  • Conduct card sorting to understand how users categorize and label information — their groupings reveal their mental model.
  • Align terminology with user vocabulary, not engineering vocabulary. "Archive" vs "Delete" means different things to different users.
  • Maintain spatial consistency — items that stay in the same place feel predictable and safe.

Common Mistakes

  • Building a UI that mirrors the database structure or API architecture instead of the user's mental model.
  • Inventing novel interaction patterns when a familiar one would work. Novelty is not a feature.
  • Using technical terminology that users don't know — "cache cleared," "null result," "token expired."
  • Restructuring navigation between versions without accounting for returning users' spatial memory.
  • Ignoring platform conventions because "our design is better." It is almost never better in users' eyes.

Checklist

Research & Theory

Don Norman's Conceptual Models

Norman distinguishes between the design model (designer's intent), the user's model (user's understanding), and the system image (what the product communicates). Good design minimizes the gap between all three.

Why it's relevant

The user's model is the one that matters. Your design model only succeeds if it's accurately communicated and matches user expectations.

Jakob's Law

Users spend most of their time on other websites. They expect your site to work the same way as every other site they know.

Why it's relevant

This is the most practically actionable mental models principle. Follow conventions. Differentiate on content and value, not interaction patterns.

Real-World Examples

Dropbox

The folder/file metaphor maps exactly to the user's mental model of file storage. No learning curve for the core concept.

Slack

Channels = rooms. DMs = private conversation. The spatial metaphor of an office translates directly.

Apple Notes

Yellow notepad metaphor, handwriting feel. The visual language communicates "this is for quick, informal writing."