Match the Interface to How Users Already Think

You can ship a product that looks great and still confuse people. Clean type, nice spacing, and it still feels wrong. That gap almost always comes from one place. The product works one way, and the user expected it to work another way. When those two pictures do not line up, people struggle, and no amount of visual polish fixes it.

The fix is not more design flair. It is understanding the picture your users already carry in their heads before they touch your product, then building to match it. That picture is called a mental model. Get it right and your product feels obvious. Get it wrong and it feels broken, even when it is technically fine.

The picture in the user's head comes before your screen

A mental model is what someone expects a thing to do before they use it. Susan Weinschenk puts it plainly: hand a person an iPad and tell them they can read a book on it, and before they even turn it on, they already assume how to turn a page or drop a bookmark. That expectation comes from every book, Kindle, and app they used before yours.

Weinschenk splits this into two parts worth keeping straight. The mental model is what the user expects. The conceptual model is what your interface actually shows them. Almost everything in design comes down to the match, or mismatch, between those two.

The useful takeaway: your users show up with expectations you did not create and cannot ignore. Your job is to find them, not fight them.

Steal the patterns people already know

You do not have to invent how a button or a login works. People carry standard expectations from thousands of other products. Buttons are rectangles with text. Links are underlined. The Adam Fard guide calls this Jakob's Law: people spend most of their time on other sites, so they expect yours to work like those.

This is freeing, not limiting. Every place you match a known pattern, you spend zero of the user's brainpower. That saves it for the parts that are genuinely new about what you do. Save your originality for the thing only your product does, and copy everyone else on the plumbing.

Watch for mixed-up models, too. Fard points to Google search, where people type a site name into the search box instead of the address bar because the two look too similar. When your parts blur together, people pick the wrong one.

Find the model before you draw a screen

You cannot guess a mental model from your desk. You find it by asking and watching. Interviews and surveys early tell you how people think about the problem. Testing your wireframes later shows you where your version clashes with theirs.

Card sorting is the cheap, direct move here. Hand people your content on cards and ask them to group it and name the groups. Open sorting when you have no structure yet, closed sorting when you want to check one you already have. You learn how they file things, which is how they will hunt for things in your product.

Competitor research counts too. Looking at similar products tells you what patterns your shared users already expect. Copy what works, and pick your spots to do something different on purpose.

Design for the reasons people act, not just the layout

Mental models are about how people expect things to work. But people also arrive with motives and biases that shape what they even notice. Kevin Waltz points to drivers like autonomy, achievement, and recognition that pull people toward a product or push them away.

Biases shape this filter. David Susman's rundown of cognitive biases is a good checklist for the shortcuts your users take without noticing, and the ones your own team takes when deciding what to build. Katelyn Bourgoin's work on the hidden why behind a purchase is a reminder that the reason someone acts is often not the reason they say out loud.

The point for your team: understanding cognition means understanding motive, not just interface habits. Build for why people show up, and the layout has something real to serve.

The deep cut

Here is the part that changes your approach. When you find a real mismatch, you have two options, not one. You can change your product to fit the user's model. Or, as Weinschenk notes, you can change the user's model to fit your product, usually with a short bit of onboarding or a training video. That is what good onboarding is actually for: adjusting the picture in the user's head before they hit the interface.

Most teams reach for the second option too fast. If you find yourself writing a tooltip to explain why something works in a surprising way, stop. That tooltip is often a confession that your conceptual model fights the user's mental model. Fix the model first. Save the teaching for the parts that are genuinely new and worth learning.

Three questions for your team

1. What is our user's mental model for this task, and where does our product mismatch it? Pick one flow, run a quick card sort or five interviews, and name the biggest gap before your next design review.
2. Where are we explaining with a tooltip what we should be fixing with the design? Audit your onboarding copy and flag any place that exists only to cover a surprising interaction.
3. What real reason brings people to this feature, and are we designing for that motive or just the screen? Tie one upcoming build to a specific user motivation you can test, not a layout you assume.