Mental Model

For a long time, when a product didn't get used, the explanation pointed at the person. They didn't read the instructions, they don't know the feature exists. The remedy was more help text or a tutorial video. Yet the text would go up and the same question would keep arriving about the same screen.

What actually happens is that the user isn't missing knowledge — they arrive holding a different picture. Standing in front of something unfamiliar, a person pulls in experience with similar things, invents an on-the-spot account of how this one must work, and then acts on that account. When the picture matches, they use the product without reading anything. When it doesn't, they trust their own picture over the instructions printed on the screen.

Pagedeck got a ticket exactly like this. A user moved a document into another folder and found it still sitting in the original one, and they filed it as a bug. The product had been built so that moving makes a document visible in both places, so it worked as designed. But the user thought of folders the way they think of a physical filing cabinet. Take a page out of one drawer, put it in another, and the first drawer should be empty — it wasn't, so it read as a malfunction. The term mental model exists to move that mismatch out of the category of user error and into the category of design.

The user's picture and the product's actual structure exist separately, and the screen sits between them, which makes three things that have to line up.

1. The user's picture. It comes from other products they've used, physical objects, and what they've heard from people around them. It doesn't need to be accurate, only good enough to get their goal done. Nobody knows the route an email takes and everyone sends email anyway.
2. The product's actual structure. Where data lives and what references what. Whether one document can belong to several folders at once is settled here.
3. The picture the screen presents. Users never see the structure directly, only the interface, so how the screen reflects the structure is what builds the user's picture. Affordance, the property of looking like what it does, and a signifier, a cue added deliberately to say something is operable, are both tools for shaping that picture.

There are two directions the three can fall out of line. When the structure genuinely differs from the user's picture, either the structure changes or the screen has to announce the difference up front. For the folder case, the interface answer is splitting one "move" into two differently named actions.

The other direction is a structure that does match the user's picture while the screen fails to show it. That one is cheaper to fix. A label or a single line of guidance often settles it, which is why UX writing gives the largest return for the smallest change here.

The most frequent use is in naming. Deciding what menus and buttons say and how features get grouped — the work of information architecture — is largely an exercise in guessing the user's picture. Put internal vocabulary straight onto the screen and you get an interface that mirrors the structure precisely and that nobody can read.

It also comes up when introducing something new. To explain a concept a user doesn't have, borrow one they do. Folder, trash, lock — all borrowed. Borrowing cuts the explanation down, but the expectations attached to the borrowed picture come along with it. Call it a trash can and people expect to get things back out.

Jakob's law, which says users expect a product to behave like the other products they already use, is close to this concept turned into a design instruction. Pictures are mostly built elsewhere, so redesigning a widespread convention tends to register as confusion rather than as freshness.

Checking the picture means watching, not asking. In a usability test, where someone is given a real task and observed where they stall, the moment a hand stops or clicks the wrong thing is the moment the two pictures diverged. Onboarding starts from the same observation: what belongs on the first screen is decided by what the user already knows.

"People think of this like a filing cabinet. They expect that moving it empties the original spot."

Locating the reason for a ticket in the user's expectation rather than in the feature description.

"The feature isn't the problem, the name is. The current name sets up a different expectation."

Judging that this can be fixed at the interface without touching the structure.

"This flow works differently from every other tool. Is there a reason worth it?"

Asking for justification before departing from a familiar pattern.

At Pagedeck, once the folder tickets accumulated, Noa brought in five people and gave them the same task. Asked to move a document into another folder, four of the five went back and opened the original folder to check whether it was still there. They had heard the word move and expected the first place to be empty.

Noa didn't propose changing the structure, since belonging to several folders at once was something the team-based product needed. Instead the menu dropped the word move and split it into add to folder and remove from this folder. The tickets almost disappeared the following month.

The most common position is that users can be educated into a new picture. With the structure already built, filling the gap with explanation looks faster. But people don't read guidance before they start. They came in with a goal, so they touch things first and read only once stuck. A mismatch papered over with help text doesn't reduce tickets; it just accumulates more text in the same spot until the screen is heavy. Guidance that keeps growing in one place usually reads as a signal that the design is off.

The second mistake is treating the user's picture as a single thing. When a team says "the user thinks it works this way," the user in that sentence is usually one person. In reality the picture splits according to which products someone came from. A person who spent years in document tools and a person who passed files around in chat expect different things from the word share. So there's a choice to make about which picture to build for, and that choice turns out to be the same decision as choosing the primary audience.