归因方式决定用户自责还是迁怒系统
别名: 归因 · 归因理论 · 归因维度 · 自责 · 迁怒 · attribution theory · locus of causality · service failure
概念解释
失败之后用户会找原因，而失败文案的措辞是这场归因（attribution）的重要推手：把原因推向「我的错」，产出羞耻与悄悄退出；推向「系统的错」，产出愤怒但保留修复的期待。两头的极端都有代价——自责让用户离开（人不愿反复面对让自己显得愚蠢的系统），全怪系统摧毁能力信任（一个把每次小故障都认作「我们出错了」的系统，凭什么被托付要紧事）。较好的位置是把失败放进情境（「这一步没有成功」——局部的、这次的操作），并把修复工作交给系统。拟人化产品会把故障读作系统的态度问题，那是角色设计带出的另一种归因扭曲；普通失败文案面对的问题是，如何在归因维度上安放原因。
机制
归因理论的框架把原因沿几个维度分解：内部还是外部（原因在人还是在系统）、稳定还是不稳定（每次都这样还是偶发）、可控还是不可控（能不能改）。维度组合直接预测情绪与后续行为：内部加稳定的归因（「我就是不会用」）产出羞耻与无望，行为后果是回避与沉默流失；外部加稳定的归因（「这系统就是烂」）产出愤怒，行为后果是投诉与弃用；只有外部且不稳定、具体到这一步的归因（「刚才那一步没成功」）产出的是不带身份威胁的懊恼——留得住用户，且附带「再试一次」的意愿。文案是在给用户递归因材料：指责式措辞（「您输入了无效内容」）把原因按进内部一格，用户要么羞耻要么反驳；全盘揽责的措辞（「非常抱歉，我们搞砸了一切」）把偶发故障抬到稳定一格，用户据此下调对系统的能力判断。归因还会自我巩固——一次自责的经验累积成低自我效能，一次全怪系统的经验累积成能力不信任，文案只是在给这两条累积曲线递送每次的原料。
怎么研究
- 归因维度操作化范式：给被试一段失败情景，用问卷测其对原因在诸维度上的定位（内部/外部、稳定/不稳定、可控/不可控），再测情绪与行为意向（再试、投诉、离开）；维度定位作为中介变量，解释从「失败」到「行为」的路径。消费情境的经典版本是产品失效研究：让被试回忆或阅读一次产品故障，测归因、愤怒与更换品牌的意向，发现外部稳定归因经由愤怒中介了弃用意向。
- 界面失败的归因测量：在真实任务中制造受控失败（网络超时、提交丢失），会话结束后用回放引导用户复盘「你觉得问题出在哪」，对回答做维度编码；同时记录行为侧的沉默流失（不重试即离开）与自愿反馈量。
- 文案变体对照：同一失败配不同归因框架的文案（指责用户/情境化/系统揽责），比较重试率、完成率与事后评价。
- 方法论注意点：这条文献里相当一部分证据来自假设情景问卷（「想象你遇到……你会感觉如何」），测的是意向不是行为；实验室失败对用户没有真实代价，羞耻与流失这类强后果在低利害实验里天然测不足，需要现场数据补。
边界
- 诚实是硬约束：情境化措辞不能滑向否认。失败真实出在系统且反复出现时，用户会自己完成「稳定」的归因——几次「这一步没成功，正在重试」之后仍失败，继续轻描淡写就成了遮掩；此时文案应升级为承认（「我们这边出了问题，正在修复」）。措辞最多影响第一次的读法，重复的失败会自己说话。
- 先入之见框住文案的作用：对系统已有不信任的用户，无论文案怎么写都做外部归因；高度自信的用户则倾向不把失败归给自己。文案能移动的是中间地带，不是所有人。
- 情境化不等于含糊：「这一步没有成功」必须配上具体哪一步、为什么（可解释的那部分），否则用户会把含糊本身读成系统在遮掩，归因反而更糟。
- 跨情境外推要小心：高利害场景（支付失败、丢稿）中的归因强度与低利害场景不可比，同一句情境化文案在两类场景下的安抚作用差别很大。
怎么落地
- 逐条审查失败文案的归因指向：删掉一切指向用户能力的表述（「无效操作」「您输入错误」「请正确填写」），改写成对事件的状态描述（「这个日期格式没有被识别，已按今天生成」）——错的是这一次的输入，不是输入的人。
- 也不走另一个极端：用户侧真实出错时不必道歉揽责，那会抬升稳定归因、侵蚀能力信任；情境化加修复就够。
- 修复动作交给系统：自动重试、自动恢复草稿、自动回填正确格式——用户确认结果而不是重建过程；把修复揽给系统的同时，归因上仍保持对事件的如实描述，不额外揽成「我们的错」。
- 失败反复出现时升级措辞为承认加补救，不要让第 N 次的文案与第 1 次相同。
- 验证办法：会话回放配事后追问「你觉得刚才是谁的错」，对回答做内部/外部、稳定/不稳定的编码；跟踪失败后的无重试离开率（自责与无助的行为签名）与自愿报障量（参与修复的行为签名），改版前后对比。