Mental model
The picture in a user's head of how your product works. Match it and things feel obvious; miss it and everything feels broken.
See it
What it is
A mental model is the user's guess about how your system works, built from every other product they have used. Files live in folders. The trash can holds things until you empty it. A heart means saved, a star means important. None of that is technically true, and all of it governs what people expect your buttons to do. Don Norman's split is useful: there is the designer's model, the system's actual implementation, and the user's model, and the interface is the only thing connecting them.
Use it as a diagnostic. When testers say a feature is 'confusing', they usually mean the model mismatched: they thought Archive deleted things, or that closing the tab lost their draft. The cheap fixes are borrowing a familiar metaphor, using the words your users already say, and making state visible so the model can correct itself.
The trap is assuming your own model is the shared one. You know the sync queue exists; they think the document is 'saved' the moment the spinner stops. Either match the expectation or show enough status that the wrong model cannot survive first contact. Borrowed metaphors also age: a floppy disk save icon still works only because it stopped meaning a floppy disk.
Ask AI for it
Audit this interface against the mental model a first-time user brings. For each primary action, state what a non-expert would assume it does based on its label, icon, and placement, then flag every case where the real behavior differs (for example Archive versus Delete, autosave versus explicit save, local versus synced). For each mismatch, propose the cheapest fix in this order: rename to the user's own vocabulary, borrow a familiar metaphor, or expose system status so the wrong assumption gets corrected immediately. Return a table of action, assumed behavior, actual behavior, and fix.