需求验证与用户测试：原型、可用性与 A/B

需求验证与用户测试：原型、可用性与 A/B

需求从"我们认为用户想要"变成"用户确实需要且能用"，离不开验证。Nielsen Norman Group 指出，即使是顶尖设计师也无法在不观察真实用户的前提下设计出"足够好"的体验——唯一的方法就是测试。本文梳理原型测试、可用性测试、A/B 测试与访谈四类方法，以及各自的使用时机。

为什么需要用户测试

用户测试（可用性测试）的目标通常包括：发现设计中的问题、找到改进机会、了解目标用户的行为与偏好。现代界面变量极多，加上人脑的复杂性，组合数量巨大，只有通过基于真实用户观察的迭代设计才能逐步逼近正确体验。

用户测试的三要素

一次典型的可用性测试包含三个核心角色与要素：

• 主持人（Facilitator）：给出指令、回答问题、提出追问，同时避免暗示性提问影响参与者行为。
• 任务（Tasks）：贴近真实生活的活动，措辞至关重要——任务描述中的微小错误可能让参与者误解或受到"启动效应"影响。
• 参与者（Participant）：产品的真实或相近用户，常被要求"出声思考"（think-aloud），边操作边说出自己的想法。

一份典型的测试脚本不需要很长，任务清单通常 4-6 个，按真实使用顺序排列。以购物车结算流程为例：

注意任务 1 的措辞是"昨天加入购物车的外套"，而不是"点击购物车图标"——后者等于把答案告诉了参与者，测不出真实的导航路径。任务措辞的每个细节都可能改变测试结果，这也是 NN/g 反复强调"任务要贴近真实生活"的原因。

定性 vs 定量测试

定性测试收集洞察、发现与轶事，最适合发现体验问题，也最为常见；定量测试收集任务成功率、任务耗时等指标，最适合建立基准（benchmark）。对单一用户群的定性研究，NN/g 建议 5 名参与者即可发现大部分最常见问题。

远程 vs 现场测试

远程测试通常更省时省钱，分两类：远程有主持测试（moderated）与面对面类似，通过屏幕共享进行；远程无主持测试（unmoderated）由测试工具代替主持人自动发放任务、收集指标与录像，适合规模化的快速验证。现场测试则便于观察肢体语言与真实环境。对 AI 类功能，可采用AI 应用虚拟用户测试中的方法，用虚拟用户大规模覆盖场景。

原型测试与 A/B 测试

原型测试在写代码之前用纸面原型、可点击原型验证信息架构与交互，成本低、迭代快，是需求验证的第一道关。A/B 测试则用于上线后对两个方案做量化对比，例如按钮文案、定价展示或引导流程。两者互补：原型测试回答"方案是否可用"，A/B 回答"哪个方案更优"。正式写测试场景前，可先把需求固化为用户故事与验收标准，让任务与验收口径一致。

四类方法的定位对比如下：

一个具体的验证流程

假设团队要给一个记账 SaaS 增加"自动对账"功能。第一轮先做 5 场用户访谈，发现"手动对账太累"确实是高频痛点，但用户根本听不懂"自动对账"这个词，他们说的是"让系统自己把账对上"——这直接改变了功能命名。第二轮用可点击原型测 5 名用户，发现用户预期"导入账单后 10 分钟内出结果"，而团队原本计划 30 分钟批量处理，于是调整了异步任务的进度提示。上线后对"对账结果页"做 A/B，新的汇总卡片让"下一步该做什么"的点击率提升了 21%。

这个案例的启示是：每一轮测试都回答一个具体问题，而问题来自上一轮的发现。验证不是一次性的评审会，而是嵌入到开发节奏里的小循环。

参考：Nielsen Norman Group《Usability Testing 101》https://www.nngroup.com/articles/usability-testing-101/

测试成本与 ROI

最简单的"折扣可用性测试"成本很低——租用会议室、付少量参与激励，三天即可完成一轮（规划、测 5 名用户、分析并转为改版建议）；复杂的跨国、多用户组、眼动追踪研究则成本可达数十万美元。但即便是高成本研究，ROI 通常依然为正，因为修复问题的成本远低于上线后再返工。

16IDC 观察

对建站与 SaaS 团队，建议按"先访谈与原型验证需求 → 再可用性测试验证可用性 → 上线后 A/B 持续优化"的顺序建立验证闭环。每轮测试不必追求样本量，5 名用户 + 出声思考 + 明确的改进清单，就足以让产品每个迭代都更贴近用户。完整的分析流程，可回到本站需求分析分类。

原文来源：https://www.nngroup.com/articles/usability-testing-101/