错误预防

错误预防是一种设计实践，它通过构建界面结构，使用户难以甚至不可能犯错，而不是事后依赖完善的错误提示信息。它是可用性领域最古老的原则之一，最早出现在尼尔森的启发式方法和早期的人因工程文献中。其核心在于：避免错误无需任何成本，而纠正错误却需要耗费时间、精力，而且往往会损害用户信任。

这些技术可以归纳为几个易于识别的类别。约束可以完全防止无效输入，例如日期选择器会阻止选择不可能的日期，或者数字字段只接受数字。合理的默认值可以减少可能做出错误选择的次数。在输入之前（而不是在拒绝之后）显示清晰的格式要求，可以避免用户猜测字段要求所带来的挫败感。确认步骤可以防止不可逆操作。如果可以提供撤销功能，则撤销功能优于确认，因为它不会中断用户通常正确的操作。

人因工程区分了失误和错误，而这种区分会影响补救措施。失误是指执行过程中的失败，即用户本意是好的，但却做了错事：例如打字错误、点击了相邻的控件、错过了小目标等等。这些问题可以通过物理设计来解决，例如增大目标尺寸、增加间距、将破坏性操作与建设性操作分开，以及提供容错的输入处理方式。错误是指计划过程中的失败，即用户完全按照自己的意图操作，但其意图并不适合当前情况。这些问题需要更完善的信息、更清晰的模型和更有用的反馈，而仅仅增大目标尺寸是无济于事的。

验证时机的选择是一个经常需要面对的实际问题。在提交时进行验证会迫使用户在创建问题很久之后才去纠正，这往往脱离了上下文，而且通常是在页面重新渲染导致用户输入内容丢失之后。每次按键都进行验证会在用户输入完成之前就标记错误，这会让人感觉很不友好。在字段失去焦点时进行验证，同时确认有效输入，是大多数情况下测试效果最佳的模式，而且无论验证时机如何，在验证失败时保留所有已输入的数据都是不可妥协的。

错误预防还必须考虑到系统自身故障时的情况，因为并非所有错误都源于用户。支付失败、超时、会话过期和连接丢失等情况，用户并没有做错任何事，他们需要的是清晰明确的后续步骤，而不是描述内部状况的消息。对于系统故障而言，在会话过期后保留工作、在安全的情况下透明地重试以及解释下一步操作，就相当于错误预防。

错误预防不仅适用于界面，也适用于围绕产品的运营决策。如果系统允许在账户仍有未结余额的情况下关闭账户、订购无法送达该地址的商品，或在营业时间之外预约，那么这些错误并非源于交互设计，而是源于业务规则。由此产生的问题往往以客户投诉的形式出现，而非可用性问题。要识别这些问题，需要追踪实际操作的限制条件，并确认界面在信息可用的最早阶段就强制执行这些限制，而不是先接受输入再在之后出现错误——后者才是导致最昂贵补救工作的模式。

从商业角度来看，预防措施最有效的流程是那些高价值、高放弃率的流程：结账、注册、申请表，以及任何用户完成一次后难以继续的流程。在这些流程中，一个错误往往会导致整个会话彻底结束。利用表单字段分析和会话录制来识别错误实际发生的位置，是标准的诊断工作。 用户体验审核而由此产生的修复方案是目前最可靠的方案之一。 CRO服务 积压是因为它们针对的是已记录在案的失败案例，而不是关于偏好的假设。