Q5.11.4attractive sample data bias设计研究
好看的示例数据会让评审者低估真实场景的复杂度
别名: 好看示例偏差 · 示例低估复杂度 · pretty fixture bias
概念解释
评审里的示例常常被选成好看：短标题、高清图、理想用户、成功状态、刚好排满一屏的五条。观看者据此以为真实场景也是这种密度和这种合作程度，于是低估搜索噪声、缺图、失败态、多语言混排和一天几百条的滚动。好看示例造成的低估针对的是决策者的复杂度模型，而不只是测试参与者有没有撞上边界。与占位掩盖不同，这里数据可以是“真的”，只是被挑过；与极端值测试不同，这里的问题是给谁看、挑了哪一段。
机制
人用眼前的例子估计分布。精选示例是分布的最好一段，心理上却被当成典型。好看还带叙事：成功的人、完整的档案、漂亮的照片，暗示产品运行在一个已经整理好的世界里。复杂度（审核队列、冲突编辑、垃圾内容、设备差异）被编成“上线后的运营问题”，进不了设计范围。越是向高层和客户演示，挑选压力越大，低估越严重。示例一旦进入需求文档和营销，还会反向约束产品：真实难看的数据被视为偏差，而不是主场景。
怎么研究
把给评审的数据集与生产抽样的描述统计对照：长度分位、缺图率、失败态占比、语言混合。让未见过精选示例的人先看随机抽样再看精选，比较他们对“日常有多乱”的估计。编码评审发言里把复杂度外推到运营的次数。材料因子可以是“精选五条”对“随机二十条含失败”。不要用精选示例上的满意度或“看起来很清晰”当作内容复杂度已解决。
边界
教学、品牌和招聘演示需要可读的例子，好看是合法目标，只要不拿去锁设计决策。专家评审若同时拿到随机抽样，低估可以被纠正。有些产品的生产数据本身就被运营洗得很干净，精选与真实差距小。反过来，内容平台和政务系统的真实分布极脏，精选造成的偏差最大。时间极短的评审只能看几条，应明确告诉房间“这是最好的五条，不是中位数”。
怎么落地
- 给决策评审准备两叠：精选说明愿景，随机（或脱敏随机）说明日常；先看随机。
- 示例旁标注它在分布中的位置（最好 10% / 中位 / 失败态）。
- 禁止把精选截图单独写进需求作为“默认列表长这样”。
- 若只有时间看一叠，看含失败与缺字段的那叠，而不是最好看的那叠。