> ## Documentation Index
> Fetch the complete documentation index at: https://meta.niceshare.site/llms.txt
> Use this file to discover all available pages before exploring further.
# 最小驚訝原則
> 最小驚訝原則（POLA）指出系統的行為不應讓使用者感到驚訝。了解其起源、優勢以及在設計與開發中的應用。
**類別**：原則
**類型**：使用者介面與軟體設計原則
**來源**：1980年代，IBM 與蘋果介面指南
**別名**：POLA、最小驚訝原則
**快速回答** — 最小驚訝原則（Principle of Least
Astonishment，POLA）是一個設計準則，主張系統的行為應該符合使用者期望，不應讓他們感到驚訝。該原則源於
1980 年代的使用者介面指南，已成為使用者體驗設計、API
設計和軟體架構的基本原則，強調可預測性和一致性。
## 什麼是最小驚訝原則？
最小驚訝原則指出，一個系統——無論是使用者介面、API 還是程式碼——應該以不讓使用者驚訝或困惑的方式運行。當使用者遇到意外行為時，他們會感到「驚訝」，這會削弱信任並增加認知負擔。
> 「使用者介面的設計應使使用者永遠不會對其行為感到驚訝。」—— 蘋果人機介面指南
該原則起源於 1980 年代的人機互動領域。IBM 的「通用使用者存取」標準和蘋果的人機介面指南都強調介面應該以符合使用者期望的方式運行。
透過設計師和開發者的觀察，這一原則獲得了更廣泛的關注。他們發現意外行為是使用者挫折的主要原因。即使使用者最終學會繞過驚訝，每次驚訝都需要額外的心理努力來處理和記憶。
在軟體開發中，該原則的應用超越了使用者介面設計。它指導 API 設計：一個名為「delete」的方法應該刪除，而不是封存。它指導程式碼組織：一個名為「calculateTotal」的函數應該計算總計，而不是修改資料庫。它指導錯誤處理：意外錯誤應該被優雅地處理，而不是導致應用程式崩潰。
### 最小驚訝原則的三層理解
* **入門**：在設計任何面向使用者的元素時，問自己：「一個新使用者會期望這種行為嗎？」 如果答案是否定的，要麼改變行為，要麼清楚地說明這個例外。
* **實務**：將 POLA 應用於程式碼和 API。描述性地命名事物，並確保函數做其名稱所暗示的事情。避免使用「巧妙」的解決方案，這些方案以意想不到的方式工作。
* **進階**：考慮整個使用者旅程。每次互動都應該建立在前一次互動之上，形成一個連貫的思維模型。驚訝——即使是令人愉悅的——都可能打破使用者的控制感。
## 起源
最小驚訝原則起源於 1980 年代的人機互動領域。IBM 的「通用使用者存取」標準和蘋果的人機介面指南都強調介面應該以符合使用者期望的方式運行。
該原則透過設計師和開發者的觀察獲得了更廣泛的關注，他們發現意外行為是使用者挫折的主要原因。即使使用者最終學會繞過驚訝，每次驚訝都需要額外的心理努力來處理和記憶。
在軟體工程中，這一原則被採用並超越了 UI 設計。它成為 API 設計的指導原則，「令人驚訝」的行為不僅會破壞個別使用者，還會破壞整個依賴軟體的生態系統。 如今，POLA 被認為是最基本的設計原則之一，與一致性、可預測性和簡單性等概念並列。
## 核心要點
當系統按預期運行時，使用者會產生信心。他們可以預測結果，並對自己的互動感到掌控。
熟悉的模式允許使用者從其他系統轉移知識。減少學習時間；增加生產力時間。
當使用者能夠預測系統行為時，他們的錯誤會減少。意外行為通常會導致錯誤，因為使用者試圖「糾正」正常情況。
可預測的介面對每個人都更容易，但對依賴一致性的認知障礙使用者尤其重要。
## 應用場景
按鈕應該看起來像按鈕，表現也像按鈕。點擊「提交」表單應該提交它，而不是儲存草稿。
方法名稱應該清楚地表明它們的作用。「updateUser」方法應該更新使用者資料，而不是發送電子郵件或觸發通知。
檔案和資料夾的組織方式應符合開發者的期望。設定檔應該放在設定目錄中，而不是與業務邏輯混在一起。
錯誤訊息應該清楚地說明出了什麼問題以及如何解決。通用的「發生錯誤」訊息會讓使用者驚訝，不提供任何解決路徑。
## 經典案例
2012 年，一個流行的相片分享平台做了一個違反 POLA 的改變：他們將「刪除」按鈕的行為從立即永久刪除相片，改為將相片移動到「垃圾桶」資料夾，30 天後自動刪除。
使用者感到驚訝。許多使用者使用「刪除」來釋放儲存空間，期望相片立即消失。他們不檢查垃圾桶資料夾，當相片重新出現或儲存沒有減少時感到困惑。反彈很顯著——使用者覺得系統背叛了他們的信任。
該公司最終為高級使用者恢復了這一行為，同時為免費帳戶保留了這一行為（以節省儲存成本），但對使用者信任的損害仍然存在。這個案例說明，即使出於善意的改變也可能與既定的使用者期望發生衝突，從而違反 POLA。
教訓：在改變任何行為之前，考慮使用者的期望。如果改變是必要的，要清楚地溝通並提供退出機制。驚訝——即使在技術上是合理的——也會產生摩擦。
## 邊界與失效場景
如果從字面上理解，POLA 可能成為創新的障礙。有時「正確」的解決方案是違反直覺的。例如，文字編輯器中的「復原」功能讓早期使用者感到驚訝，但現在已成為預期。
關鍵是區分因設計不佳而導致的驚訝與因創新而導致的驚訝。創新需要教導使用者新的模式。解決方案不是避免創新，而是逐步引入創新，並清楚地說明。
另一個失敗模式是為了犧牲一致性而過度因循守舊。 如果你複製了一個在上下文中有效但不適合你特定用例的介面，使用者可能在局部不驚訝但在全域感到困惑。
邊界條件：POLA 應該指導設計但不應使其癱瘓。當創新需要令人驚訝的行為時，投入教育並提供清晰的回饋。
## 常見誤區
POLA
不禁止新想法——它要求新行為的引入要經過深思熟慮。如果溝通清楚，使用者可以學習新的模式。
該原則適用於任何有使用者的系統——包括使用 API
的開發人員、管理系統的管理員，甚至是程式碼的讀者。
有時使用者說他們想要一件事，但當得到它時卻感到驚訝。POLA
是關於理解*思維模型*，而不只是收集功能請求。
## 相關概念
最小驚訝原則與其他重要的設計和開發原則相連：
保持簡單。簡單、可預測的系統更容易理解，不太可能讓使用者驚訝。
一致的介面遵循既定的模式。POLA 本質上是關於與使用者期望的一致性。
使用者攜帶關於系統如何運作的思維模型。POLA
是關於設計來匹配這些模型，而不是對抗它們。
## 一句話總結
**設計系統以符合使用者期望的方式運行——匹配他們的思維模型，保持一致性，當創新需要令人驚訝的行為時，要清楚地溝通並提供指導。**