We do not only design what people see; we design what they believe is happening.
Concept of the week · The interface is not the whole explanation
A product is used through the mental model a person carries into the moment.
People do not act based on the system architecture; they act based on the explanation in their heads. Under pressure, a weak or mismatched interpretation creates hidden checks, workaround rituals, verification burden, and correct actions performed for the wrong reason.
Design standard: identify the broadest common model you can safely support, then make important mismatches visible through language, feedback, and guardrails.
A simple example is the visualization of physiological vital signs.
Should the interface show a human avatar, a cardiovascular system, a decision tree, a traffic light, or only numbers? In one view, the clinician asks, “Which organ system is deteriorating?” In another, the question becomes, “Does this patient need immediate action?”
Each choice carries an assumption about how clinicians understand patient status.
A human avatar supports a body-state view. A cardiovascular system supports physiological reasoning. A decision tree supports guided next action. A traffic light supports fast prioritization. Pure numbers preserve detail, but ask the user to interpret values, trends, limits, and context themselves.
None of these representations is neutral.
Each one moves work between the interface and the user.
A few years ago, I worked with a team on an innovation project in which a basic research question proved surprisingly difficult to answer: What is the underlying mental model of our users?
At first, we looked for one answer. Then we realized we could not define a single clean user group. Physicians and nurses approached the same situation with different assumptions, different priorities, and different explanations of what the system was doing.
Even within the same role, the interpretation varied. Some users could complete the workflow correctly, but for reasons that did not match the actual system logic. That is a quiet risk: the action looks right, but the belief underneath may fail in the next edge case.
The calmer shift was not to chase every individual model. It was to find a common one worth supporting, then design the system so that deviations could be seen, tested, and corrected before they became rework or a safety risk.
The same pattern appears in enterprise software and information technology. A customer success manager, a data engineer, and a finance user may all use the same dashboard, but each one brings a different explanation of what a status, score, or automation means.
Correct use can still hide a wrong model.
Every unsupported interpretation adds another branch to onboarding, labeling, error handling, analytics review, and regression testing.
How teams ship this: version the assumed user model beside each workflow, including primary user group, expected interpretation, known mismatch, and the first test that proved or challenged it.
Asset & resource
Mental Model Mismatch Card
Use one card for any workflow where users may succeed for different reasons.
What does the user think is happening?
What is actually happening?
Which action still looks correct?
Where could the mismatch create hidden checks, delay, or risk?
What label, feedback, or guardrail reduces the gap?
Mental Models by Indi Young
Read it as a way to move from “what users clicked” toward “what users believed they were doing.” The asset keeps that belief visible long enough for designers, engineers, and product managers to make a safer trade-off.
Light wisdom & reflection
“A mental model is what the user believes about the system … at hand.”
Where are users still succeeding in your product while carrying a belief that would fail in the next edge case?
Mindful practice
Before using one familiar object today, pause for a few seconds and notice the small theory you carry about how it works.
What do you expect it to do before you touch it?
What would make that expectation break?
Next time an object surprises you, notice whether the thing failed, or whether your model met a different model.
Bonus chapter on artificial intelligence (AI)
Artificial intelligence (AI) can help teams surface candidate mental models faster, but it should not be treated as the user’s mind. A useful AI workflow is to cluster interview notes, complaints, task-analysis observations, and support logs into likely belief patterns, then ask researchers to verify those patterns with actual users.
This is especially useful before formative testing. AI can propose “users may think X because they say Y,” but the team still needs to test whether that belief changes behavior, creates hidden checks, or breaks in an edge case. Recent work on AI-assisted card sorting suggests that LLMs can produce useful first groupings, but they still miss parts of how real participants organize meaning. The output is a hypothesis, not lived use.
The calm use of AI here is not automation of judgment. It is compression of the early search space: fewer blank pages, faster pattern spotting, and a clearer list of assumptions to test. For regulated or high-stakes systems, keep the AI output as hypothesis evidence, not validation evidence.
Best,
Andreas Walden
Share this with someone designing for clarity.