The mental model your user already has
I once watched a person fail to sign a document on a screen I had designed. Everything worked. The certificate was valid, the flow was short, the labels were accurate, and the button said what it did. She read the confirmation screen twice, then looked up and asked when it would be sent for the stamp.
There was no stamp. There had not been a stamp in that process for years. But she had spent her working life in a world where a document became real when somebody pressed something onto it, and nothing on my screen had replaced that moment. I had removed the ritual and given her a status message.
That is the part of the job that took me longest to understand. People do not arrive at your product empty. They arrive carrying a model of how this kind of thing works, assembled from every previous version of it they have used, including the paper ones. Your interface does not get to introduce itself first. It gets compared.
The model is built from everything except your product
When designers talk about mental models we usually mean something narrow, like whether a user understands that a folder contains files. The models that actually cause trouble are bigger and older than that.
Somebody using a banking app has a model of what money is and where it lives, and that model was formed by bank branches and paper statements long before it was formed by an app. Somebody using a sports app has a model of what a match is, built from television coverage and from standing in a stadium. Somebody signing a contract digitally has a model of what makes a document binding, and it involves ink.
None of these models are technically accurate. All of them are load bearing. When a person cannot predict what your product will do next, they fall back on the model they already trust, and they will trust it over your interface almost every time.
This is why the most expensive usability problems are rarely the ones that show up in a click test. A click test tells you whether somebody can find the button. It does not tell you whether they believe what happened after they pressed it.
Two kinds of mismatch, and only one is fixable with copy
Over the years I have found it useful to separate mismatches into two groups, because they need different responses.
The first is a vocabulary mismatch. Your product uses a word for something, and the user has a different word for the same thing. A person looking for their order history does not look for “transactions”. A person who wants to stop paying you does not look for “manage subscription”, they look for “cancel”.
Vocabulary mismatches feel severe when you watch them, because the user is visibly lost. They are also the cheap ones. You rename the thing. You add the word the user actually says, even if it is less precise than the word your database uses. Precision that nobody recognises is not precision, it is decoration.
The second is a structural mismatch, where the user’s model of how the pieces relate is different from yours. This is the one that hurts.
If a user believes that an item in their basket is reserved for them, and your system believes a basket is a list of intentions with no claim on stock, no amount of copy will resolve that. You can write “items in your basket are not reserved” in the clearest sentence ever composed, and a portion of people will still be surprised when the last one sells while they are entering their card details. Their model says the thing is theirs. Reading a sentence does not overwrite a model.
Structural mismatches have three honest responses. Change the system so it matches the model. Change the model by making the mechanism visible in the interface, repeatedly, not once. Or accept the mismatch and design for the moment it breaks, so the failure is graceful instead of surprising.
Most teams reach for a fourth option, which is to write more copy and hope. That option does not work, and it is popular because it is cheap.
Making the mechanism visible beats explaining it
If you do decide to change somebody’s model, the way to do it is not with a tooltip. It is by making the underlying mechanism observable while they use the product.
A stock counter that visibly ticks down teaches scarcity better than a sentence about scarcity. A progress indicator that shows a document moving between named states teaches a person what a signature process actually is. A timer on a held reservation teaches that the hold is temporary, and it teaches it every single time, to every user, without anybody reading anything.
The general principle is that people learn systems by watching them behave, not by being told how they behave. This is also why removing an intermediate state to “simplify” a flow can make the flow harder to trust. You have not removed complexity from the system, you have only removed the user’s view of it. The complexity is still there, and now it surfaces as a surprise later.
I have made this mistake more than once. Collapsing a three step process into one screen almost always tests well in the session and generates support tickets in the month afterwards, because people no longer have any idea what the product did on their behalf.
Where the model comes from matters for who you are designing for
There is a version of this thinking that goes wrong, and it is worth naming.
If you take “match the user’s mental model” as an absolute rule, you end up building a slightly nicer version of whatever people are used to, forever. Every new product would be shaped like the old one. Nobody would ever have shipped anything that required learning.
The resolution is that models are not evenly distributed. A person using a professional tool eight hours a day will invest in learning a model that fits the work, and will resent an interface that has been simplified below the complexity of their job. A person doing something once a year, under stress, with legal consequences, has no interest in learning anything and should be given the model they already have.
So the real question is not “what is the user’s mental model”. It is “how much does this particular person, in this particular situation, have to gain from learning a new one”.
For a back office used by trained operators, the answer is often quite a lot, and it is worth introducing a structure that matches the domain rather than the layperson’s intuition. For a public service that somebody touches twice in their life, the answer is nothing at all, and every deviation from the familiar is a cost you are asking a stranger to pay.
How I look for the mismatch now
I have stopped opening research sessions by showing people the product. If you put an interface in front of somebody, you get their reaction to your structure, and you lose access to the structure they had before you interfered.
Instead I ask them to describe how they think it works before they see anything. What happens to the money between the moment you press send and the moment it arrives. Who reads this document after you sign it. What would you expect to happen if you closed the browser right now.
The answers are frequently wrong in ways that are far more useful than any observed click. Someone telling you they assume a support agent personally reviews their complaint tells you more about your confirmation screen than watching them find the submit button ever will.
The second thing I do is collect the workarounds. When a person keeps a separate spreadsheet next to your tool, that spreadsheet is a specification. It contains exactly the part of their model your product refused to accommodate, written down by the person who needed it most. I have got more design direction out of other people’s spreadsheets than out of most formal research reports.
What this actually buys you
None of this is a technique for making an interface prettier, and it does not usually show up as a redesign. It shows up as small decisions that stop being arbitrary.
You keep a step that a stakeholder wants removed, because that step is where the user’s model gets confirmed. You use a longer, less elegant label because it is the phrase people actually say. You add a state to a status display because the absence of that state was making people call support to ask whether anything had happened.
Individually these look like minor calls. Together they are most of the difference between a product people trust and a product people tolerate. The interface was never really the thing being designed. The thing being designed was the story a person tells themselves about what just happened, and whether that story turns out to be true.
