B5.10.2Error Recovery设计研究

错误需按可自行恢复与不可恢复分开统计,合并计数会掩盖严重问题

别名: 可恢复错误 · 不可恢复错误 · 错误分层

概念解释

「错了一次」与「错一次就完不成任务」是两类事实:可自行恢复的错误(点错标签后立刻改回来)用户自己消化;不可恢复的错误(数据被覆盖、订单重复提交、找不到返回路)造成实质损失或任务终止。合并成一个错误总数时,大量轻错误能把少数致命错误淹没在统计里。

机制

两类的代价函数完全不同:可恢复错误的成本是几秒冗余操作,不可恢复错误的成本可能是重做全部工作或永久损失。可用性上真正需要设计干预的是后者——它们暴露的是防错与退出机制的缺失。合并计数的算术后果是均值支配排序:一个界面错误总数低但含一次不可恢复错误,会在排序中胜过错误总数高但全部可恢复的界面,而真实风险排序应该相反。

怎么研究

测量协议把恢复状态编码进错误记录:发生、是否被用户察觉、是否自行恢复、恢复耗时、不可恢复时的后果等级。统计上分别报告两类计数与「恢复成功率」;不可恢复错误单列缺陷清单,不允许被均值稀释。日志数据里可用「撤销/返回操作序列」识别可恢复错误,用「任务中途终止伴随错误」标记疑似不可恢复事件,再人工核验。

边界

恢复与否是相对任务与数据状态而言的:草稿场景下几乎一切可恢复,支付场景下大多数错误不可恢复,两场景的错误率不可直接比较。「自行恢复」依赖用户的经验储备,专家的可恢复范围比新手宽,同一错误在新手手里不可恢复——分层统计应按用户经验组分开。恢复成本也有梯度,二分法是简化。

怎么落地

  • 错误记录模板固定恢复字段:察觉、恢复方式、耗时、后果等级。
  • 验收标准分级:不可恢复错误单独设阈值(理想为零),不与总错误率混用。
  • 对高危操作铺防错层(确认、二次输入、软删除),目标是把「不可恢复」类别清空而不是降低总数。

延伸

  • 同组B5.10.1 错误率与有效性相关但需单独报告,二者的改进手段不同 · B5.10.3 零错误的界面可能只是把出错变成了放弃 · B5.10.4 错误率对界面变更的敏感度高于满意度,适合作为回归监测量
  • 相邻I1 状态、时间与响应 · Y1 安全关键交互
  • 站内检索error recovery · recoverable errors · error severity

同组卡片

快捷操作

分享

分享当前页面

ios_share

https://hci.top/zh/handbook/B5.10.2