T2.04.2Blame-free but explicit error responsibility设计研究
不把责任归于用户
别名: 非归责错误文案 · 输入边界 · 责任边界
概念解释
非归责但责任明确的错误文案（blame-free but explicit error responsibility）描述不满足的输入、权限或系统条件，并说明谁能采取哪项修复，而不评价用户的人格、能力或动机。“日期需为 YYYY-MM-DD”可以清楚指出输入边界；“你又填错了”则把条件问题变成人的过错。不归责不是含糊，也不是所有消息都用“我们”承担并非系统可控的责任。
机制
指责会把注意从修复转向防御，而模糊的中性话又会隐藏实际解决者。将事实分为 submitted value、expected constraint、system state 和 responsible actor，用户就能知道改输入、请求管理员、等待系统还是联系支持。高频输入失败还可能表明前置约束、控件或默认值设计不足；把责任全写给用户会遮蔽产品应修的缺口。
怎么研究
在格式、资格、权限、服务故障和多人协作情境中比较措辞，测能否正确指出问题条件、解决者和下一步，同时观察羞辱感、争议和再次失败。结合错误日志判断是输入不符、规则变化、系统校验错误还是权限配置，避免把文案效果与错误分类错误混为一谈。邀请实际角色参与，不从一次情绪评分推断普遍偏好。
边界
明确用户可控输入不等于归责；安全与合规场景也可坚定说明禁止条件和后果。若责任确属管理员、组织策略、外部服务或产品系统，应直接命名可行动主体，但不泄漏不应公开的策略细节。恶意行为和滥用处置仍需准确政策语言；本规则不要求以轻柔语气弱化边界。
怎么落地
- 将消息拆成现值/发生结果、期望条件、可行动主体和修复动作，删除人格判断、反问、羞辱及无必要的感叹。
- 输入错误展示可接受格式、范围或示例，并尽量保留用户输入；权限错误说明需要哪类公开权限以及由谁申请或批准。
- 系统和外部故障如实归属到可安全说明的层级；原因未知时不把空白默认归给用户。
- 监测重复校验失败、争议工单和恢复率；同一输入持续失败时修约束提示、控件或验证逻辑，而非继续加重措辞。