可用性测试

小唐第一次主持可用性测试，觉得自己准备得很充分。测试计划写了三页，任务脚本改了四遍，招募条件跟产品经理对过两轮。第一个参与者进来，她说了开场白，请对方打开报销系统："假设你需要提交一次这周的差旅费用。"

然后她看见了。

参与者的鼠标在"新建报销"上停了一下，移到"费用申请"上，再移回来。在两个选项之间来回移了两次。最后选了"标准用户"——错了。

小唐在笔记本上写："标签前缀'标准'二字可能误导了认知——待验证。"

这句话后来成了这个项目最关键的一条发现。不是因为它揭示了什么复杂问题，而是因为它暴露了一件很简单的事：团队在会议室里不会发现这个问题。设计师、产品经理、研发围在一起评审界面，每个人都知道"标准用户"是给普通员工用的——懂业务的当然懂。可新员工不懂。刚入职三天的销售助理，面对"标准用户"和"费用管理员"两个标签，只能猜。

会议室里的顺畅，到了任务现场才会露出裂缝。

这就是可用性测试存在的理由。它把"我们觉得用户会这样用"变成"用户实际这样用"。不是问用户"你觉得怎么样"，而是请他们完成真实任务，然后安静地看着。

1. 导读

可用性测试不是访谈。访谈听用户讲经验、动机和看法；可用性测试看用户带着任务操作产品。用户说"我觉得挺清楚"不够，你要观察他能不能真的完成任务。用户说"这个按钮应该能点"也不够，你要看他点了之后能不能理解反馈。

也别把可用性测试当成大型实验。很多时候，一次小规模、任务清楚、观察认真、问题记录扎实的测试，就足以发现关键问题。它真正要交付的不是一份漂亮报告，而是一组可行动的判断：哪个任务卡住了，卡住的原因像不像设计问题，后果会影响谁，下一轮应该先改入口、术语、反馈、流程还是业务规则。

可用性测试衔接着用户研究、交互设计、原型设计和视觉设计的工作。理解了用户、设计了流程、制作了原型、组织了界面之后，要回答的问题是：这些方案到底能不能被用户顺利使用？

2. 核心问题

可用性测试到底测试什么？它看的是特定用户在特定情境中能否把事情办成，不是给参与者出一张"数字产品智力题"。

可用性测试和访谈、问卷、启发式评估有什么区别？访谈听经验，问卷收集态度反馈，启发式评估由专家检查原则，可用性测试观察用户完成任务。四类方法各有用途，不能互相替代。

测试任务如何设计？任务要接近真实目标，不能把答案写进题目，不能用内部术语引导用户。如果你写"请点击右上角的'新建项目'按钮"，那就不是在测试设计——你在测试用户是否识字。

样本量怎么理解？小样本测试适合发现常见问题，定量基准和分群比较需要更严谨样本。不能把一次小样本测试写成总体比例。

主持测试、无主持测试、远程测试和现场测试怎么选？选择取决于问题复杂度、任务风险、样本分布、观察深度和预算。没有万能的方案。

测试结果如何分析？不仅要记录用户说了什么，更要记录任务成败、错误、停顿、绕路、求助、情绪和系统反馈。用户说"这个还行"的时候，他可能已经卡了四十秒。

测试发现如何转化为改进优先级？优先级应结合问题严重度、影响范围、业务风险、修复成本和证据强度。不是所有问题都要马上改，但高风险问题不能因为"不太好修"就被搁置。

3. 关键概念与定义

可用性

可用性，Usability，通常指用户在特定使用情境中，以有效性、效率和满意度达成目标的程度。ISO 9241-11 将可用性与目标、用户、任务、资源和使用情境联系起来。¹

这一定义提醒我们，可用性不是"界面看起来简单"，而是"特定用户在特定情境中能否完成特定目标"。

同一个系统，对熟练员工可能很好用，对新员工可能难用；在办公室大屏幕上可能好用，在移动端弱光环境下可能难用；正常流程可能好用，异常流程可能难用。

可用性测试

可用性测试，Usability Testing，是让目标用户或接近目标用户的人，在研究者观察下完成任务，以发现设计问题、改进机会和用户行为特征的方法。NN/g 的 Usability Testing 101 将可用性测试描述为研究者让参与者使用界面完成任务，并在过程中观察行为和听取反馈。³

这句话里有三个关键词：任务、观察、反馈。

没有任务，测试会变成随意评价；没有观察，测试会变成访谈；没有反馈，研究者可能只看到用户做错了，却不知道他为什么这样理解。

任务成功率

任务成功率是用户完成指定任务的比例。

比如 8 名员工尝试报销一次客户拜访的地铁和出租车费用，其中 5 人把单据提交到了正确审批人。这个任务的成功率可以记为 5/8。真正要提前说清的不是分数，而是"成功"边界：只点了提交按钮算不算？发票缺失但系统放行算不算？交通类型选成差旅补贴算不算？如果这些规则没有写在测试计划里，最后得到的数字只会制造新的争论。

完成时间

完成时间是用户从开始任务到完成任务所花的时间。

它可以反映效率和学习成本，但不能机械解释。在医疗、金融、法律等高风险任务里，速度有时反而是警报。用户在手术知情同意、基金风险确认或贷款合同确认页上一路秒点，未必说明流程顺畅，也可能说明风险信息没有真正进入他的判断。完成时间要结合错误率、任务质量和用户理解一起看。

错误率

错误率是用户在任务中发生错误的比例或错误次数。

错误可以是点错入口、漏填必填信息、误解状态、选择错误角色、提交错误材料、误以为完成。错误率的价值在于定位高风险环节，但错误定义必须一致。

严重度

严重度用于判断一个可用性问题有多重要。

一个标签用词不够自然，可能只是轻微问题；一个支付失败后没有解释钱是否扣除，可能是严重问题；一个权限配置界面让管理员容易给错权限，可能是高风险问题。严重度通常需要结合任务影响、发生频率、恢复难度和业务风险判断。

SUS 与任务后评分⁶

SUS，系统可用性量表，是 10 题标准化可用性感知量表，适合评估整体系统可用性感知。 SEQ，Single Ease Question，常用于任务后询问用户完成某个任务的难易感受。⁷

SUS 不适合评价单个按钮，SEQ 不应替代行为观察。量表能补充用户感受，但不能取代任务成败和错误记录。

4. 概念边界与相近概念区别

可用性测试看用户如何完成任务

访谈主要听用户讲。可用性测试主要看用户做。

如果你问用户："你觉得这个结账流程清楚吗？"他可能回答清楚。但当你让他买一件商品、使用优惠券、修改地址、处理支付失败时，他可能在配送费出现的一刻停住，或者在优惠券不可用时不知道为什么。

访谈能帮助理解背景和原因，可用性测试能暴露真实操作中的卡点。两者可以结合，但不能互相替代。

可用性测试不是问卷

问卷适合收集较多用户的态度、满意度或自报行为，但它很难告诉你用户实际在哪里点错。

比如很多用户在问卷里说"开通账号有点麻烦"，这能提示阻力存在，却很难告诉团队麻烦藏在哪里。是短信验证码总收不到，还是密码规则只在输错后才出现？是隐私授权文案太长，还是邮箱验证后没有回到产品？可用性测试的价值，就是把一句笼统抱怨拆成几个能被修复的失败点。

可用性测试不是焦点小组

焦点小组适合讨论态度、概念和偏好，不适合评估界面可用性。

在一群人讨论界面时，声音更大的人可能影响其他人；大家会说自己认为合理的观点，而不是展示真实使用行为。可用性问题往往发生在独自操作的几秒钟里，这不是小组讨论能替代的。

可用性测试不是启发式评估

启发式评估是专家根据原则检查界面，例如系统状态可见、用户控制、一致性、错误预防等。NN/g 的 10 条可用性启发式原则可用于专家评审。⁴

它的优势是快速、成本低、适合早期排查明显问题。但专家评审不能替代真实用户。专家可能发现原则性问题，却不一定知道目标用户在真实任务里会如何理解。

可用性测试不是 A/B 测试

A/B 测试观察不同版本在真实流量中的表现，适合比较转化、点击、留存等指标。可用性测试更适合发现为什么用户失败、误解或犹豫。

如果 A/B 测试发现版本 B 转化更高，你仍然可能不知道原因；如果可用性测试发现用户看不懂费用说明，你还需要上线后数据或实验验证改进效果。两者互补。

可用性测试不是市场代表性调查

一次 5-8 人的可用性测试不能告诉你"80% 用户都会失败"。它只能说明"在这次测试中，这些参与者在这些任务中出现了这些问题"。如果要估算总体比例、比较不同版本或建立基准，需要更严格的定量研究设计。

小样本测试的价值在于发现问题，不在于代表总体。

5. 方法、流程或框架

可用性测试可以按七个步骤执行。听起来多，但每个步骤都有原因。

定义目标

先说清楚这次测试要回答什么问题。

比如"新成员能否在 10 分钟内创建第一个项目并邀请同事""审批人能否在一张差旅单里发现超标住宿费"。也可以是"支付失败后用户是否知道订单保留多久、钱是否扣除""用户能否在帮助中心找到退货时限和运费规则"。目标越具体，任务越容易设计，结果越容易解释。

不要把目标写成"测试整体体验好不好"。这个目标太大，测试结束后很难行动。

确定测试对象

测试对象可以是真实产品、原型、纸面流程、服务脚本、后台系统或帮助内容。

原型测试适合上线前发现问题；真实产品测试适合发现上线后的使用障碍；竞品测试适合理解用户预期；服务测试适合观察跨触点问题。

设计任务

任务要接近真实使用目标，而不是内部功能清单。

不要写："请点击优惠券入口并选择一张优惠券。"这会把路径告诉用户。更好的任务是："你准备购买这件商品，想看看有没有可用优惠。请完成下单前的价格确认。"

任务要避免内部术语。用户不会说"配置访问控制策略"，他可能说"让新员工能进入销售系统，但不能看到财务数据"。

招募参与者

参与者应尽量接近目标用户。测试企业后台时，新员工、管理员、审批人、客服和主管可能是不同角色，不能混在一起。

样本数量取决于研究目标。定性可用性测试可以用较小样本发现常见问题；5 到 8 名参与者如果都在同一个报销字段、支付提示或权限概念上卡住，团队已经有理由优先修正。定量基准、分群比较和高风险产品则需要更多样本和更严谨设计。NN/g 关于可用性测试的资料区分了定性和定量测试，并提示定量测试常关注任务成功和完成时间等指标。⁵

执行测试

测试可以现场，也可以远程；可以主持，也可以无主持。

主持测试适合复杂任务、早期原型、高风险场景和需要追问原因的研究。无主持测试适合任务清楚、样本分散、需要较快收集行为记录的场景。远程测试节省时间和地域成本，但对设备、网络和任务说明要求更高。

主持人要尽量避免引导。用户卡住时，不能马上告诉他答案；用户问"我是不是该点这里"，主持人可以把问题还给任务："你现在会怎么判断？"或者"如果这是你自己要办的事，你下一步会怎么做？"这样既不泄露答案，也能继续观察用户的理解路径。

如果做反了会怎样

测试开始前，主持人说："这是我们刚设计的新版页面，你觉得怎么样？"用户笑着说"挺好的，看起来很清爽"。测试结束后，主持人在报告里写"用户对新版表示满意"。这不是可用性测试——这是满意度调查，它告诉你的不是"用户能不能完成关键任务"，而是"用户不想让你失望"。

真正的可用性测试不会让用户"评价"设计。它不告诉用户哪个是新功能，把任务写成"给你的新同事配置一下项目权限"，然后安静地观察：用户是否选对了角色？是否看懂了权限说明？是在哪个字段犹豫了三秒？为什么返回上一页两次？那些沉默、皱眉、反复横滚、口中小声念出标签名的瞬间，才是测试真正有价值的数据。

分析问题

分析时不要只摘用户原话。

一条好的发现应包含：谁，在什么任务中，遇到什么问题，表现是什么，可能原因是什么，影响是什么，证据来自哪里。

例如："5 名新员工中有 3 人在选择报销费用类型时选择错误。他们把'市内交通'和'差旅交通'混淆，原因可能是两个标签过于接近，且说明文字只在鼠标悬停时出现。该问题导致报销被退回风险，建议调整命名并在选择时展示示例。"

这比"用户觉得费用类型不清楚"更可执行。

推动改进

可用性测试的成果不是报告，而是改进。

测试结束后，要把问题按严重度和优先级整理，和产品、设计、研发、业务一起确认修复方式。某些问题可以立即改文案，某些问题涉及流程重构，某些问题需要补充研究或数据验证。

6. 实际工作场景

表单失败：用户不是不会填，而是不知道错在哪里

一个保险理赔表单看起来很完整：姓名、身份证、事故时间、事故地点、材料上传、银行账户。团队内部评审时觉得逻辑清楚。

可用性测试中，用户却在"事故类型"和"材料类型"之间反复切换。他不知道轻微剐蹭和第三方责任属于哪类，也不知道上传照片、发票和维修单的顺序。提交后系统提示"材料不完整"，但没有说缺什么。

这时测试发现的不是参与者粗心，而是一条体验链同时失灵：分类像内部审批语言，说明没有举例，错误提示只说"材料不完整"，材料反馈也没有告诉用户先补哪一项。

导航迷失：用户找不到，不代表内容不存在

一个 SaaS 产品有完整帮助中心，但新用户仍然频繁问客服"怎么邀请同事""怎么设置权限""怎么导出数据"。

测试时，研究者让用户完成"邀请一名同事加入项目并设置只读权限"。用户先去成员管理，找不到；再去项目设置，看到"访问控制"但不确定是不是权限；最后去帮助中心搜索"添加同事"，结果出来的是团队管理文章。

内容存在，但路径、命名和搜索都没有匹配用户语言。可用性测试能把"帮助中心不够好"拆成更具体的问题：入口、标签、搜索词、文章标题和任务路径。

流程中断：支付失败后的恢复比成功页更重要

电商结账流程最常测试成功路径，但用户真正焦虑的常常是失败路径。

如果支付失败后页面只显示"系统异常"，用户会担心钱是否扣了、订单是否还在、优惠是否失效、是否能重新支付。可用性测试可以让用户经历一次模拟失败，观察他是否知道下一步。

这个场景也能连接商业价值：支付失败恢复不清，可能造成放弃购买、客服咨询和投诉。但上线后的业务变化仍受价格、活动、支付渠道和库存影响，不能全部归因于一次测试。

企业后台：错误不是小问题，可能是运营风险

企业后台的可用性问题常常不显眼，却会造成返工和风险。

比如权限配置系统中，管理员需要为新员工选择角色。测试时，管理员把"区域销售经理"和"销售主管"混淆，系统没有展示权限预览，也没有提交前确认。结果新员工可能看到不该看的客户信息，或者无法访问必要模块。

这种问题不能只按"界面不清楚"处理。它涉及权限风险、培训成本、IT 支持和审计责任。可用性测试要把任务失败和业务后果连起来。

AI 和数据产品：用户看懂结果，不等于能正确使用结果

一个数据看板或 AI 助手，用户可能能读懂文字，却误解输出的适用范围。

比如 AI 客服建议"可以退款"，但它只是基于当前信息判断，仍需人工审核。用户可能把建议当成承诺。可用性测试可以观察用户是否理解系统能力、是否知道如何转人工、是否能识别不确定提示。

7. 案例

SUS：可用性测试后的整体感知度量

SUS（系统可用性量表）是可用性测试后常用的标准化度量工具。10 道题、5 点量表，测试结束后请参与者填写，可以得到一个 0-100 的 SUS 分数。

在可用性测试实践中，SUS 通常在任务完成后发放，与任务成功率、错误率、完成时间等行为指标互补——行为指标告诉团队"用户在哪里失败"，SUS 告诉团队"用户整体觉得有多难用"。SUS 适合在不同版本、不同迭代之间横向对比，帮助团队追踪可用性的长期变化趋势。

但 SUS 不适合评价单个按钮、单个页面或单次交互。它是一个整体感知工具，得分变化需要结合任务表现和产品语境一起解读。

专家评估与用户测试的互补

启发式评估和结构化评估方法（如 UX Scorecards，详见第 11 章）可以作为可用性测试的补充——它们快速、低成本，适合在用户测试前排查明显问题。但专家评审不能替代真实用户：专家可能发现原则性问题，却不一定知道目标用户在真实任务里会如何理解。实践中建议先用专家评估扫一遍，再用可用性测试验证关键任务路径。

SUS 来源资料：量表不是百分比

SUS 的经典来源和 UXPA/Usability Body of Knowledge 资料可帮助理解 SUS 的用途。 SUS 的价值在于低成本、标准化、适合长期追踪整体可用性感知。但它常被误读成百分比。一个系统 SUS 得分 70，不等于"70% 用户满意"，也不等于"70% 可用"。它是量表换算分数，需要结合语境解释。

8. 数据、指标或衡量方式

可用性测试最常用的指标包括任务成功率、完成时间、错误率、任务后主观评分、SUS、问题严重度和问题复现频次。

任务成功率回答"用户是否完成"。但成功标准必须提前定义。比如用户提交了报销单，却把"客户拜访交通费"选成"差旅补贴"。界面显示提交成功，业务后果却是财务退回；这种情况最多只能算部分成功，不能为了数字好看把它记成完成。

完成时间回答"完成得是否高效"。但高风险任务中，过快可能不是好事。

错误率回答"哪里容易错"。错误包括点错、漏填、误解、选择错误、重复操作、误以为完成。错误定义要统一。

SEQ 可以在任务后询问用户觉得任务难不难，SUS 可以在一组任务后观察整体可用性感知。它们适合补充用户感受，但不能替代行为证据。

严重度评估要综合四件事：问题是否阻止任务完成，是否频繁发生，用户是否能自行恢复，后果是否严重。

客户和管理者要特别注意：可用性测试数据不等于业务结果。测试中 5 人里有 3 人失败，不能直接写成"60% 用户会失败"。但它足以提示一个高风险问题，需要修复或进一步验证。

9. 常见误区

误区 1：可用性测试就是问用户意见。修正：让用户完成真实任务，再结合追问理解原因。

误区 2：测试用户越多越好。修正：先明确研究目标，再决定样本。

误区 3：只测试成功路径。修正：任务脚本必须覆盖关键失败路径。

误区 4：主持人帮用户完成任务。修正：主持人只解释测试流程，不解释界面答案。

误区 5：把用户失败归咎于用户。修正：把失败看成系统反馈，而不是用户能力问题。

误区 6：测试结束后只交报告。修正：把发现转化为改进项、负责人、优先级和复测计划。

误区 7：SUS 得分就是百分比。修正：结合任务表现、趋势和产品语境解释 SUS。

误区 8：启发式评估可以替代用户测试。修正：用专家评审快速排查，用用户测试验证真实任务。

10. 小结

可用性测试的核心，是让用户带着任务使用产品，然后观察他们是否能完成、在哪里出错、为什么卡住。

它不是访谈、问卷、焦点小组、启发式评估或 A/B 测试的同义词。它是一种评估研究方法，特别适合发现设计方案在真实任务中的可用性问题。

好的可用性测试不是为了证明设计对了，而是为了更早发现哪里还不对。

11. 延伸阅读

| 资料 | 推荐理由 | 适合读者 | |---|---|---| | ISO 9241-11:2018 | 理解可用性的有效性、效率、满意度和使用情境 | 设计师、研究员、管理者 | | NN/g Usability Testing 101 | 理解可用性测试的任务、参与者、主持人和测试类型 | 设计师、研究员、产品经理 | | Measuring the User Experience | 理解 UX 指标、测试度量和分析方法 | 用户研究员、数据分析师 | | SUS: A Quick and Dirty Usability Scale | 理解 SUS 来源和用途 | 研究员、体验管理团队 | | GitLab SUS / UX Scorecards | 理解复杂产品如何追踪和评估可用性 | SaaS 团队、设计负责人 | | Baymard Cart & Checkout Usability Research | 理解电商结账可用性研究和流程摩擦 | 电商产品团队 |²

注释

¹ ISO 9241-11:2018。可用性与有效性、效率、满意度和使用情境相关。 🔗 https://www.iso.org/standard/63500.html

² NN/g, Usability Testing 101。可用性测试通过任务、参与者和主持观察发现问题。 🔗 https://www.nngroup.com/articles/usability-testing-101/

³ NN/g, 10 Usability Heuristics。启发式评估可快速检查原则性问题，但不能替代用户测试。 🔗 https://www.nngroup.com/articles/ten-usability-heuristics/

⁴ John Brooke, SUS: A Quick and Dirty Usability Scale。SUS 可用于整体可用性感知追踪。 🔗 https://uxpajournal.org/sus-a-quick-and-dirty-usability-scale/

⁵ Baymard Cart & Checkout Usability Research。结账流程摩擦可通过可用性研究发现。 🔗 https://baymard.com/research

⁶ GitLab UX Scorecards。复杂产品可通过结构化评估机制发现体验问题。 🔗 https://handbook.gitlab.com/handbook/product/ux/ux-scorecards/

⁷ 本书指标库（13_metric_library.md）。可用性测试指标可包括任务成功、完成时间、错误率和量表。