第 12 章 · 找一个人，不解释，让他用

第三阶段 · 让它能用第 12 章Build Cycle · 验证

你一开口解释，这次测试就作废了。

对付：发布鸿沟

这是发布前最有价值的 20 分钟，也是大多数人跳过的一步。

机制

无指导测试Unguided Test

把东西交给一个人，不做任何说明，看他能不能自己用成功。

规则只有一条：你不能开口。 一开口这次测试就作废了。

为什么不能开口：你要测的正是「产品自己能不能说清楚」。你补的每一句话，都是产品本该说而没说的话。真实用户那里没有你。

这 20 分钟会非常难熬。你会看见他点错地方、看不懂某个词、在一个你觉得显然的地方卡住。你会特别想说「那个按钮在右边」。忍住。

观察时记三件事：

不要问「你觉得怎么样」。那会得到一句礼貌的「挺好的」，没有任何信息。要问就问「你刚才在那里停了一下，当时在想什么」。

可用性问题Usability Issue

用户想做某件事，但产品没让他知道怎么做。

它和 bug 不同：bug 是东西坏了，可用性问题是东西好的但没人看得懂。后者在你自己测试时永远发现不了。

20 分钟，三个问题合成案例

林舒请同组的运营同学试用 · 发布前一天

第 8 秒：对方盯着 5 个空文本框，问「这个要粘什么」。林舒的设计里，框上方写的是「渠道 1」到「渠道 5」——她自己知道指的是后台导出的原始数据，别人不知道。

第 2 分钟：对方粘进了第一段，然后去点「合并」。合并按钮是灰的，但没有任何提示说明为什么。她等了几秒，以为页面卡了。

第 6 分钟：选列的下拉框，对方把「日期」那一列选成了「曝光量」。界面上没有任何方式让她发现选错了，直到合并出来的表全乱。

三个问题，没有一个是 bug。全部是「东西是好的，但看不懂」。

林舒自己测过十几遍，一个都没发现——因为她每次都知道该填什么、知道按钮为什么是灰的、知道哪列对哪列。

找一个人，20 分钟。标准：他属于你的目标用户，或者至少接近；他没见过这个东西；他愿意在你盯着的时候用。

流程：

找不到人的话，退而求其次：换一台设备、隔一天再自己用一次。效果差很多，但比不做强。

做一次无指导测试，记录观察到的三类信息。

然后把发现的问题分成两类：挡住主路径的，和不挡的。只修第一类。

产出：一份观察记录，至少三条，每条写明是在哪一步、他做了什么、你当时想说却忍住的是哪句话。

「他不是目标用户，所以不算」是最常见的逃避

在找到真正的目标用户之前，任何一个没见过它的人都能暴露出 80% 的可用性问题——因为那些问题和领域知识无关，和「界面有没有说清楚」有关。

等「真正合适的人」通常等于不做这一步。

你想说的那句话，就是产品缺的那句话

测试过程中你最想开口的那个瞬间，记下来。那句话应该以某种形式出现在界面上——一句占位提示、一行说明、一个禁用状态的原因。