尼尔森十大原则驱动的可用性测试实战指南

做了这么多年可用性测试我最大的一个感受就是很多人不是不会测而是不知道“测什么”和“按什么标准下结论”。功能测试可以对着需求文档一条条过性能测试有明确的指标阈值但可用性测试经常变成“我觉得这里不好用”——你说了对方还不一定服气。所以我一直习惯用尼尔森十大易用性原则来驱动整套测试流程。它不是一份简单的检查表而是一套能把模糊体验翻译成具体问题、再按严重程度排序的分析框架。这篇文章就从实际测试的角度聊聊我怎么做原则驱动的可用性测试适合产品经理、交互设计师、测试工程师以及对用户体验感兴趣的朋友参考。1. 为什么我用尼尔森十大原则来驱动测试1.1 一套原则怎么就成了测试标尺尼尔森十大易用性原则是行业内非常经典的一套启发式评估标准。系统状态可见性、系统与现实世界的匹配、用户控制和自由、一致性和标准、错误预防、识别而非回忆、灵活性和使用效率、美观和极简设计、帮助用户识别诊断并从错误中恢复、帮助和文档——这十条原则覆盖了绝大多数可用性问题的根源。一开始我也觉得这十句话太抽象但真正用起来才发现它给了你一个非常稳定的分析坐标系。当你判断一个页面“怪怪的”又说不清到底哪里不对的时候可以拿原则逐条过一遍是操作之后没有状态反馈是某个术语超出了用户的日常表达还是信息展示需要用户靠记忆来回切换大多数情况下很快就能定位到问题所在。我更看重它的另一个原因是它可以降低个人主观偏好的影响。做测试最怕的就是“我觉得”和“我喜欢”因为这种结论无法讨论也无法复现。有了原则做框架我可以理直气壮地说“这里违反的是第五原则‘错误预防’用户在提交前没有任何校验或二次确认所以产生了大量误操作。”这一句话设计同学能听懂开发同学也能接住。1.2 和单纯的功能测试、走查式检查有什么不一样可用性测试有很多种做法比如随便“自己点一圈看看”或者是严格的多用户A/B实验。用十大原则来驱动是我在实践中觉得投入产出比最高的一条中间路线。它不需要像A/B测试那样规划大样本、跑统计也不需要等产品上线在原型阶段就能做又不像自由探索式走查那样缺乏判断标准容易变成个人审美大会。原则驱动的测试有几个特征第一测试任务在设计时就围绕原则展开每个任务都带着要验证的对应原则第二观察时重点记录行为与原则的冲突点比如用户犹豫、误点、求助、放弃第三分析时把问题按原则归类和分级输出结构清晰的结论。这样哪怕是一个刚接触可用性测试的新人按这套流程走下来也能产出一份有价值、别人愿意看的报告。我带新人做测试时经常说一句话不要急着教用户怎么操作也不要急着评价用户“会不会用”你先记他“在哪里停顿、在哪里皱眉、在哪里绕回了”。这些行为信号才是后续做原则判断的核心依据。2. 十大原则翻译成测试观察点的方法2.1 原则到检查点的拆解模板学过十大原则的人很多但一到具体的测试现场就发懵不知道眼睛该往哪里看。我的做法是在准备阶段先做一张“原则—观察点”对照表。这张表不是为了逐条打勾而是为了提醒自己在这个任务里哪些行为信号值得记录。原则核心关注点观察点示例可以问用户的问题系统状态可见性用户是否知道系统发生了什么是否有加载、进度、成功、失败反馈你觉得现在系统在做什么系统与现实世界匹配系统语言是否贴近用户常识有没有黑话、英文缩写、难懂的图标这个按钮你觉得是干什么用的用户控制和自由能不能轻松撤销、退出、回退是否有取消、返回、关闭入口如果不想继续了你会怎么做一致性和标准同类操作是否统一相同含义的按钮位置、命名、样式是否一致这两个页面里同样的东西你觉得是同一个意思吗错误预防是否在错误发生前就阻止必填项校验、不可操作项置灰、二次确认如果输入错误会发生什么识别而非回忆用户是否不用记忆就能完成操作菜单是否展示可选项是否有自动填充你不需要记住上次选了什么吧灵活性和使用效率高频操作是否足够快是否有快捷键、默认值、批量操作如果每天都要用有没有更快的办法美观和极简设计信息是否不必要地复杂有没有冗余信息、装饰性元素、重复模块页面上哪些东西和你当前任务无关帮助用户识别诊断恢复出错后能否理解并解决错误提示是否写明原因和下一步操作刚才报错了你看明白怎么处理吗帮助和文档用户能否自助获得有效帮助帮助入口是否可达内容是否匹配场景如果卡住了你会去哪里找答案这张表我几乎每个项目都会重新做一次根据业务特性去调整观察点和追问话术。表格写得越细测试执行的时候就越省力笔记也不会写成一堆毫无章法的流水账。2.2 每一条原则对应的典型测试场景与话术光有表格还不够你还要知道每一条原则适合埋进什么样的任务里。我举一个做过的内部运营后台项目代号就叫模拟项目X。那是一个给运营人员处理客户信息的管理后台我前后安排了五六个典型任务每个任务背后都带着明确的原则验证目标。第一个任务是“新注册一个客户并录入他的第一笔订单”。这个任务重点观察错误预防、识别而非回忆、系统状态可见性。比如表单提交前有没有格式校验提交后有没有明确的成功反馈客户类型是做成下拉选择还是让用户凭记忆手工输入这些细节都能在用户实际操作中暴露出来。第二个任务是“修改一位客户的合同截止日期然后撤销这次修改”。主要看用户控制和自由、一致性和标准。用户能不能轻松找到修改入口修改之后有没有取消或恢复的操作路径返回按钮是回到列表首页还是回到上一个操作页这种不起眼的小事恰恰是测试中最容易发现的体验断裂点。第三个任务是“从Excel导入一批客户数据并处理中间的异常行”。重点观察错误恢复、帮助和文档、系统状态可见性。导入失败时提示信息有没有具体到某一行、某一列能不能下载失败清单帮助中心里能不能搜到对应的技术说明如果用户导入到一半卡住旁边没有人他到底能不能自救第四个任务是“在首页找到最近处理过的3个客户”。重点看识别而非回忆、美观和极简设计。首页会不会自动展示最近处理记录还是用户必须记住客户名再去搜索框里输入首页有没有被大量无关的报表或推广信息干扰每个任务里要重点盯的观察点不要超过五六个否则眼睛根本看不过来。我自己的经验是一次测试安排4到6个任务最合适太少覆盖不了基本原则太多用户会产生疲劳测试时长也容易失控。3. 实操过程从测试脚本到结论产出3.1 准备阶段任务设计与用户招募准备阶段的第一步是把十大原则列成一张“覆盖矩阵”。横轴是十条原则纵轴是测试任务交叉点标注“覆盖”或“重点观察”。我的习惯是整体上保证十条原则至少都被覆盖一次越是核心的流程越要安排两到三条任务反复验证。另外再根据业务风险额外补一两个高操作成本的任务比如支付、审批、批量删除这类场景。在用户招募上5到7个用户就能暴露绝大部分可用性问题。这个数字很多人觉得太少但相关研究已经反复证明过大部分关键问题在第五个用户出现后就基本稳定了。我一般招募5到6名真实目标用户不会找同事“帮忙看看”因为同事太熟悉业务和使用习惯根本测不出真实用户的认知过程。实在找不到目标用户时我宁可找没接触过产品的新手也比内部人测出的结果有意义。测试开始前我要给用户讲清楚“大声思考法”。也就是请用户把信息化成语言说出来一边做一边讲脑子里在想什么。这一步一定要现场演示一遍否则用户很容易陷入沉默。我会做个示范“你看我把鼠标移到这个按钮上我猜点了它会跳到下一步但我又担心会不会直接提交。”先让用户理解怎么做后面执行才会顺利。测试脚本也要写得非常具体但不是一个字一个字地指挥用户。每个任务我都给出一段场景描述而不是直接说“点击新增客户按钮”。比如我会说“你刚拿到一个新客户的信息领导让你把这个客户录入系统并记录第一笔订单。”这样测的才是用户在真实场景里的行为路径而不是在测用户听不听得懂你的指令。3.2 执行阶段观察、记录与追问观察和记录是整个测试的核心。我一般坐在用户侧后方能同时看到屏幕和用户的手部操作但不会和用户正脸对上这样可以减少压迫感。记录用的是一张提前打好的观察表按任务分区域每行留白。现场我尽量不做判断只记事实在哪个环节停顿了多久、点了哪里、说了什么话、有没有皱眉、有没有回退、有没有换了好几种操作方式。我有几个固定追问句式都是很多次测试里打磨出来的看到用户皱眉或长时间停顿“你现在在想什么你是在找什么吗”看到用户误点“你刚才想点的是哪一个为什么点到这个”看到用户反复尝试“你已经试了两次了你期望接下来发生什么”任务结束但结果不理想“如果刚才没有做成功你接下来会怎么解决这个问题”这里最重要的原则是不要引导用户。尤其不要说“你是不是应该点那里”这句话一出口测试的真实性就毁了。我宁愿少追问几次也不要把用户带偏否则记录下来的所有行为都不算数。条件允许的时候我会用录屏软件把操作过程录下来再用手机全程录音。事后分析时重看一段关键时刻的录屏比翻笔记要直观得多。需要注意录屏一定要提前征得用户同意并且明确告知数据用途。我在某个项目里遇到过对数据比较敏感的用户那就只记录笔记质量其实也足够。3.3 评估阶段问题定级与原则归类测试结束后把笔记整理成一份问题清单。每个问题先用一句话写清楚现象比如“用户点击‘保存’后以为合同已经生效但实际上只是保存了草稿后续没有走审批流程”。仅仅有现象还不够还要完成两件事映射原则、评估严重度。映射原则就是判断这个现象违反的是哪一条或哪几条原则。上面这个例子表面上是一个文案歧义问题但实际上跨了“系统与现实世界匹配”和“一致性和标准”。用户在真实业务里“保存”和“提交审批”是两种不同动作而界面表达几乎一样自然容易踩坑。严重度我习惯分四级严重直接阻断任务用户完全无法继续较重用户能完成但花费了大量时间或频繁出错一般用户被困惑和干扰但最终还算能搞定轻微用户有一些不适但从行为上观察不到明显影响。定级标准一定要写进报告开头不然别人会不理解你为什么把某个问题定成“严重”。全部定级完成后再把问题按对应原则做一次汇总就能看到哪几条原则被突破得最多。这个汇总结果往往直接指出了产品体验风险最集中的模块比单独列100条问题更值得关注。4. 常见问题与排查技巧实录4.1 我在测试里频繁撞见的几类问题做了这么多次测试后我发现很多问题是跨项目反复出现的。把它们提前列出来后面再做测试时你就能更快地辨认它们。第一类是“用户总找不到保存按钮”。这通常和系统状态可见性、一致性和标准有关。排查方法也很简单就是等用户完整走一次保存流程记录从准备保存到看到结果之间花了多长时间、试错了几次。如果用户连点两三下都没有找到那按钮的位置或视觉权重一定出了问题。第二类是“错误提示像天书”。报错信息写什么都行就是不给用户出路。比如直接弹一个“系统内部错误”用户只能干瞪眼。这典型对应的是帮助用户识别、诊断并从错误中恢复这条原则。我的经验是错误提示最好说清楚三件事哪里错了、为什么错、下一步怎么办。第三类是“用户以为整段文字都能点结果点不进去”。这往往不是用户的问题而是系统里可点击元素和纯文本的视觉区分度太弱。排查时可以直接问用户“你看这个像不像是可以点击的”如果十个里有六七个都说“像”那就要考虑把按钮、链接、普通文本的样式彻底拉开。第四类是“表单提交后没有反馈用户以为没成功连续点了好几次”。这是系统状态可见性的典型反面案例。我的早年项目里也踩过这个坑后来每次上线前都要专门检查一遍凡是有提交动作的按钮提交过程中必须有loading成功或失败必须有明确反馈。第五类是“用户要在几个页面之间来回切换才能完成一件事”。比如录订单的时候需要同时看得见客户历史合同但系统只让你在一个页面里做事必须跳出去查完再跳回来。这通常对应识别而非回忆核心问题是信息没有出现在它该出现的地方。4.2 新手最容易犯的5个错误新手做原则驱动测试十有八九会栽在下面这几个错误上。第一个错误是把所有原则一次性塞进所有任务。结果每个任务都蜻蜓点水什么都没测透。正确做法是每个任务只设一两个主测原则其他原则顺带看不要贪多。第二个错误是用户一卡住就忍不住上手帮忙。用户刚停顿两秒新手立刻说“你点这里就行”测试当场失效。你的角色是观察者不是引路人。如果用户明确求助你可以记录下来但不要给出操作指引继续观察他接下来会怎么办。第三个错误是只记录主观感受不记录行为证据。“用户觉得页面很乱”这种话信息量太低。要记的是“用户在选择日期时花了48秒先翻日历又去找预设筛选最后自己手动输入”。行为是客观的感受必须用行为来佐证。第四个错误是严重度评估全靠感觉。我见过有同事把每个问题都标成“严重”结果开发看了第一页就怀疑整份报告的可信度。定级之前先冷静一下这个问题是不是真的阻断任务了如果不阻断它值不值得放到下一次迭代第五个错误是报告里只写问题不写建议。可用性测试的目标是提升产品而不是给产品判刑。哪怕建议很简单也一定要给出方向比如“把保存按钮的文案改成‘保存草稿’并且明显区别于‘提交审批’”。这种话开发拿过去就能直接改。4.3 关于排查的两个小技巧除了单条问题我还会在每次测试结束后花十五分钟看共性。如果某一条原则被反复突破那往往说明系统在结构层面出了问题而不是某一个页面的小bug。比如“一致性和标准”失守很多时候是因为不同功能模块由不同团队设计样式规范和交互习惯没有统一。这时候再去逐个按钮修补已经来不及更值得做的是推进全局设计规范。另外一个小经验是给开发提交问题清单之前自己先试着画一版修正后的线框图。不需要多精细只要能表达“改成什么样”就行。有图有建议比干巴巴写一句“请增强反馈”有用得多。我靠这一招避免了很多次“报告很好看但开发看完就放着不动”的局面。5. 测试报告怎么写才不会被开发打回来5.1 结构化报告的字段设计一份好的可用性测试报告不需要长篇大论但证据链要完整。我常用的报告结构是先写测试基本信息包括时间、版本、环境、参与人数、任务清单再写总体结论比如本次测试发现严重问题3个集中出现在哪些原则领域然后按严重度列出问题清单最后补一张原则热力汇总让读者一眼看出问题扎堆的地方。问题清单的字段可以这样设计编号问题现象用户行为证据违反原则严重度修改建议1用户重复提交订单用户等待4秒后再次点击提交按钮同一订单被提交3次系统状态可见性严重提交后立即显示进度状态提交期间禁用按钮成功后展示成功页2用户找不到“另存为草稿”用户依次检查顶部菜单、侧边栏、右键菜单耗时约25秒一致性和标准较重在表单底部增加固定显示的“保存草稿”按钮位置与其他模块保持一致3导入失败原因不明确用户看到“部分数据异常”后直接放弃没有尝试下载错误清单帮助用户识别诊断恢复较重弹窗中直接展示异常行摘要同时提供“下载完整错误列表”按钮5.2 修改建议到底该怎么给最容易让开发反感的建议是“让体验更好”“更有设计感”这种话没有任何信息量。要给就给到具体的位置、状态和交互方式。比如“提交按钮在点击后变为禁用并显示‘提交中…’超过2秒则显示进度动画。”开发拿到这种描述可以直接评估工作量、安排迭代双方都省时间。当然有一些建议需要投入比较大的成本比如推进全局设计规范、重构底层页面跳转逻辑。这种情况下我会把它单独放进“长期优化建议”明确说明优先级和预期收益而不是和其他小问题混在一起。否则团队很容易被一批零散问题淹没真正该做的大改进反而没人看见。报告写完以后我还会约一个十几分钟的结果同步会不用讲完整PPT只需要把严重问题逐条过一遍每一句都用用户行为的原话来佐证。我试过多次这种方法要比往群里丢一份文档管用太多——面对面讲开发才能真正理解用户在那一秒遭遇了什么。最后聊一点我自己的体会。尼尔森十大易用性原则这十个名词在网上随便一搜就能找到真正值钱的从来不是背住这十句话而是怎么把它们变成测试设计、观察记录和问题分析的工具。我早期也走过弯路把原则当成死板清单对着页面一项项打勾测出来的东西特别浅。后来改成围绕任务走流程再用原则做归因框架报告一下子就有了分量。如果你也准备在团队里推这套做法我的建议是先拿一个不太关键的模块试水完整地跑上两三轮把观察表、脚本模板、报告结构都调顺了再扩大到核心业务。可用性测试的价值不在于一次性发现多少个问题而在于建立起一套持续反馈、持续优化的机制。这套机制转起来以后“不好用”这三个字终于能变成大家都能讨论、都能动手改的具体问题了。