Mental Models
Mental models are the assumptions users bring to an interface — design that matches those assumptions is intuitive; design that contradicts them requires learning.
Users do not approach an interface with a blank slate. They arrive with expectations built from every system they have used before. The degree to which your interface matches those expectations determines how much learning it requires.
What a mental model is
A mental model is the internal representation a user builds of how a system works. It does not need to be accurate — it just needs to be predictive enough to guide action. When a user assumes that clicking the X in the top-right corner will close a dialogue, that assumption is a mental model. When it does not close the dialogue, the model fails and the user must revise it. The cost of revision is friction.
Where mental models come from
Mental models are built from prior experience with similar systems. The desktop metaphor — folders, files, trash — imported physical office concepts into computing because users already understood them. The shopping cart borrowed from physical retail. The inbox borrowed from postal mail. These metaphors lowered the learning cost for early digital interfaces by mapping to existing models. Every convention you follow in your design activates an existing model. Every convention you break forces users to build a new one.
Matching versus correcting
When your interface matches the user’s mental model, interaction feels intuitive — the user knows what to do without being told. When it contradicts the model, users make errors and must correct course. The question is not whether your design is objectively correct — it is whether it behaves the way users expect it to. A design that violates convention for no functional reason introduces friction for no benefit.
When to deviate
Deviating from established patterns is justified only when the new pattern offers a meaningful improvement — greater clarity, less effort, or a genuinely different capability that no existing convention covers. Deviating for aesthetic reasons, or because a convention feels dated, is rarely worth the learning cost. When you do deviate, make the new behaviour as discoverable as possible and be consistent throughout the interface.
The takeaway
Before designing any interaction, identify the established pattern for that type of control or flow. Understand what mental model users will bring. Deviate only when you have a concrete reason to improve on it — and document the new pattern clearly so it can be applied consistently. The affordances and signifiers that make your controls legible depend on activating the right models.