> ## 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）指出系统行为不应让用户感到惊讶。了解其起源、优势以及在设计和开发中的应用。

<Info>
  **类别**: 原则<br />
  **类型**: 用户界面与软件设计原则<br />
  **来源**: 1980年代，IBM与苹果界面指南<br />
  **别名**: POLA，最小惊讶原则
</Info>

<Note>
  **快速回答** — 最小惊讶原则（Principle of Least Astonishment，POLA）是一个设计准则，主张系统的行为应该符合用户期望，不应让他们感到惊讶。该原则源于1980年代的用户界面指南，已成为用户体验设计、API设计和软件架构的基本原则，强调可预测性和一致性。
</Note>

## 什么是最小惊讶原则？

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

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

该原则起源于1980年代的人机交互领域。IBM的"通用用户访问"标准和苹果的人机界面指南都强调界面应该以符合用户期望的方式运行。

这一原则通过设计师和开发者的工作获得了更广泛的关注，他们观察到意外行为是用户沮丧的主要原因。即使用户最终学会绕过惊讶，每次惊讶都需要额外的心理努力来处理和记忆。

在软件开发中，该原则的应用超越了用户界面设计。它指导API设计：一个名为"delete"的方法应该删除，而不是存档。它指导代码组织：一个名为"calculateTotal"的函数应该计算总数，而不是修改数据库。它指导错误处理：意外错误应该被优雅地处理，而不是导致应用程序崩溃。

### 最小惊讶原则的三层理解

* **入门**：在设计任何面向用户的元素时，问自己："一个新用户会期望这种行为吗？"如果答案是否定的，要么改变行为，要么清楚地传达这个例外。

* **实践**：将POLA应用于代码和API。描述性地命名事物，并确保函数做其名称所暗示的事情。避免使用"巧妙"的解决方案，这些方案以意想不到的方式工作。

* **进阶**：考虑整个用户旅程。每次互动都应该建立在前一次互动之上，形成一个连贯的思维模型。惊讶——即使是令人愉悦的——都可能打破用户对控制感。

## 起源

最小惊讶原则起源于1980年代的人机交互领域。IBM的"通用用户访问"标准和苹果的人机界面指南都强调了界面应该以符合用户期望的方式运行。

该原则通过设计师和开发者的工作获得了更广泛的关注，他们观察到意外行为是用户沮丧的主要原因。即使用户最终学会绕过惊讶，每次惊讶都需要额外的心理努力来处理和记忆。

在软件工程中，这一原则被采用并超越了UI设计。它成为API设计的指导原则，"令人惊讶"的行为不仅会破坏个别用户，还会破坏整个依赖软件的生态系统。如今，POLA被认为是最基本的设计原则之一，与一致性、可预测性和简单性等概念并列。

## 核心要点

<Steps>
  <Step title="建立用户信任">
    当系统按预期运行时，用户会产生信心。他们可以预测结果，并对自己的互动感到掌控。
  </Step>

  <Step title="降低学习曲线">
    熟悉的模式允许用户从其他系统转移知识。减少学习时间；增加生产力时间。
  </Step>

  <Step title="减少错误">
    当用户能够预测系统行为时，他们的错误会减少。意外行为通常会导致错误，因为用户试图"纠正"正常情况。
  </Step>

  <Step title="改善可访问性">
    可预测的界面对每个人都更容易，但对依赖一致性的认知障碍用户尤其重要。
  </Step>
</Steps>

## 应用场景

<CardGroup cols={2}>
  <Card title="用户界面设计">
    按钮应该看起来像按钮，表现也像按钮。点击"提交"表单应该提交它，而不是保存草稿。
  </Card>

  <Card title="API设计">
    方法名称应该清楚地表明它们的作用。"updateUser"方法应该更新用户数据，而不是发送电子邮件或触发通知。
  </Card>

  <Card title="代码组织">
    文件和文件夹的组织方式应符合开发者的期望。配置文件应该放在配置目录中，而不是与业务逻辑混合在一起。
  </Card>

  <Card title="错误处理">
    错误消息应该清楚地解释出了什么问题以及如何解决。通用的"发生错误"消息会让用户惊讶，不提供任何解决路径。
  </Card>
</CardGroup>

## 经典案例

2012年，一个流行的照片共享平台做了一个违反POLA的改变：他们将"删除"按钮的行为从立即永久删除照片，改为将照片移动到"垃圾箱"文件夹，30天后自动删除。

用户感到惊讶。许多用户使用"删除"来释放存储空间，期望照片立即消失。他们不检查垃圾箱文件夹，当照片重新出现或存储没有减少时感到困惑。反弹很显著——用户觉得系统背叛了他们的信任。

该公司最终为高级用户恢复了这一行为，同时为免费账户保留了这一行为（以节省存储成本），但对用户信任的损害仍然存在。这个案例说明，即使出于善意的改变也可能与既定的用户期望发生冲突，从而违反POLA。

教训：在改变任何行为之前，考虑用户的期望。如果改变是必要的，要清楚地沟通并提供退出机制。惊讶——即使在技术上是合理的——也会产生摩擦。

## 边界与失效场景

如果从字面上理解，POLA可能成为创新的障碍。有时"正确"的解决方案是违反直觉的。例如，文本编辑器中的"撤销"功能让早期用户感到惊讶，但现在已成为预期。

关键是区分因设计不佳而导致的惊讶与因创新而导致的惊讶。创新需要教导用户新的模式。解决方案不是避免创新，而是逐步引入创新，并清楚地传达。

另一个失败模式是为了牺牲一致性而过度conformity。如果你复制了一个在上下文中有效但不适合你特定用例的界面，用户可能在局部不惊讶但在全局感到困惑。

边界条件：POLA应该指导设计但不应使其瘫痪。当创新需要令人惊讶的行为时，投入教育并提供清晰的反馈。

## 常见误区

<AccordionGroup>
  <Accordion title="误区：POLA意味着不创新">
    POLA不禁止新想法——它要求新行为的引入要经过深思熟虑。如果沟通清楚，用户可以学习新的模式。
  </Accordion>

  <Accordion title="误区：POLA只适用于UI">
    该原则适用于任何有用户的系统——包括使用API的开发人员、管理系统的管理员，甚至是代码的读者。
  </Accordion>

  <Accordion title="误区：用户总是知道他们想要什么">
    有时用户说他们想要一件事，但当得到它时却感到惊讶。POLA是关于理解*思维模型*，而不只是收集功能请求。
  </Accordion>
</AccordionGroup>

## 相关概念

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

<CardGroup cols={3}>
  <Card title="KISS原则">
    保持简单。简单、可预测的系统更容易理解，不太可能让用户惊讶。
  </Card>

  <Card title="一致性">
    一致的界面遵循既定的模式。POLA本质上是关于与用户期望的一致性。
  </Card>

  <Card title="思维模型">
    用户携带关于系统如何工作的思维模型。POLA是关于设计来匹配这些模型，而不是对抗它们。
  </Card>
</CardGroup>

## 一句话总结

<Tip>
  **设计系统以符合用户期望的方式运行——匹配他们的思维模型，保持一致性，当创新需要令人惊讶的行为时，要清楚地沟通并提供指导。**
</Tip>