最小驚訝原則

​

什麼是最小驚訝原則？

最小驚訝原則指出，一個系統——無論是使用者介面、API 還是程式碼——應該以不讓使用者驚訝或困惑的方式運行。當使用者遇到意外行為時，他們會感到「驚訝」，這會削弱信任並增加認知負擔。

「使用者介面的設計應使使用者永遠不會對其行為感到驚訝。」—— 蘋果人機介面指南

該原則起源於 1980 年代的人機互動領域。IBM 的「通用使用者存取」標準和蘋果的人機介面指南都強調介面應該以符合使用者期望的方式運行。 透過設計師和開發者的觀察，這一原則獲得了更廣泛的關注。他們發現意外行為是使用者挫折的主要原因。即使使用者最終學會繞過驚訝，每次驚訝都需要額外的心理努力來處理和記憶。 在軟體開發中，該原則的應用超越了使用者介面設計。它指導 API 設計：一個名為「delete」的方法應該刪除，而不是封存。它指導程式碼組織：一個名為「calculateTotal」的函數應該計算總計，而不是修改資料庫。它指導錯誤處理：意外錯誤應該被優雅地處理，而不是導致應用程式崩潰。

​

最小驚訝原則的三層理解

• 入門：在設計任何面向使用者的元素時，問自己：「一個新使用者會期望這種行為嗎？」 如果答案是否定的，要麼改變行為，要麼清楚地說明這個例外。
• 實務：將 POLA 應用於程式碼和 API。描述性地命名事物，並確保函數做其名稱所暗示的事情。避免使用「巧妙」的解決方案，這些方案以意想不到的方式工作。
• 進階：考慮整個使用者旅程。每次互動都應該建立在前一次互動之上，形成一個連貫的思維模型。驚訝——即使是令人愉悅的——都可能打破使用者的控制感。

​

起源

最小驚訝原則起源於 1980 年代的人機互動領域。IBM 的「通用使用者存取」標準和蘋果的人機介面指南都強調介面應該以符合使用者期望的方式運行。 該原則透過設計師和開發者的觀察獲得了更廣泛的關注，他們發現意外行為是使用者挫折的主要原因。即使使用者最終學會繞過驚訝，每次驚訝都需要額外的心理努力來處理和記憶。 在軟體工程中，這一原則被採用並超越了 UI 設計。它成為 API 設計的指導原則，「令人驚訝」的行為不僅會破壞個別使用者，還會破壞整個依賴軟體的生態系統。 如今，POLA 被認為是最基本的設計原則之一，與一致性、可預測性和簡單性等概念並列。

​

核心要點

​

應用場景

​

經典案例

2012 年，一個流行的相片分享平台做了一個違反 POLA 的改變：他們將「刪除」按鈕的行為從立即永久刪除相片，改為將相片移動到「垃圾桶」資料夾，30 天後自動刪除。 使用者感到驚訝。許多使用者使用「刪除」來釋放儲存空間，期望相片立即消失。他們不檢查垃圾桶資料夾，當相片重新出現或儲存沒有減少時感到困惑。反彈很顯著——使用者覺得系統背叛了他們的信任。 該公司最終為高級使用者恢復了這一行為，同時為免費帳戶保留了這一行為（以節省儲存成本），但對使用者信任的損害仍然存在。這個案例說明，即使出於善意的改變也可能與既定的使用者期望發生衝突，從而違反 POLA。 教訓：在改變任何行為之前，考慮使用者的期望。如果改變是必要的，要清楚地溝通並提供退出機制。驚訝——即使在技術上是合理的——也會產生摩擦。

​

邊界與失效場景

如果從字面上理解，POLA 可能成為創新的障礙。有時「正確」的解決方案是違反直覺的。例如，文字編輯器中的「復原」功能讓早期使用者感到驚訝，但現在已成為預期。 關鍵是區分因設計不佳而導致的驚訝與因創新而導致的驚訝。創新需要教導使用者新的模式。解決方案不是避免創新，而是逐步引入創新，並清楚地說明。 另一個失敗模式是為了犧牲一致性而過度因循守舊。 如果你複製了一個在上下文中有效但不適合你特定用例的介面，使用者可能在局部不驚訝但在全域感到困惑。 邊界條件：POLA 應該指導設計但不應使其癱瘓。當創新需要令人驚訝的行為時，投入教育並提供清晰的回饋。

​

常見誤區

​

相關概念

最小驚訝原則與其他重要的設計和開發原則相連：

​

一句話總結