上线前先看五个人怎么用：vibe 项目的可用性测试实战

以下示例中的人物与产品均为虚构。

先说判断：访谈问的是想法，测试看的是行为

一个人团队最常见的自我欺骗，是把“问过用户”当成“验证过产品”。访谈里用户说“这个功能我肯定会用”，上线后却一次都不点；问卷里八成人说“界面很清晰”，真让他们自己操作，第一步就卡住了。这不是用户在撒谎，这是两种完全不同的信息：人对自己未来的行为预测得很差，但对自己当下的行为诚实得很。访谈拿到的是态度，测试拿到的是行为，而产品最后拼的是行为。

所以我的判断是：上线前最值得花的一天，不是再加一个功能，而是找五个人来，坐在旁边看他们用你的产品，什么都不提示，什么都不解释。五个人里有三个人在同一个地方卡住，那个地方就一定有问题，不用再争论。测试的价值不在于样本量大，而在于你亲眼看到了卡住的瞬间：鼠标悬停、犹豫、点错、退回、叹气。这些瞬间在任何数据报表里都不会出现，但在测试里一眼就能看见。

划界先说清楚，避免和站内已发指南重复：用户访谈指南讲的是怎么问出真实需求；A/B 测试指南讲的是用数据对比两个方案；反馈闭环指南讲的是上线后持续收集意见。本文不重复这三点，只讲上线前的一种定性方法：给用户具体任务、看他们怎么做、按严重程度修。这篇不讲问卷设计，不讲数据分析，只讲“看人用产品”这一件事。

虚构示例贯穿全文：跑团组织者周野用 AI 搭了一个跑团报名小程序“晨光跑团”，想在下次开团前测一次报名流程。所有人物和数字都是编的，只用来讲方法。

第一步：测什么？只测主流程，而且只测三到五个任务

测试的第一步不是找人，是定任务。任务清单的取舍标准只有一个：这个流程如果走不通，用户今天的目的是不是就达不成了。报名、付款、改时间、找入口，这些算；换头像、改昵称、看往期照片，这些不算。周野的第一版测试只列了四个任务：找到本周六的跑团并报名、为朋友再报一个名额、把周六改成周日、报名成功后找到集合地点。四个任务走完，报名流程的生死就测完了。

任务要写成场景，不要写成操作指令。写“请你为朋友再报一个名额”，不要写“请点击右上角的加号再点确认”。前者测的是用户能不能自己找到路，后者测的是用户会不会照着念说明书。场景里要给动机，不要给路径：动机是真实的，路径是待验证的。任务之间按真实顺序排，不要按功能模块排，用户在真实世界里就是按顺序遇到这些事的。

还有一个取舍：一次测试不要超过五个任务。超过五个，后面任务的数据质量会直线下降，用户累了，开始乱点，只想快点结束。宁可测三个任务测透，也不要测十个任务测个大概。测不完的功能，留到下一轮，这不是偷懒，这是对数据的诚实。

第二步：找五个人，别找熟人，别找内行

五个人够不够？对于找“卡住的地方”这个目标，够了。这是一个经验法则：同一个严重问题，五个人里至少会有一两个人撞上；测到第五个人，新问题已经很少了。一个人团队没有条件做二十人测试，也不需要。五个人测出的前三个问题，修掉之后，产品就已经比测试前好用很多。追求样本量是数据团队的事，找问题是产品团队的事。

找什么样的人，比找多少人重要。第一不要找熟人：朋友、同事、家人会客气，会替你找补，会说“其实也还行”。第二不要找内行：懂行的用户会自己绕过坑，而你的真实用户不会。第三要找目标用户本人：跑团报名就测真正跑过步、报过名的人，不要测从来不跑步的朋友。周野的第一批测试者就是跑团群里的普通团员，不是产品圈的朋友。

报酬要给，但不要给得让对方不敢说真话。一杯咖啡、小额红包都可以，关键是开场白要说清楚：测的是产品，不是测你；卡住了是产品的错，不是你的错；你越是卡住、越是抱怨，对我们帮助越大。这句话不是客套，它直接决定了测试者敢不敢在你面前表现出困惑。没有这句话，测试者会努力表现得很聪明，你就什么都测不出来。

第三步：主持人只做三件事：给任务、请出声、别帮忙

测试当天，主持人的工作清单只有三条。第一，给任务，一次只给一个，做完再给下一个。第二，请对方出声思考：心里想到什么就说什么，比如“我以为点这里能报名”“这个字我看不懂”。出声思考是测试的灵魂，没有它，你只能看到“卡住了”，看不到“为什么卡住”。第三，别帮忙。用户点错了，不要纠正；用户问“是不是点这里”，不要回答，只说“你觉得呢，按你的想法来”。

最难的就是第三条。看着自己的产品被人用错，第一反应是解释、是辩护、是伸手去点。但每一次帮忙，都毁掉一条数据：你永远不知道如果不帮忙，用户自己能不能走出来。正确的姿势是记下来：几点几分、在哪个页面、因为什么卡住、用户原话说了什么。原话最重要，写报告的时候，“我以为报名按钮在下面”比任何总结都有说服力。

观察者也要分工。一个人主持，一个人记录，不要让主持人又提问又记笔记，顾此失彼。记录表提前准备好四列：任务、是否完成、卡住的点、用户原话。测试结束当天就整理，不要拖到下周，记忆会把细节磨平。录屏可以开，但必须先征得同意，并且只用来回看细节，不代替现场记录。现场的感受——叹气、犹豫、笑出声——录屏不一定录得到，记录表要写下来。

第四步：问题按严重程度分级，不要按出现次数排序

测试结果最常见的误读，是按出现次数排序：五个人都提到的先修，一个人提到的往后放。这个排法是错的。一个人提到的阻塞问题——比如报名最后一步付不了款——比五个人都提到的轻微问题——比如按钮颜色不好看——严重得多。分级只看一个标准：这个问题离“用户达不成目的”有多近。

我的分级很简单，只有三档。阻塞：用户不靠帮忙就完不成任务，比如找不到报名入口、付款失败、改期按钮点了没反应。严重：用户能完成，但要绕路、要猜、要试错，比如集合地点藏在三级页面里、报错信息没说清楚。轻微：用户能完成，只是不舒服，比如文案别扭、间距不均。修的顺序就是这个顺序：先修阻塞，再修严重，轻微留到有空再说。

修完还要复测，而且复测不用重新测全部，只测修过的任务。周野修掉报名入口问题后，只找了两个人重测报名任务，两个人一次通过，这轮才算闭环。没有复测的修复只是猜测：你以为修好了，其实可能只是换了一种卡法。复测的人最好是新面孔，测过的人已经学会了流程，测不出真实效果。

第五步：数字可以记，但不要被数字骗了

测试里可以顺手记三个数字：任务成功率、完成耗时、出错次数。这三个数字有用，但只能用来对比同一任务的前后变化，不能用来跨任务比较，更不能用来给产品打分。报名任务成功率从五分之二涨到五分之四，说明修复有效；但报名成功率百分之八十和改期成功率百分之六十放在一起比，没有意义，因为任务难度本来就不一样。

系统可用性量表，也就是常说的 SUS 问卷，十道题、五分钟，可以在测试结束时让用户填一份。它的作用是给“整体好不好用”一个可比较的锚点，方便下个版本对比。但要记住，SUS 是体感分，不是体检报告：分数涨了不代表问题修完了，分数没涨也不代表白测了。真正决定修什么的，永远是观察记录里的卡住瞬间，不是问卷分数。

还有一类数字不要记：用户说“喜欢”或“不喜欢”的次数。测试不是投票，喜欢不等于好用，不喜欢也不等于难用。用户可能喜欢配色但完不成报名，也可能抱怨界面土却一路畅通。把“态度票”从报告里删掉，报告会瘦一圈，但可信度会高一截。

反模式：这五种测试等于没测

第一种，演示式测试：主持人先演示一遍流程，再让用户照着做。这测的是模仿能力，不是可用性。第二种，引导式提问：“你觉得这个按钮是不是不太明显？”问题里已经藏了答案，用户只会点头。第三种，熟人测试：找朋友来测，朋友全程顺利，因为朋友不好意思卡住。第四种，只测 happy path：全程按最顺利的路径走，不测输错、断网、返回、改主意这些真实情况。第五种，测完不修：报告写得很漂亮，问题列了二十条，下一版一个没改，等于用一天时间证明了自己知道问题在哪。

远程测试和无主持测试也可以用，但要认清它们的边界。远程主持测试适合用户分散在各地的情况，流程和现场一样，只是要通过屏幕共享看操作，网络卡顿会丢细节。无主持测试是把任务和录屏工具发给用户、让用户自己做，成本低、量大，但拿不到出声思考，也没法追问“刚才为什么停住了”。一个人团队的第一轮，优先做现场或远程主持测试；无主持测试留给后面的大批量验证。

测试之后：报告怎么写，团队才愿意改

测试做完，真正的难关才开始：怎么让报告里的发现变成下一版的改动。一个人团队没有这个烦恼，测完自己就是改的人；但只要团队超过两个人，报告的写法就决定了问题会不会被修。最常见的失败报告有两种：一种是流水账，把五个人每一步都写下来，读完不知道先改什么；另一种是情绪化总结，“用户觉得不好用”，没有证据、没有位置、没有原话，开发看了也不知道改哪里。

好报告只有三部分，每部分都不超过一页。第一部分是结论先行：三个最严重的问题，每个一句话，写清它堵住了哪个任务。第二部分是证据：每个问题配一段用户原话、一个卡住的截图或时间点，让人无法反驳“这只是个别现象”。第三部分是建议：每个问题给一个具体改法，不要只写“优化报名流程”，要写“把报名按钮从二级页面移到首页卡片上”。结论、原话、改法，三件齐了，报告才有推动力。

还有一个容易被忽略的习惯：测试视频剪辑。把五个人的卡住瞬间剪成三分钟的合集，团队一起看一遍，比任何报告都管用。人对自己亲眼看到的困惑是无法抵赖的，而文字报告总可以被解释成“用户太笨”。剪辑的时候注意保护隐私：只剪操作画面和原话，不要露脸、不要放全名，对外分享更要先征得同意。周野就是把报名卡住的片段发到团队群里，当天就排进了下一版。

再补一个常被跳过的环节：测试对象的多样性。五个人如果全是同一种人，测出来的问题也会是同一种。至少要覆盖两种差异：熟练程度的差异，找一个常用手机应用的人，也找一个不太会用手机的人；设备的差异，至少有一台安卓、一台苹果，或者一台旧手机。周野第二轮就特意找了一位五十多岁的团员，结果发现报名页面的字体在小屏上根本看不清，而年轻团员从来没提过这个问题，因为他们眼睛好、会放大页面。多样性不是政治正确，是找问题的手段：同质样本测出的问题清单，永远比真实用户遇到的问题清单短一截。招募的时候多问一句对方的设备和使用习惯，花不了十分钟，换来的可能是上线后最致命的那一个问题。另外要记得给测试者留出反馈出口：测试结束时问一句还有没有什么想吐槽的，往往能捞到任务清单之外的发现，比如有人会主动提到短信通知里的集合时间写错了，而这根本不在当天的任务范围内。还有一个细节值得写进主持人手册：测试进行到一半用户想放弃是正常现象，不要劝也不要施压，记下放弃的那个任务和那句话就够了，放弃本身就是最强烈的可用性信号，比任何量表分数都真实。

最后一句话：可用性测试不是仪式，是产品上线前最便宜的保险。五个人、一天时间、四个任务，换来的可能是上线后几百个用户的流失被提前拦住。写代码的时候我们习惯先跑测试再上线，对产品体验也应该一样：先看人用，再谈上线。

一周落地流程与检查表

• 周一：定三到五个主流程任务，写成场景，不写操作指令。
• 周二：找五个目标用户本人，不找熟人、不找内行，约好时间与报酬。
• 周三：准备记录表（任务、是否完成、卡住的点、用户原话），主持人只练三句话：给任务、请出声、别帮忙。
• 周四：逐个测试，每人不超过五十分钟，现场记原话，当天整理。
• 周五：按阻塞、严重、轻微三档分级，先修阻塞，修完找新人复测修过的任务。
• 开场白必须说清：测的是产品不是测你，卡住了是产品的错。
• 报告里只写观察到的行为记录，不写态度票；数字只用来对比同一任务的前后变化。
• 录屏须先征得同意，只用于回看细节，不代替现场记录。