这一批笔记其实是两件相关但不同的事，别混：
(1) 十大可用性启发式 Usability Heuristics —— Jakob Nielsen 1994 年提出的 10 条"设计经验法则"。它们是专家用来给界面做体检的清单(启发式评估 Heuristic Evaluation)，也是设计阶段的自检表。注意"启发式(heuristic)"= 粗略好用的经验规则，不是精确公式，所以它告诉你"该往哪看"，但不替你做决定。
(2) 可用性测试 Usability Testing —— 找真实用户来用你的产品、在旁边看他们卡在哪。启发式评估靠专家眼睛，可用性测试靠真实用户行为，两者互补：先用启发式自检挑出明显问题(便宜)，再用用户测试抓你想不到的问题(准)。
全文八块：启发式为什么是地基(愉悦层级) → 10 条启发式完整表 → 复杂企业应用怎么落地 → 测多少人(5 人法则) → 怎么招人 → 远程怎么测 → 任务怎么设计(任务场景+分步任务) → 数据怎么读(态度vs行为·4 步分析·别信小样本的数字·竞争性评估)。
一、为什么可用性是"地基"：用户愉悦的四层金字塔
很多人以为"愉悦的体验(Delightful UX)"= 动画、萌吉祥物、幽默文案。NNGroup 借 Aarron Walter《Designing for Emotion》的用户需求层次(类比马斯洛需求金字塔)说清：愉悦是塔尖，下面三层不稳，塔尖就是空中楼阁。
| 层级(自下而上) | 含义 | 缺了会怎样 |
|---|---|---|
| 功能性 Functionality | 产品得真有用、能完成基本需求 | 没用处，其他全白搭 |
| 可靠性 Reliability | 功能要按预期稳定运行，不崩 | 再好看也留不住人 |
| 可用性 Usability | 易学易用、高效完成任务 | 愉悦的先决条件——这一层就是本篇主角 |
| 愉悦性 Pleasurability | 美学、情感、惊喜 | 只有前三层达标，用户才会注意并欣赏它 |
表面愉悦 vs 深层愉悦：
- 表面愉悦 Surface Delight：局部、短暂——动画、触觉反馈、幽默微文案(Groupon)、高清图、声音交互。锦上添花，但产品本身有问题时反而显得轻浮。
- 深层愉悦 Deep Delight：整体、持久——四层需求全满足时，用户进入"心流(flow)"，界面退成无缝的辅助工具。靠的是优化工作流、消灭痛点(Yelp、Unroll.me 是正例)。
心法：愉悦不是"加糖"，是"去痛"。Why：负面偏差效应(Negativity Bias)——人记住糟糕体验远比记住愉悦体验牢，所以功能/可靠/可用是"必须不出错"的，愉悦才是"可以加分"的。反例：The Clove Club(华丽 HTML5 动画但信息密度低、链接藏起来、加载慢)、Ithaca Bakery(排版混乱)、Magic of Baltimore(导航过载、为创意牺牲可用性)——在可用性不足时强加表面愉悦，适得其反，甚至损害品牌。
二、十大可用性启发式完整表(The 10 Usability Heuristics)
下面是核心参考表。用法：设计阶段当自检清单；评审阶段做"启发式评估"(几位专家各自对照这 10 条找问题，再汇总)。注意：这 10 条会互相牵扯——比如"错误预防(#5)"和"帮助从错误恢复(#9)"是一前一后；"撤销"功能同时服务 #3、#5、#9。
| # | 启发式(EN / 中) | 一句话心法 | Do(该做) | Don't(别做) | 反例 |
|---|---|---|---|---|---|
| 1 | Visibility of System Status 系统状态可见性 | 系统要在合理时间内用反馈告诉用户"我在干什么"，给用户信任感和控制感 | 点击后即时变色/进度条；持续状态(电量、Wi-Fi、电梯到几楼)常驻可见 | 别把内部活动全抖给用户(如"正在扫描服务器日志")——无用信息=噪声 | 点提交后毫无反馈，用户不知道点没点上、要不要再点一次 |
| 2 | Match Between the System and the Real World 系统与真实世界的一致性 | 用用户的语言和现实惯例，按符合逻辑的顺序呈现信息 | "Staff Directory(员工目录)"而非"Meet-and-Greet"；拟物化(Kindle 翻页/书签)借用现实心智模型 | 别用内部黑话、营销术语、设计师自嗨的时髦词 | 内网联系人区叫"Meet-and-Greet"，用户猜不出是不是日历邀请 |
| 3 | User Control and Freedom 用户控制与自由 | 用户常误操作进入不想要的状态，要给清晰的"紧急出口"(撤销/重做/退出) | 浏览器前进后退；分步流程顶部"返回上一步"；表单"取消"按钮——明确标注 | 别把退出藏在隐秘手势里(如"摇一摇撤销"，多数人不知道) | 注册流程不给取消，强制走完才能退出 |
| 4 | Consistency and Standards 一致性与标准 | 同样的词/图标/动作应有同样含义，让界面可预测、易学 | 内部一致(橙色只用于可点击元素)+ 外部一致(购物车放右上角，跟全网一样) | 别让一种视觉信号有两种含义(橙色又标可点又标静态标题) | DevOps 软件里"+"号既表"加新任务"又表"展开详情"，用户混乱 |
| 5 | Error Prevention 错误预防 | 用户出错往往是设计没防住，不是用户笨。优先防"高风险错误" | 关键按钮用不同颜色/大小/位置区隔；高风险操作加确认对话框；提供撤销 | 别只忙着减小挫折而忽略致命错误的优先级 | "回复全部"和"回复"挨太近、长得一样，误点群发 |
| 6 | Recognition Rather than Recall 识别优于回忆 | 识别(认出来)比回忆(凭空想起来)轻松——多给上下文线索 | 下拉菜单列出选项；图标(垃圾桶=删)；自动补全；相关功能分组 | 别逼用户背命令/路径/语法(老式命令行的痛) | 命令行删除线要记住命令名和语法，学习曲线陡 |
| 7 | Flexibility and Efficiency of Use 灵活性与效率 | 给多条路径完成同一任务，并为专家用户提供"加速器(accelerators)" | 复制三条路(菜单/右键/Ctrl+C)；快捷键、宏、双击点赞；加速器藏起来不打扰新手 | 别只服务新手而锁死专家，也别把加速器塞到新手面前吓人 | 高频用户被迫每次走菜单，没有快捷键，效率撞天花板 |
| 8 | Aesthetic and Minimalist Design 美学与简约设计 | 界面只放与任务相关的信息——提高"信噪比(Signal-to-Noise Ratio)" | 内容/功能按重要性排序；视觉元素要传信息不只装饰；逐步显示高级选项 | 别堆装饰背景图、无意义动画、冗余标签——每个噪声都削弱信号 | 给任务列表每一项都加同一个图标，占空间又干扰 |
| 9 | Help Users Recognize, Diagnose, and Recover from Errors 帮助用户识别、诊断、恢复错误 | 出错时说清"哪错了、为什么、怎么修"，最好把修复入口嵌在错误旁 | 红字+图标标出错字段(Nordstrom)；用大白话说原因(Lowes 404)；嵌可点的修复入口(Kayak 直接列可移除的筛选条件)；Gmail"撤销发送" | 别用技术黑话；别只说"出错了请联系管理员"却不给出路 | ERP 报"无法显示数据，请联系系统管理员"，用户卡死 |
| 10 | Help and Documentation 帮助与文档 | 理想是不用看文档，但复杂界面难免要——文档要可搜、贴任务、给具体步骤 | 无字符限制的搜索框、问句式结果(LeTote)；上下文敏感帮助(Skyscanner 在字段旁弹提示)；编号步骤+截图(Asana) | 别做 30 字符上限+只显标题的搜索(Wayfair)；别写一堆背景知识 | Wayfair 帮助搜索限 30 字符、结果只给标题，得逐个点开 |
#5(错误预防)和 #9(错误恢复)的关系：能防的尽量防(#5 是上策)，防不住时让恢复变容易(#9 是兜底)。两条配合，才是完整的错误处理策略。
三、把 10 条启发式用到复杂企业应用(Complex Applications)
启发式自 1994 年沿用至今，对企业级软件、数据分析工具、高价值决策系统一样适用，但落地手法要升级。下面是 NNGroup 对每条的"复杂应用版"要点(正反例多来自真实企业软件)。
| # 启发式 | 复杂应用里的关键升级 | 正例 | 反例 |
|---|---|---|---|
| 1 可见性 | 长任务单个转圈不够，要列已完成/待完成步骤+剩余时间(超 10 秒尤其要) | ArcMap 详细进度指示器分步显示 | —— |
| 2 真实世界一致 | 符号要符合文化惯例 | —— | 呼叫中心软件用"咖啡杯"图标表示客服"可接听"，与"咖啡=休息"惯例冲突 |
| 3 控制与自由 | 高认知投入的任务更需要快速纠错 | Jitterbit Cloud Studio 项目历史时间线，可回滚到早期版本 | —— |
| 4 一致性 | 同一符号别一物两用 | Power BI 所有工作区统一用"+"表示新增 | DevOps 软件"+"既加任务又展开详情 |
| 5 错误预防 | 学习期最易出错，支持探索式操作 | Salesforce 搭仪表板时实时预览组件效果 | —— |
| 6 识别优于回忆 | 数据/选项海量，靠悬停提示减记忆 | Revit 悬停部件编号即显 3D 图示+名称 | —— |
| 7 灵活效率 | 高频用户靠快捷打破效率瓶颈 | Solidworks 鼠标手势快捷可自定义 | —— |
| 8 简约 | 信息过载是企业软件通病，用动态显示 | Mastercard Test & Learn 选中字段后才显示高级设置 | 项目管理软件给每项任务加同一图标 |
| 9 错误恢复 | 错误信息嵌文档链接 | Jitterbit 错误信息含详细文档链接 | ERP"无法显示数据，请联系管理员" |
| 10 帮助文档 | 用户不会提前读文档，要嵌入式上下文帮助 | Revit 工具栏悬停显示描述+快捷键+演示视频 | —— |
心法：复杂应用的可用性，本质是"在信息更密、流程更长、出错代价更高"的条件下，把 10 条原则做得更狠——进度要更细、撤销要更强、提示要更贴、噪声要更少。
四、测多少用户？5 人法则与它的例外
黄金法则：在定性可用性测试里，5 个用户就能发现约 85% 的可用性问题，成本收益比最优。更多用户带来的新问题发现迅速递减。这条对网站、内网、PC 应用、移动应用普遍适用。
为什么是 5 个而不是更多：成本随人数线性上升(招募+测试时间)，但收益在 5 人后趋平。有余钱就做多轮小测试，而不是把一轮做大——迭代设计才是高质量+高 ROI 的来路(早期修问题的成本仅为项目末期的百分之一)。
四个常见误解(都站不住)：
| 误解 | 真相 |
|---|---|
| 网站用户多，样本就该大 | 统计方差只跟样本量有关，与总体规模无关 |
| 功能多，要测更多人 | 把大网站拆成多个小测试，每次只测一部分功能 |
| 目标群体不同要更多人 | 是要更多，但每组目标用户仍只需 3–5 人 |
| 高价值项目要一次消灭所有问题 | 高预算应支持多轮迭代，而非一次大测试 |
例外情况(这些场景必须放大样本)：
| 场景 | 目标 | 建议人数 |
|---|---|---|
| 定量研究 Quantitative | 拿统计显著性结果 | ≥ 20 人(置信要求严时更多) |
| 卡片分类 Card Sorting | 设计/验证信息架构 | 每组 ≥ 15 人 |
| 眼动追踪 Eye-tracking | 生成稳定热图 | 39 人 |
| 小型敏捷项目 | 极低成本快速迭代 | 2–3 人/轮，多轮累积 |
| 多目标群体(如医生+患者) | 覆盖完全不同的用户组 | 每组 3–5 人 |
实证：一项汇总 83 项用户测试的研究发现，测试人数与发现问题数的相关性很小——之所以有人用更多人，主要是客户要内部说服力、要覆盖多目标群体、或高预算咨询项目倾向加人，不是因为多人真能多发现问题。
五、怎么招到合适的人(Recruiting Participants)
招人是可用性测试里最耗时、最难的一环。平均每位参与者成本约 $171(随地区和职业大幅波动)。
用户测试三大铁律(招募只是为了满足第一条)：① 找有代表性的用户；② 让他们做有代表性的任务；③ 观察并倾听，尽量少引导。
关键数据(201 位从业者调查)：
| 维度 | 数据 |
|---|---|
| 地理分布 | 美国 54% / 英国 8% / 加拿大 7% / 澳大利亚 5% / 其余含巴西中国印度新加坡 |
| 外部机构使用 | 36% 公司用机构，仅 9% 完全依赖；机构费均 $107/人(美西最高 $125) |
| 机构费高端 vs 普通 | 高端专业人士 $161 vs 普通消费者 $84(近 2 倍) |
| 内部招募时间成本 | 平均 1.15 小时/人，24% 公司超 2 小时/人 |
| 激励(外部测试) | 63% 给现金、41% 给非现金；均 $64/小时(美西 $81)；高端 $118 vs 普通 $32(近 4 倍) |
| 激励(内部员工) | 仅 10% 给现金，35% 给非现金(免费午餐、书券) |
| 缺席率 No-Show | 平均 11%(约 1/9) |
心法：招人慢是公司做不起测试的头号原因。对策：① 初次测试可雇专业机构省心，逐步把流程内化；② 给慷慨激励压低缺席率；③ 多招几个当替补应对 no-show；④ 建标准化筛选标准(screener)+ 记录流程，让以后越招越快。
六、远程有主持测试 7 步(Remote Moderated Testing)
远程有主持(moderated = 有研究员实时引导)比线下更便宜、更快、对参与者更方便，但前期工具准备更重。
| 步骤 | 要点 |
|---|---|
| 1 选沟通工具 | Zoom / GoToMeeting / Join.me / Skype / Lookback.io；查跨系统兼容(Lookback 不支持所有 iOS/Android 版本)；能静音观察者、能私聊(Slack)给主持人传话 |
| 2 定任务呈现方式 | 推荐：聊天窗逐条发任务 + 让参与者朗读——确保读完、防提前看后续、促使出声思考 |
| 3 安排技术练习 | 正式测前给每人 15 分钟练习装软件、测屏幕共享/音频/网络；没时间就在正式测时预留缓冲 |
| 4 发提醒邮件 | 给参与者(时间/充电/耳机/强网络)和观察者(提前 5 分钟登录、保持静音、注意哪些问题) |
| 5 邀团队进会 | 观察者可提前进(不打扰但浪费时间)或参与者设置好后再进 |
| 6 与参与者开场 | 欢迎→确认名字发音→告知有观察者并征得录制许可→口头确认同意书→把屏幕控制权交给参与者 |
| 7 结束会话 | 致谢+说明奖励领取→停止保存录制→与观察者复盘主要发现和任务改进；重复 5–7 直到测完 |
附加技巧：口头同意替代书面签字；主持人自己也用耳机+强网络；留缓冲应对软件更新/防火墙；先做试点测试(pilot)优化流程和任务。
七、任务怎么设计：任务场景三技巧 + 分步任务
测试结果好不好，一半看任务设计。核心：把"用户目标"包装成真实的任务场景(Task Scenario)，给情境和理由，但别暗示该点哪里。
先问自己：用户用这产品最重要的几件事是什么？(如：找某主题文章、报名研讨会、了解咨询服务。) 再把目标写成场景。
任务场景三技巧：
| 技巧 | 差的任务 | 更好的任务 | 为什么 |
|---|---|---|---|
| 1 让任务真实 | 买一双橙色 Nike 跑鞋 | 买一双 < $40 的跑鞋 | 让用户按自己标准比较，而非机械执行 |
| 2 让任务可操作 | 想看电影，告诉我你会点哪 | 用 fandango.com 找周日下午想看的电影 | 实际操作才暴露真问题，口述反映不了真实困难 |
| 3 避免提示/不描述操作步骤 | 登录后告诉我点哪查成绩单 | 查找你的期中考试成绩 | 任务里出现界面术语(如菜单标签)就测不出标签是否好懂 |
避免提示的延伸——别用界面里的词当线索：差"注册公司周报" → 好"找一种方式定期接收活动信息"。但也别太模糊：差"预约看牙医" → 好"为下周二上午 10 点预约牙医 Dr. Petersen"(用户能"悬置怀疑"假装与陌生名字的牙医预约)。
分步任务(Stepped Tasks)——同时研究"可发现性 Discoverability + 可查找性 Findability"的进阶设计：从最宽泛的任务起步，若用户没碰到研究目标区域，再用后续子任务逐步给微小提示。
- 编号方式：子任务用 4A/4B 或 4.1/4.2；编号不给用户看(免干扰节奏)。
- 示例(研究内网日历功能的可发现性)：
| 任务编号 | 任务描述(逐步收窄) | 这一步能学到什么 |
|---|---|---|
| 任务 4 | 同事请你空出 1/12 下午 2–3 点开会，你会怎么确保不忘？ | 用户自主发现并用了日历功能 = 最佳 |
| 任务 4A | 你能找到另一种方式记住这个会吗？ | 提示后才找到 = 功能需改进(不是首选) |
| 任务 4B | 内网里有个安排会议的工具，能用它记住吗？ | 知道功能存在仍找不到 = 可发现性有问题 |
| 任务 4C | (引导到日历页)用这个工具记住这个会 | 引导到页面仍不会用 = 交互/导航/易用性都有严重问题 |
心法：任务越具体，研究"可发现性/可查找性"的机会越少——所以先宽后窄，宽任务看自然行为，窄任务保底拿到目标信息。为什么要预先写任务而不是临场编：临场编容易引导性过强、不清晰、无效；书面任务强化"观察而非对话"的节奏(研究员发任务→用户读并做→研究员看着少说话→做完再问)，提高效率和一致性。
八、数据怎么读：态度 vs 行为、4 步分析、别信小样本的数字、竞争性评估
8.1 态度数据 vs 行为数据(Attitudinal vs Behavioral)——分清"用户说什么"和"用户做什么"：
| 类别 | 态度数据 Attitudinal | 行为数据 Behavioral |
|---|---|---|
| 来源 | 用户自我报告(说不出来观察不到的) | 用户实际操作(可直接观察) |
| 回答 | 用户为什么这么想？ | 用户具体做了什么？ |
| 方法 | 问卷、访谈、焦点小组 | 可用性测试、产品分析、日记研究 |
| 典型数据 | "我喜欢这个功能" | 点击路径、停留时间、犹豫 |
结合的力量：观察到用户点"完成"前犹豫几秒(行为) + 访谈发现他对按钮标签困惑(态度) = 既知道有阻碍、又知道为什么。定性可用性测试 + "边做边说(Think-Aloud)"法正是同时捕捉两者的常用手段。
8.2 定性测试数据分析 4 步法——教科书把分析说得很简单(记问题、统计错误)，实际很难，尤其当测试方法特殊(测多版本)、研究问题复杂(能否找到+是否理解+如何解决)、原型不完整时。要做两件事：分析(Analysis，把数据拆开看)+ 综合(Synthesis，把碎片重组找洞察)，两者来回切换。
| 步骤 | 做什么 | 比喻/要点 |
|---|---|---|
| 1 收集相关数据 Collect | 从记录/笔记/视频里挑出对研究问题有用的观察和原话 | 像在果园里挑好苹果 |
| 2 检查准确性 Assess | 判断每条信息多可靠(用户说喜欢但从没用过？只是答了引导性问题？) | 不是所有信息一样重要 |
| 3 理解数据 Explain | 把现象 + 专业知识结合解释行为(同一现象常有多种解释) | 没人用比较功能，可能位置不对/不够显眼/根本不需要 |
| 4 验证拟合 Check for Good Fit | 用数据反验你的解释，有矛盾就重想 | "用户不需要比较"但数据显示他比较得很费劲 → 解释错了 |
心法：步骤 3、4 要反复推敲，不是一次走完——先凭印象出初步想法，再用更多数据验证、发现矛盾、调整，循环多次。
8.3 别信小样本里的"数字"(Why You Cannot Trust Numbers)——定性测试天生小样本 + 协议可变，所以它产出的任务成功率、完成时间、满意度评分这些数字不可靠(大测量误差)，只适合找问题、不适合当指标。
- 真值理论：
观测值 = 真值 + 测量误差。真值=总体真实行为；观测值=你小样本测出来的。误差小→观测值能预测真值；误差大→不能。 - 样本量直接决定误差：
| 样本量 | 观测成功率 | 95% 置信区间 | 误差 |
|---|---|---|---|
| 10 人 | 50%(5/10) | 24%–76% | ±26% |
| 100 人 | 50% | 40%–60% | ±10% |
- 两个统计工具：置信区间(Confidence Interval)——观测值可能覆盖真值的范围，样本越大越窄；统计显著性(Statistical Significance)——两个数差异是真的还是噪声，看 p 值(p<0.05 才算显著)。
- 协议可变性加剧误差：定性测试为了快速发现问题，允许研究员临场干预/调整任务，导致各用户测试条件不一致、噪声增大；定量测试协议固定、干预少、噪声小。
- 别报裸数字，要带范围和局限：
| 错误陈述 | 应改成 |
|---|---|
| "70% 用户完成了任务" | "10 人中 7 人完成；据此估计总体成功率 39%–90%(95% 置信区间)" |
| "新设计评分优于旧设计(6.2 vs 5.1)" | "新设计评分更高，但差异未达统计显著(p>0.05)，不确定能推广到总体" |
| "满意度均值 6.7(1–7 分)" | "均值 6.7；预计总体均值 5.2–7(95% 置信区间)" |
8.4 竞争性可用性评估(Competitive Usability Evaluations)——拿你的产品和竞品对比，看什么有效、什么无效。
- 范围：整体评估(按整体可用性排名)或聚焦评估(比某个功能/流程，如结账)。
- 两种方法：专家评审 Competitive Review(可用性专家凭经验评，找相对优劣/趋势/模式)+ 竞争性用户测试 Competitive Testing(让用户在多个设计上做代表性任务，随机化测试顺序避免偏见，会后问用户比较各设计)；还可对同一产品的多套设计方案(纸原型/初稿)做比较，帮团队选方向。
- 怎么选竞品：聚焦 2–4 个——提供类似功能的、可用性出色的、目标用户最常拿来比较的；可扩展纳入小型创新公司、甚至只部分相关的行业找独特视角。
- 目标不是评出"赢家"，是改进自己：识别优势 → 发现共性趋势(有益还是有害) → 突出竞品的创意解法 → 找差异化机会 → 发现功能/信息缺口。评估指标：成功率、完成时间、用户主观评分、定制评分表。把发现转成设计决策，而不是简单照抄竞品——更要理解竞品失败的原因以免重蹈覆辙。
源自 NNGroup Topics / Usability Heuristic 可用性测试(22 篇)。用户研究方法与定性/定量边界见 NNGroup 定性研究与研究方法工具箱(方法全景/访谈/共情图/样本量/任务设计/主持/专家评估/工作坊/伦理) / NNGroup 定量研究 Quantitative Research(A/B 测试·样本量·置信区间·UX 指标·转化分析·基准测试·学习曲线) / NNGroup UX 研究方法选型(23 法速查/四象限定位/按问题-阶段-预算选/定性探索·定量验证·专家评估·IA·行为分析五大族);与 Will 的 Google UX 证书课测试与迭代笔记 Google UX 证书 / 测试·迭代·设计评审·交付 互为补充。图片与原文档(含 ArcMap/Power BI 等复杂应用截图、Yelp/Clove Club 视频)保留在 sources。