Q5.07.2prototype-to-context overgeneralization设计研究
原型顺畅不代表真实场景顺畅
别名: 原型顺畅外推 · 场景外推广 · lab-smooth fallacy
概念解释
一场测试里任务走完了、没人卡住、满意度也不错，只能说明在这场测试的场景里走得顺。把这份顺畅推广到真实工作、家庭或窗口服务，是从原型到情境的过度推广（prototype-to-context overgeneralization）。测试场景删掉了并行任务、打断、真实后果、残缺数据和他人在场。原型顺畅是局部观察，不是现场预测。与“演示路径掩盖异常”不同，这里即使走的不是演示稿，场景本身仍可能不真。
机制
可用性测试为了可重复，会固定任务、安静房间、准备好的账号和主持人可救助的气氛。这些条件让流程的内在逻辑变得可见，也同时移走了让流程失败的外部负荷：电话进来、库存不对、顾客在排队、设备电量不足。人在无后果时更愿意探索，在有后果时更保守或更慌。团队看到的“顺”往往是被抽掉负荷之后的顺。外推时若只保留界面、不保留情境约束，等于换了一个现象还沿用同一结论。
怎么研究
在计划里把目标情境的负荷写成清单：打断、时间压力、共享设备、真实差错成本。实验室通过后，用情境化复测：现场观察、情境访谈、或带真实负荷的扮演。比较同任务在安静实验室与现场的失败类型，而不是只比较成功率。生态效度文献强调：实验室检出的问题常仍为真，但实验室的“无问题”不可直接写成现场无问题。报告应分开“流程在受控任务下可完成”和“在目标情境下可完成”。
边界
早期结构探索可以、也应该在低负荷下进行，否则问题会搅成一团。对几乎只在安静、单人、桌面发生的任务，实验室顺畅的外推距离较短。专家用户在自己工位上的测试已经带部分真实情境，但仍可能缺少客户、高峰和故障。完全现场又会牺牲可重复和控制，需要另一套方法，而不是把实验室标准硬套上去。
怎么落地
- 每条“走得顺”的结论后面注明情境：任务、场所、有无真实后果。
- 列出实验室删掉的负荷，把其中最可能翻转结论的几项排进下一轮现场。
- 禁止在评审中只播实验室顺畅片段作为“用户没问题”的证据。
- 现场若出现实验室没有的失败，以现场为准，回头改的是情境假设，不是“用户这次状态不好”。