最小惊讶原则

​

什么是最小惊讶原则？

最小惊讶原则指出，一个系统——无论是用户界面、API还是代码——应该以不让用户惊讶或困惑的方式运行。当用户遇到意外行为时，他们会感到”惊讶”，这会削弱信任并增加认知负担。

“用户界面的设计应使用户永远不会对其行为感到惊讶。” — 苹果人机界面指南

该原则起源于1980年代的人机交互领域。IBM的”通用用户访问”标准和苹果的人机界面指南都强调界面应该以符合用户期望的方式运行。 这一原则通过设计师和开发者的工作获得了更广泛的关注，他们观察到意外行为是用户沮丧的主要原因。即使用户最终学会绕过惊讶，每次惊讶都需要额外的心理努力来处理和记忆。 在软件开发中，该原则的应用超越了用户界面设计。它指导API设计：一个名为”delete”的方法应该删除，而不是存档。它指导代码组织：一个名为”calculateTotal”的函数应该计算总数，而不是修改数据库。它指导错误处理：意外错误应该被优雅地处理，而不是导致应用程序崩溃。

​

最小惊讶原则的三层理解

• 入门：在设计任何面向用户的元素时，问自己：“一个新用户会期望这种行为吗？“如果答案是否定的，要么改变行为，要么清楚地传达这个例外。
• 实践：将POLA应用于代码和API。描述性地命名事物，并确保函数做其名称所暗示的事情。避免使用”巧妙”的解决方案，这些方案以意想不到的方式工作。
• 进阶：考虑整个用户旅程。每次互动都应该建立在前一次互动之上，形成一个连贯的思维模型。惊讶——即使是令人愉悦的——都可能打破用户对控制感。

​

起源

最小惊讶原则起源于1980年代的人机交互领域。IBM的”通用用户访问”标准和苹果的人机界面指南都强调了界面应该以符合用户期望的方式运行。 该原则通过设计师和开发者的工作获得了更广泛的关注，他们观察到意外行为是用户沮丧的主要原因。即使用户最终学会绕过惊讶，每次惊讶都需要额外的心理努力来处理和记忆。 在软件工程中，这一原则被采用并超越了UI设计。它成为API设计的指导原则，“令人惊讶”的行为不仅会破坏个别用户，还会破坏整个依赖软件的生态系统。如今，POLA被认为是最基本的设计原则之一，与一致性、可预测性和简单性等概念并列。

​

核心要点

​

应用场景

​

经典案例

2012年，一个流行的照片共享平台做了一个违反POLA的改变：他们将”删除”按钮的行为从立即永久删除照片，改为将照片移动到”垃圾箱”文件夹，30天后自动删除。 用户感到惊讶。许多用户使用”删除”来释放存储空间，期望照片立即消失。他们不检查垃圾箱文件夹，当照片重新出现或存储没有减少时感到困惑。反弹很显著——用户觉得系统背叛了他们的信任。 该公司最终为高级用户恢复了这一行为，同时为免费账户保留了这一行为（以节省存储成本），但对用户信任的损害仍然存在。这个案例说明，即使出于善意的改变也可能与既定的用户期望发生冲突，从而违反POLA。 教训：在改变任何行为之前，考虑用户的期望。如果改变是必要的，要清楚地沟通并提供退出机制。惊讶——即使在技术上是合理的——也会产生摩擦。

​

边界与失效场景

如果从字面上理解，POLA可能成为创新的障碍。有时”正确”的解决方案是违反直觉的。例如，文本编辑器中的”撤销”功能让早期用户感到惊讶，但现在已成为预期。 关键是区分因设计不佳而导致的惊讶与因创新而导致的惊讶。创新需要教导用户新的模式。解决方案不是避免创新，而是逐步引入创新，并清楚地传达。 另一个失败模式是为了牺牲一致性而过度conformity。如果你复制了一个在上下文中有效但不适合你特定用例的界面，用户可能在局部不惊讶但在全局感到困惑。 边界条件：POLA应该指导设计但不应使其瘫痪。当创新需要令人惊讶的行为时，投入教育并提供清晰的反馈。

​

常见误区

​

相关概念

最小惊讶原则与其他重要的设计和开发原则相连：

​

一句话总结