章节 10

你没有在听

确认偏误如何在反馈抵达之前就把它筛掉

证据就摆在眼前，你仍可能带着自己想要的答案离开。这就是确认偏误。你脑中已经有一套理论，于是把研究当成了本该替它找支持的东西。

你在检验自己想保住的故事

1960 年，Peter Wason 给人们一个数列：2、4、6，让他们找出规律。大多数人尝试的例子，都符合自己已有的猜测。很少有人尝试能打破那条规律的例子。他们并没有真正检验想法，而是在寻找支持。

Raymond Nickerson 回顾了几十年的相关研究，指出了令人不愿面对的一面：“一旦采取了某种立场，一个人的主要目的就变成了捍卫它”（译自英语）。这里起作用的就是这个机制。你不会一视同仁地看反馈。你偏向符合预期的部分，匆匆略过不符合的部分。

所以，满屋子笔记仍然可能得出一个不诚实的结论。偏差就在你注意什么、相信什么，以及找理由排除什么之中。

它也藏在你热心记录的内容里。设计师常把支持自己的引语完整记下，却用寥寥几个字概括反证。“边缘情况。”“用户没搞懂。”“需要新手引导。”在分析总结变成幻灯片之前，筛选早已开始。

Segway 在 2001 年推出时，人们对它寄予了厚望。它本该重塑城市出行。当人们质疑 5000 美元的价格、人行道规则，以及大多数城市并非为它而建时，回应常常相似：人们还没理解它。

这正是这个例子有用的原因。负面信号不断到来，却总被翻译成错误诊断。不是“产品还不足以适应世界”，而更接近“世界还没跟上”。头五年，它总共卖出 3 万台。2020 年停产时，二十年累计销量不到十万台。

这就是产品形态的确认偏误。警告没有消失，只是被反复解读，直到支持你原本想要的故事。

这套动作也不断出现在更小的产品项目里。测试失败，成了表达问题；转化率低，成了用户教育问题；采用率差，成了用户发现不了功能的问题。有时的确如此。有时，它只是比“东西本身没有打动人”更好听的故事。

仔细听动词，就能听出区别。学习的语言是“那里发生了什么”“他们为什么停下”。防御的语言是“他们没懂”“我们得解释得更清楚”。前一组让你开始探索问题，后一组却让你还没看清就停止了探究。

Carol Dweck 在这里有用，原因更具体。如果把测试当作一场以通过或不通过来判定自己对错的考试，偏差就会更强。如果把测试当作寻找哪里会坏，你就更有机会在把坏信号修饰得好听之前，先看见它。

我在意的是这个分岔。这里主要不是自我的问题，而是做法的问题。你做这场测试，是为了学习，还是为了放心上线？

我见过设计师引用那个成功完成任务的参与者，却找理由把另外三个没完成的参与者排除在外。没有戏剧性的事，没有撒谎，只是选择性地认真。

研究开始之前，写下什么能证明你错了。这才是做法。不是“保持开放”。把失败条件写到纸上。什么发现会让你改方向？什么行为会说明目前的做法站不住？如果不先定义，测试就会变成一堆印象，事后任你按喜欢的方式整理。

解出 Wason 问题的人，尝试了可能失败的数列。这里也需要同样的本能。别只收集设计的支持材料，去找设计会坏掉的那个点。

分析总结时也一样。指定一个人，专门论证当前方向不该上线。不是因为他本来就这么想，而是屋里至少需要一个人，努力让相反证据保持原貌。

回看笔记时，先标出出乎意料的地方，不是最符合当前故事的引语。让屋里安静下来的时刻。停在无人预料之处的参与者。在 Figma 里看着安全、实际操作却乱了的那一步。没人保护，它们就最容易被磨平。而通常也正是这些部分，告诉你设计真正的薄弱之处在哪里。

如果证据只有在赞同你时才算数，你就没有在听。