In one line: Great design makes itself disappear. Bad design keeps interrupting the user until they ask, “Why?”
0. The five-second version
Imagine a competitive card game. You reach a higher rank, queue on a quiet weekday afternoon, and matchmaking fails repeatedly. A small player pool is understandable. The experience changes when every failure makes the human press Retry again.
The game is supposed to be PvP, yet the first fight is against the UI.
That gives us a useful rule: don’t make users fight outside their actual objective. Humans carry predictions about what normally happens next and how a system should work if its stated goal is real. When reality violates that model, we notice: “Huh?”, “Why?”, “Something feels off.”
This article calls that pattern structural inconsistency detection as a practical label, not an official psychological construct. It connects research on prediction error, expectancy disconfirmation, processing fluency, person–environment fit, expectancy violations, and expert intuition.
Most importantly: a feeling of mismatch is an alarm, not a verdict about its cause.
1. The origin: I opened a card game and the first boss was Retry
Rank goes up. The player pool looks thin. Start matchmaking. No opponent. Retry. Still nobody. Retry again. How many times are we doing this?
A UI cannot manufacture players, but it can decide whether to keep searching, retry automatically, or let users do something else while waiting. The frustration changes from “there is nobody” to “why have I been promoted to matchmaking operator?”
A card game should ask the player to choose cards, read the opponent, manage risk, and win. It should not add a side job called Manual Queue Restart Technician.
Do not turn humans into cron jobs. I launched a game, not an application form for UI Operations.
2. The principle: remove out-of-objective PvE
Generalized: do not turn friction unrelated to the user’s goal into the user’s job.
Want to buy something, but fight registration. Want to reserve, but fight the availability interface. Want to submit a request, but fight several spreadsheets. Want to finish work, but play Find the Approver. Build automation, then make a human watch it daily to verify it is still automated. Want a conversation, but spend it reverse-engineering invisible rules.
That is all out-of-objective PvE. Nobody wants the achievement “Defeated the Checkout Form.”
A good service does not manufacture additional enemies.
3. High quality often feels like “nothing happened”
Excellent services rarely make users think, “What a magnificent hierarchy of buttons.” The automatic door opens. Payment completes. Search finds. The next action is obvious. Decision ownership is clear. Conversation works without constant decoding. Then it ends.
Review: nothing special.
That can be a very high score. Research on processing fluency examines how ease of processing can influence liking, confidence, familiarity, and judgment. Service research also shows that satisfaction depends on the relationship between expectations and experience, not raw performance alone.
Mature systems become transparent. Immature systems keep introducing themselves: click here, go back first, this field is mandatory, ask another department.
Bad design has a loud introduction. Good design lowers its own visibility.
4. Translating “something feels off” into research language
Prediction error: many cognitive and neuroscience models treat the brain as predictive. A meta-analysis combining 264 neuroimaging studies examined prediction-error activity across reward, punishment, action, cognition, perception, and social inference. In ordinary language: “Wait, that happens next?”
Expectancy disconfirmation: consumer and service research studies the gap between expectations and actual experience. A 2024 meta-analysis synthesized 150 records, 168 independent studies, and 58,597 participants. Performance matters, but “this is not what I expected” matters too.
Processing fluency: easy to read, find, understand, and predict. Less academically: do not use the customer’s brain as your free auxiliary CPU.
Person–Environment Fit: there is no universally perfect environment. A prestigious shoe still hurts if it is the wrong size.
Expectancy Violations Theory: behavior that departs from interpersonal expectations attracts attention and appraisal. Violations can also be positive, such as unexpected kindness.
5. Five practical structural mismatches
- Goal–means mismatch: “go faster” → add three approvals; “increase matches” → make retry manual.
- Responsibility–authority mismatch: “use your judgment” → “why did you decide without permission?” A minefield marketed as empowerment.
- Words–behavior mismatch: “we welcome experiments” → punish failures for months. The poster and the workplace belong to different companies.
- Evaluation–outcome mismatch: want productivity but reward visible hours; want quality but punish defect reports. People optimize the scoring system.
- Human–system mismatch: repeated clicks, duplicated entry, manual starts, constant no-error checks. Do not turn humans into cron jobs.
6. How the mismatch detector works
Understand the goal → predict a sensible structure → observe reality → detect the gap → ask why → inspect causes, criteria, and responsibility → redesign if needed.
Noticing mismatches often does not automatically mean being negative. It may mean aggressively comparing purpose with implementation. The downside is that once an unnecessary step becomes visible, it stays visible forever. A pebble in the shoe becomes the protagonist of the entire walk.
Congratulations: the world is now permanently running in UI Debug Mode.
7. Services: stop making the UI a boss battle
Look for repeated data entry, unnecessary confirmation screens, manual recovery after predictable failure, forms that erase data, unclear primary actions, error codes without causes, and questions about information the system already knows.
Each issue looks small alone. But a tiny stone inside a shoe becomes the entire product review after two kilometers.
A mature service does not only ask what it can add. It asks what the user can stop having to notice.
8. Environments: stop patching broken institutions with human willpower
No clear decision owner? Ask the veteran. No definition of done? Read the room. Unknown data location? Find the person who knows. Undocumented exceptions? Find whoever handled it last time. Systems do not integrate? Glue them together with spreadsheets. Schedules break? Assign someone to watch them daily.
When work still gets completed, leaders may think the system works. Maybe not. People may simply be performing real-time manual correction for a defective system.
The more capable the staff, the longer bad design can survive. Excellent operators can become life support for terrible processes. Infernal teamwork.
9. People: discomfort is an alarm, not mind-reading
Repeated contradictions between words and actions, shifting rules, or responsibility always moving in one direction are worth observing. But “I observed inconsistent behavior” is an observation; “therefore this person has malicious motives” is an inference.
Separate: what happened, what you predicted, where the mismatch occurred, alternative causes, and what future observation could distinguish them.
Discomfort is a smoke alarm, not a photograph of the arsonist.
10. When can expert intuition be trusted?
Kahneman and Klein argued in 2009 that reliable intuitive expertise depends especially on two things: an environment containing learnable regularities and sufficient practice with meaningful feedback.
Stable domains with repeated feedback can support rapid anomaly detection. Environments where outcomes are rarely observed, rules constantly change, or randomness dominates do not guarantee accurate intuition just because someone has years of experience.
Record your misses too. Do not build a review site for your own memory that filters everything except five-star reviews.
11. Turn discomfort into improvement
- State the goal. What should the user actually achieve?
- State the current process. What are they actually forced to do?
- Find the out-of-objective fight. Is it truly necessary?
- Ask why a human does it. Technical constraint, safety, cost, policy, legacy, or simply unmeasured friction?
- Remove, automate, consolidate, or make visible.
- Measure after change. Did the user think less about things unrelated to the original goal?
12. A semi-serious metric: Why Count
Count how many times a journey produces: Why click this? Why enter it again? Why ask that person? Why check it manually? Why does this rule exist?
0: transparent design. 1–2: mostly smooth. 3–5: the system becomes a visible character. 6+: the user is experiencing operations and maintenance rather than the product.
It is not a validated academic scale. But “average 3.4 why-moments before completing a reservation” often tells an improvement team more than “satisfaction is 4.2.”
13. “Normal” is a luxury product
Doors should open. Electricity should work. Search should find. Payments should finish. At work, decision ownership should be understandable. Relationships should not require reconstructing the rules every conversation.
So great systems often receive the review: “It was normal.” Behind that normality may sit years of exception handling, testing, documentation, UX work, training, and process improvement.
The best design hides the evidence of how hard it was to build. A restaurant does not announce, “Good news, the kitchen did not catch fire today.” It simply serves dinner.
14. Conclusion: good design disappears
Mismatch is not proof that the world is wrong or that you are right. First, it is a notification that your internal model and observed reality do not match.
Mismatch → separate observation from interpretation → classify the structural gap → test the cause → remove unnecessary friction → eventually nobody asks why.
In a game, fight the opponent. In a service, pursue the purpose. At work, do the work instead of administering the work. In a relationship, stop reverse-engineering the rules every time.
The final review may sound boring:
“It was just… normal.”
For a designer, that can be an extraordinary compliment.
Don’t make me fight outside the match. Don’t make me work outside the work. Don’t make me perform operations maintenance just to live. And do not turn your user into the unpaid debugger of your system.
