一句話： 好設計會讓自己消失；壞設計會一直跳出來，逼使用者問「為什麼？」
0. 五秒結論
競技卡牌遊戲中，升到較高段位後在平日白天排隊，多次找不到對手。玩家少不是UI能解決的，但若每次失敗都要人手動按重試，問題就變了：明明是PvP，第一場卻是玩家打UI。
原則是：別讓我在對戰之外還要戰鬥。 人會預測「正常下一步應該怎樣」「既然目標是這個，結構應該怎樣」。現實偏離時，就會出現「嗯？」「為什麼？」「怪怪的」。
本文暫稱這個模式為結構性不一致偵測。這不是正式心理學術語，而是把prediction error、expectancy disconfirmation、processing fluency、Person–Environment Fit、Expectancy Violations Theory與專家直覺放在同一個實務框架。
違和感是警報，不是對原因的判決。
1. 起點：第一隻Boss叫「重試」
段位上升 → 人少 → 配對失敗 → 重試 → 又失敗 → 再重試。UI不能生出玩家，但可以持續搜尋、自動重試，或讓人等待時做別的事。
抱怨因此從「沒人」變成「為什麼我是搜尋操作員？」 卡牌遊戲應讓人思考牌、節奏、風險與勝負，不是增加「手動重啟配對專員」的兼職。
別把人類做成cron。 我打開的是遊戲，不是UI維運職缺。
2. 原則：刪除目標外PvE
不要把與使用者目標無關的摩擦變成使用者工作。購物卻和註冊打架、訂位卻和空位介面打架、工作卻先找核准人、自動化後還讓人每天盯「今天還自動嗎」、聊天卻一直逆向工程隱藏規則，全部是目標外PvE。
沒有人想取得「擊敗結帳表單」成就。好服務不會替使用者增加敵人。
3. 完成度高時，常常「什麼都沒感覺」
自動門正常開、付款正常完成、搜尋正常找到、下一步自然、誰有決策權清楚、交流不必不停解碼。然後結束。評語可能只有：「沒什麼特別。」
但這可能是高分。Processing fluency研究資訊處理的容易程度與喜好、信心、熟悉感等判斷的關係。服務研究也說明期待與實際經驗的關係會影響滿意度。
成熟系統會透明。未成熟系統會一直自我介紹：「按這裡」「先返回」「找另一個部門」。壞設計的自我介紹特別吵，好設計會降低存在感。
4. 研究語言裡的「哪裡不對勁」
Prediction error： 整合264個神經影像研究的統合分析，檢視獎賞、懲罰、行動、認知、知覺與社會推論等領域的預測誤差。白話就是「啊？下一步居然是這個？」
Expectancy disconfirmation： 2024年統合分析整合150筆研究紀錄、168個獨立研究、58,597名參與者。滿意度不只看性能，「跟我想的不一樣」也重要。
Processing fluency： 好讀、好找、好懂、容易預測。別把顧客的大腦當免費輔助CPU。
Person–Environment Fit： 環境再好，也可能不適合某個人。昂貴的鞋尺寸不合照樣磨腳。
Expectancy Violations Theory： 行為偏離人物、關係與情境形成的期待時會吸引注意；也可能出現「比預想更友善」的正向違背。
5. 五種結構性不一致
- 目標—手段： 想更快，卻加三層核准。
- 責任—權限： 「自己判斷」之後又問「誰叫你自己決定？」——把雷區包裝成成長課程。
- 言語—行為： 「歡迎挑戰」，失敗一次卻被長期追責。海報和現場像兩家公司。
- 評價—成果： 想要生產力卻獎勵待得久；想要品質卻懲罰缺陷回報。人會最佳化拿分方式。
- 人—系統： 重複點擊、重複輸入、每天手動啟動、持續確認「沒異常」。別把人類做成cron。
6. 違和感感測器怎麼工作
理解目標 → 預測合理結構 → 看現實 → 找差異 → 問為什麼 → 查原因、標準、責任 → 必要時重新設計。
常發現問題不一定只是愛抱怨，也可能是習慣快速對照目的與實作。副作用是，一旦發現「這一步根本不需要」，以後每次都看得見。鞋裡的小石頭會成為整場散步的主角。世界永久進入UI Debug Mode。
7. 服務：別把UI做成Boss戰
重複輸入、不必要確認、可預測失敗後的手動復原、返回就遺失資料、不清楚的主操作、只報代碼不說原因、系統已知道卻再次詢問，都是目標外戰鬥。
每個摩擦很小，但重複的小摩擦會占領整個體驗。成熟服務不只問「加什麼」，還問「什麼可以讓使用者以後再也不用注意？」
8. 環境：別用人的意志力替制度Bug打補丁
決策者不清楚就問資深員工、完成標準不清楚就看氣氛、資料找不到就找「那個知道的人」、系統不互通就用Excel黏起來、排程壞了就讓人每天盯。
工作最後完成，不代表系統健康。可能只是人類在即時手動修正一個有缺陷的系統。 員工越能幹，壞流程甚至可能活得越久。最強現場能力成了最差設計的生命維持系統。
9. 人：違和感不是讀心術
反覆出現言行矛盾、規則隨情境改變、責任總往同一方向移動，值得觀察。但「觀察到不一致」與「對方一定有惡意」不是同一件事。
分開事實、原預測、差異、替代解釋與下一步驗證。違和感是煙霧警報器，不是縱火犯照片。
10. 專家直覺什麼時候可靠
Kahneman與Klein在2009年討論專家直覺可靠的條件，特別重要的是環境存在可學習的規律與有足夠練習及有意義回饋。規則不停改、結果很難驗證、隨機性極高時，經驗久不保證直覺準。
也記錄猜錯的時候。別讓自己的記憶評論區只顯示五星。
11. 把違和感變成改善
寫目標 → 寫現況 → 找目標外戰鬥 → 問為什麼要人做 → 檢查技術、安全、成本、政策、歷史原因 → 刪除、自動化、合併、可視化 → 看改善後「為什麼？」是否減少。
12. Why Count（「為什麼？」次數）
數一次流程中出現多少次「為什麼要按？」「為什麼又輸入？」「為什麼問那個人？」「為什麼我要手動確認？」「為什麼有這規則？」
0次：透明。1–2次：順暢。3–5次：系統開始搶戲。6次以上：使用者體驗的是維運，不是產品。 它不是經驗證的學術量表，但很適合作為改善入口。
13. 「普通」其實是奢侈品
門本來就該開、電本來就該有、搜尋本來就該找到、付款本來就該完成、工作中本來就該知道誰決定、關係中本來就不該每次重建規則。
因此優秀系統得到的評語可能只是「很普通」。可這個普通背後可能有大量例外處理、測試、文件與流程改善。最好的設計會隱藏它有多難做。 餐廳不會宣布「好消息，今天廚房也沒失火」，只會上菜。
14. 結論：好設計會消失
違和感不是世界錯了的證明，也不是自己一定正確的證明。首先只是內部模型與觀察到的現實不一致的通知。
發現差異 → 分開事實與解釋 → 分類不一致 → 驗證原因 → 移除不必要摩擦 → 最後沒人再問為什麼。
別讓我在對戰之外戰鬥。別讓我在工作之外工作。別讓我為了正常生活還要做維運。尤其別把使用者變成你系統的免費Debug工程師。
