H3.03.1non-blaming error copy in recovery设计研究
不把责任归于用户
别名: 归责文案 · blame the user · 指责
概念解释
恢复流程里的语气若把失败写成用户的过错——「你填错了」「你没有权限」当人格判决——人会从修任务切到为自己辩护。不把责任归于用户不是把所有锅揽到「我们」，而是陈述不满足的条件，并指出谁能改它。这条管语气对下一步动作的干扰，不管结果、原因、修法三句缺不缺，也不管内部术语和玩笑。
机制
指责把注意从对象状态转到自我评价。防御一旦启动，人不再核对字段，而是争论「我没错」或立刻离开以免再被判定。高频路径上的指责还会压低主动上报：同一句「操作有误」反复出现后，人不再反馈，产品失去本可修复的日志。反过来，把系统故障写成「你的网络有问题」，会让人去修错误的对象。清楚说出条件（需要 YYYY-MM-DD、需要管理员批准）不是归责，那是在给可执行约束；加上「又」「怎么还不」才把约束变成人格。
怎么研究
同一校验失败配三种语气：条件陈述、含第二人称责备、过度揽责的「都是我们的错」。
自变量：是否出现责备标记、责任主体是否与真因一致。 因变量：正确修改字段的比例、争论文案而非改值的比例、任务放弃、事后是否愿意报告这次失败。
不要用「喜不喜欢这句文案」当主指标。喜欢的责备句仍然可以毁掉恢复。观察的是下一步动作，不是评分。
边界
安全与合规可以坚定说出禁止事项和后果，不必改成软绵绵的道歉；禁止的是对能力或动机的评价。责任确实在用户可控输入上时，指出「这个日期早于开始日期」是条件，不是羞辱。恶意滥用的处置需要政策语言，不能为了不归责而写成系统故障。把每次失败都写成「我们的问题」会让人空等修复，该改输入的那一步就被跳过。
怎么落地
- 删除「你又」「请认真」「错误的用户」这类评价，改写成现值、期望条件和可行动的人。
- 权限类失败写清需要哪一类权限、由谁申请，不要写成「你无权做此事」当结尾。
- 系统侧失败不要默认写成用户环境问题；原因不明就写不明，不要为了有人可怪而指向用户。
- 验证：把失败界面拿给未参与设计的人，问「这句话在说谁做错了」以及「你下一步会做什么」。若答案是「在说我不好」或「不想继续」，语气已经抢走恢复。