The mental model your user already has

I once watched a woman fail to sign a document on a screen I designed. Nothing was broken. The certificate was valid, the flow was short, the button said exactly what it did. She read the confirmation twice, looked up at me and asked when the document goes for the stamp.

There was no stamp. That process hadn’t involved a stamp for years. But she’d spent her whole working life in a world where a document becomes real when someone presses a stamp onto it. My screen took that moment away and gave her a status message instead. As far as she was concerned, nothing had happened yet.

It took me a long time to really understand what I saw that day. People don’t come to your product empty. They bring an idea of how this kind of thing works, built from every version of it they’ve used before, including the paper ones. Your interface never gets to introduce itself first. It gets compared to something that was already in their head, and I’m not sure we think about that enough.

Where the model actually comes from

When we say mental model, we usually mean something small. Does the user understand that a folder holds files, that kind of thing. The ones that cause real damage are much older and much bigger than that.

Take a banking app. The person using it formed their idea of money in a bank branch, standing in a line, holding paper. A sports fan’s idea of a match comes from television and from the stadium. And with digital signing, the idea of what makes a document binding involves ink, and in my part of the world, very definitely a stamp.

None of these models is technically accurate, and it doesn’t matter. They’re load bearing. The moment a person can’t predict what your product will do next, they fall back on the model they trust, and between their model and your interface, their model wins almost every time.

Click tests won’t catch this, by the way. A click test tells you whether someone can find the button. It says nothing about whether they believe what happened after they pressed it, and that second part is where the expensive problems tend to be.

Two kinds of mismatch

After enough of these sessions I started sorting mismatches into two groups, because I respond to them differently.

The first group is vocabulary. Your product calls something one word, the user calls it another. Someone looking for their order history walks straight past a link called Transactions. Someone who wants to stop paying you types Cancel, and Manage subscription might as well be invisible.

A vocabulary mismatch looks dramatic when you watch it, because the person is visibly lost. The fix is boring, though. Rename the thing. Use the word people say out loud, even when your database has a more precise one. Does anyone recognise the precise word? If not, it’s not doing anything for you.

The second group is structural. The user’s model of how the pieces relate doesn’t match how your system works. This is the one I find much harder.

Say a user believes an item in their basket is reserved for them. Your system treats the basket as a wish list with no claim on stock. You can write “items in your basket are not reserved” in plain words, right above the button, and some people will still be shocked when the last piece sells while they’re typing in their card number. Their model says the thing is already theirs. A sentence doesn’t overwrite a model, however much I’d like it to.

For structural mismatches I think you have three honest options. Change the system until it matches the model. Change the model by letting people watch the mechanism work, repeatedly, inside the product. Or keep the mismatch and design the moment it breaks, so it fails politely instead of surprising anyone.

Most teams pick a hidden fourth option, which is writing more copy and hoping. I’ve watched that one fail for thirteen years, so let’s talk about the other three.

Let people watch the machine work

If you decide to change someone’s model, forget the tooltip. Make the mechanism visible while they use the product.

A stock counter ticking down teaches scarcity better than any sentence about scarcity. A document moving through named states shows what a signing process actually is. Put a countdown on a held reservation and every user learns that holds expire, without reading a word.

People learn systems by watching them behave. Which is also why “simplifying” a flow by hiding a step can damage trust. The complexity didn’t go anywhere. You removed the user’s view of it, and in my experience it comes back later as a surprise.

I’ve made this exact mistake more than once. Collapse a three step process into one clean screen and it tests beautifully in the session. A month later the support tickets start, because nobody can tell anymore what the product did on their behalf. Have you had that one? I suspect most of us have.

When breaking the model is fine

There’s a lazy version of this whole idea, and I hear it in design reviews a lot, so I want to name it.

If “match the mental model” becomes an absolute rule, you’ll spend your career shipping slightly nicer versions of whatever already exists. Nothing that requires learning would ever get built. The spreadsheet broke somebody’s mental model once, and so did the smartphone.

Here’s how I resolve it for myself, and I’m open to better ways. Models aren’t spread evenly across people. An operator who lives inside your tool eight hours a day will gladly learn a structure that fits the job, and will resent a tool that got dumbed down below the complexity of their work. A citizen renewing a permit once in five years, stressed, with legal consequences attached, wants to learn nothing. That person should get the model they walked in with.

So I stopped asking what the user’s mental model is. I ask how much this person, in this situation, gains by learning a new one. In a back office full of trained operators, often a lot. In a public service that someone touches twice in a lifetime, nothing at all. There, every deviation from the familiar is a cost, and the person renewing the permit is the one who pays it.

How I hunt for the mismatch now

I stopped opening research sessions with the product. Show someone an interface and what you get back is their reaction to your structure. The structure they carried in, the one you actually need to see, is gone by then. You’ve contaminated it, basically.

So I ask first, before showing anything. Describe how you think this works. 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 do you expect if you close the browser right now?

Wrong answers are the best research material I know. When someone assumes a support agent personally reads every complaint, that tells you more about your confirmation screen than an hour of watching them click around it.

I also collect workarounds. When a person keeps their own spreadsheet next to your tool, that spreadsheet is a specification. It holds exactly the part of their model your product refused to take in, documented by the one person who needed it most. Over the years I’ve got more design direction out of other people’s spreadsheets than out of most of the research reports I paid for. What do your users keep next to your product?

What you get for all of this

None of it makes screens prettier. It rarely even shows up as a redesign. It shows up as small decisions that stop being arbitrary.

You keep the step a stakeholder wants deleted, because that step is where the user’s model gets confirmed. The longer, uglier label wins because it’s the phrase people actually say. And a status display grows one more state, because without it people were calling support to ask whether anything had happened at all.

Each of these looks minor on its own. Together, I think they’re most of the distance between a product people trust and a product people tolerate.

I still think about the woman with the stamp. The screen was fine. What she believed had happened was broken, and nothing on my screen gave her a new belief to hold. These days that’s where I start designing. If you’ve got a story like hers, I’d like to hear it.