原型工具与可用性测试法 (NN/g)

阶段: B16 · 治理一页纸 + AI 原型 + 可用性（Day 151-160） 标签: #usability #think-aloud #prototyping #nng

今日导引（由浅入深）

B16 的前半段（Day 151-155）把治理收敛成一页纸、把评测拆成独立 κ harness——解决的是「系统对不对、可不可信」。从今天起 B16 转向「人用着顺不顺」：再准的 κ、再独立的评测，如果调查员看不懂面板、找不到 κ 是否达标，价值就漏在最后一公里。在 B1→B18 能力曲线上，这是第一次把「可用性工程」正式纳入——从纯后端正确性（B1-B15）走向人机交互可验证性（B16）。今天的最小可判定产出：一份可点击原型链接 + 3 个 think-aloud 任务脚本，原型如实标注「教学模拟/部分需 key 跑真值」。

1. 机理精读

think-aloud（出声思考）是可用性工程里性价比最高的方法。 它要求被试在操作界面时连续说出自己的心理活动——「我现在想找 κ，应该在哪……这个数字是 0.6 吗？达标了吗？」——主持人只记录、不引导。核心命题来自 Nielsen Norman Group 的经典发现：5 名真实用户即可暴露约 85% 的可用性问题。这条「5 用户法则」背后是泊松过程模型：单个用户发现某问题的独立概率 L≈0.31 时，1−(1−L)^5 ≈ 0.85。它不是说 5 人就够做统计，而是说 5 人足以把「结构性高危坑」抖出来。

为什么是「出声」而不是「事后问卷」。 人在完成任务后回忆，会自动合理化、抹平当时的困惑（post-hoc rationalization）。出声协议捕捉的是「正在挣扎」的实时信号——犹豫、走错路、读错标签——这些恰恰是设计缺陷的指纹。问卷只能问出「满意度 7/10」这种无法定位的钝感数据。

为什么先定任务、再做原型。 可用性测的是「用户能否完成某个具体任务」，不是「界面好不好看」。所以方法第一步永远是确定测什么任务。对本项目的 harness 面板，要测的任务直接对应它的两个真实数字载体：(1) κ 是否达标——能不能从面板读出 judge-human 一致性的数字并判断好坏；(2) 哪个模型更好——能不能从任务套件结果里读出 V4-Pro vs V4-Flash 并说出理由。任务定义错了，后面录再多屏也白搭。

关键权衡：保真度 vs 速度。 用 v0 / Figma Make 这类 AI 原型工具能在小时级生成「真交互」原型（可点击、有状态），代价是数据是假的。这正是诚实标注的用武之地：原型必须明写「数据为教学模拟，真值需 key 跑」，否则被试会把假数字当真，think-aloud 反馈跟着失真。保真度要够高到能测交互流，但绝不能假装数据是真的。

并发 vs 追溯式出声的取舍。 think-aloud 有两种变体。并发式（concurrent）让被试边做边说，捕捉实时困惑，但说话本身会轻微拖慢任务、扰动计时——所以并发式不适合精确测「完成时间」。追溯式（retrospective）让被试先安静完成、再看回放复述，计时干净但依赖回忆、会丢实时信号。本项目要找的是「面板哪里读不懂」的定性坑，并发式更合适——我们不追求精确计时，要的是实时的「这数字是什么意思」的犹豫。

与相邻概念的边界。 think-aloud ≠ A/B 测试（B17 的主题）：前者是小样本定性、找问题；后者是大样本定量、证差异。今天属于前者。也 ≠ 启发式评估（专家走查）：那不需要真人被试，由专家对照 10 条启发式原则扫界面。也 ≠ 满意度问卷（SUS / NPS）：那是事后主观打分，定位不到具体缺陷。今天严格指真实人类被试的并发式出声操作。

为什么这一步对 AISA 作品集是「最后一公里」。 B1-B15 把后端正确性做到了可量化（V4-Flash 79.3% / V4-Pro 89.7%、独立 κ harness）。但 hiring manager 的四问里有一问是「数据流怎么呈现给人看」——一个 hiring manager 或审计若打开面板读不出 κ 是否达标、说不清哪个模型更好，那再硬的后端数字也无法被「有效挑战」（呼应 Day 154 治理一页纸）。think-aloud 正是把「面板可被有效挑战」这条软属性变成可判定任务成功率的工具。

为什么 think-aloud 适合本项目而非传统 A/B。 本项目用户基数极小（AML 调查员、合规审计是垂直专业群体），凑不出大样本 A/B 所需的流量；而且面板的核心问题是「读不读得懂专业数字」，这种问题大样本点击流也测不出来——它需要听被试解释「我以为这个 79.3% 是 κ」。小样本定性的 think-aloud 在这种「高专业度、低流量」场景里，信息密度远高于 A/B。

资源主线：NN/g "Thinking Aloud / 5-user usability testing"（2024-09 复核版仍是行业基线）。

2. 推导 / 手算 / 代码走读

「5 用户发现 85% 问题」的手算（理解为什么是 5，而不是 3 或 20）：

设单个用户发现任意给定可用性问题的平均独立概率为 L。NN/g 经验值 L≈0.31。则 n 个用户至少有一人发现该问题的概率：

• P(n) = 1 − (1−L)^n

逐步代入 L=0.31（1−L = 0.69）：

边际收益递减很明显：从 5 到 10 多花一倍人力只多抓 ~13 个百分点（85%→98%），从 10 到 15 更只多 ~2pp。所以 NN/g 主张「5 人一轮、改完再测下一轮」而非「一次招 15 人」——多轮迭代的总信息量远高于单轮大样本。这也正是 B16 后半段的安排逻辑：

• Day 158：首批 3 人（覆盖率 ~67%，抖出结构性高危坑）
• Day 159：补到累计 5 人（覆盖率 ~85%，聚 top-3 痛点）
• Day 160：只改 top-1 后复测（受控迭代，量 Δ）

一个常被忽略的前提：L≈0.31 是「对随机界面的平均经验值」。若界面问题特别集中、人人必撞（L→1），3 人就够；若问题极分散、各人撞各的（L→0.1），5 人覆盖率会掉到 ~41%，得多轮补。所以「5 人」是经验中位数，不是教条——遇到反馈高度分散时要加轮次。

任务脚本的结构（3 个待测任务的骨架，今天产出）。好的任务脚本有三个特征：(a) 给目标不给路径（说「找出 κ」而不是「点左上角第二个标签」，否则等于喂答案）；(b) 有客观成功判据（能据此打成功/求助/错误三标签）；(c) 贴近真实工作场景（不是「点遍每个按钮」这种无意义遍历）。三个任务：

1. 「请找出当前 judge 与人工金标的一致性 κ，并告诉我它是否达标。」— 测 κ 数字的可发现性 + 可判读性。成功判据：被试读出 κ 数字 + 正确说出与阈值的关系。
2. 「请判断 V4-Pro 和 V4-Flash 哪个模型在任务套件上更好，并说出你的依据。」— 测 79.3% vs 89.7% 这组对比数字能否被正确解读。成功判据：被试指向 V4-Pro（89.7% > 79.3%）并给出基于面板数字的理由。
3. 「假设你要把这个结果给审计看，你会从面板里截哪一屏？为什么？」— 测面板的「可被有效挑战」属性（呼应 Day 154 治理一页纸）。成功判据：被试选出含 κ + 模型对比 + 数据来源标注的那一屏。

一次 think-aloud session 的标准流程（主持人脚本，约 30-45 分钟/人）：

1. 暖场（2 分钟）：说明「我们测的是界面不是你，没有对错；请大声说出你在想什么」。
2. 练习题（1 分钟）：用一个无关小任务让被试习惯出声（如「请说出你看到的第一个数字」）。
3. 正式任务（每任务 ~5 分钟）：依次给上面 3 个任务，沉默时只提示「请继续说」。
4. 不干预原则：被试走错路也不纠正，记录他怎么自己绕回来（或绕不回来）。
5. 复盘（5 分钟）：任务全做完后再问开放问题，不在任务中途打断。

每个任务还要预埋「失败信号」清单，方便编码时打标签：任务 1 的典型失败是「把 V4-Flash 的 79.3% 误当成 κ」（数字混淆）；任务 2 的典型失败是「只看通过率不看是哪个模型」；任务 3 的典型失败是「截了没有数据来源标注的那屏」——后者直接暴露「教学模拟」标签做得不够显眼。

诚实标注在原型上的具体落法（这套笔记的诚信底线，逐位标）：

• κ 数字卡：底色置灰 + 角标「待跑(需 key + ≥50 手标金标)」，不填任何假 κ。
• 模型对比区：可填真值 V4-Flash 79.3% / V4-Pro 89.7%，但角标「judge=pass 单评，非独立 κ」。
• 全局水印：原型页脚常驻「教学模拟 / 部分数据需 key 跑真值」。
• 任何「报送 / 提交」类按钮：标「演示，不触达真实系统」。

这样标的目的不是免责声明，而是保证 think-aloud 信号不被假数据污染——被试若把假 κ 当真 κ 去判断「达标」，整条任务 1 的反馈就废了。

3. 今日实战

1. 用 v0 或 Figma Make 把 harness 面板生成真交互原型 v1：至少包含 (a) judge-human κ 数字卡 + 达标阈值标注，(b) V4-Pro / V4-Flash 任务套件结果对比区。
2. 在原型每个数据位旁加诚实标签：κ 数字标「待跑(需 key + ≥50 手标金标)」；任务套件结果可填真实底层数字 V4-Flash 79.3% vs V4-Pro 89.7%，但标注「judge=pass 单评，非独立 κ」。
3. 把 3 个 think-aloud 任务脚本写成单独文件（每个任务一句话指令 + 预期成功判据），供 Day 158 直接拿去跑。
4. 原型链接与任务脚本登记入 docs/AML_GOVERNANCE_MAP.md 的可用性测试章节占位，待 Day 158-160 回填结果。
5. 为每个任务预写「成功判据 + 典型失败信号」，供 Day 158 编码时照搬（避免临场拍脑袋定标准）。

4. 今日实测 / 产出

• 可点击原型链接 + 3 任务脚本 — 待 UI 工具产出（外部动作 / UI-tooling-gated）。
• 原型须如实标注数据为「教学模拟 / 部分需 key 跑真值」。
• 可填入原型的底层真实数字：V4-Flash 79.3% vs V4-Pro 89.7%（judge=pass 单评口径，非独立 κ）。
• κ 数字位状态：待跑(需 key + ≥50 手标金标)，不得在原型上伪造一个 κ 数。

5. 常见误区 / 陷阱

• 用合成「假用户」替代真人 think-aloud。 「5 人」指的是真实人类被试；让 LLM 扮演用户走查会得到一个被训练分布扭曲的伪反馈，抓不到真实困惑点。
• 原型数据不标注、让被试误以为是真值。 假 κ 当真 κ，会让被试的「达标判断」全部失真，污染整轮测试。
• 先做漂亮 UI 再补任务。 任务定义必须先于原型——否则你测的是审美而非可用性。
• 一次招太多人。 边际收益递减；5 人一轮 + 多轮迭代远优于单轮大样本。
• 任务脚本里写出操作路径。 「点左上角找 κ」等于喂答案，测不出可发现性；只给目标不给路径。
• 用并发出声却又精确测完成时间。 说话会拖慢任务、扰动计时；要精确计时得用追溯式或纯计时观察，不能两头要。
• 被试走错路时主持人忍不住纠正。 纠正一次就抹掉了「他能不能自己绕回来」这个关键信号——不干预是铁律。
• 测「界面好看不好看」而非「任务能不能完成」。 可用性测的是任务完成度；审美评价请走别的评估方法，别混进 think-aloud。

6. 学习资源（每条带 YYYY-MM）

• NN/g, "Thinking Aloud: The #1 Usability Tool"（2024-09 复核版）— 出声协议主线。
• NN/g, "Why You Only Need to Test with 5 Users"（原文 2000，2024-09 复核仍有效）— 5 人法则与 1−(1−L)^n 推导。
• NN/g, "Task Scenarios for Usability Testing"（2024 复核版）— 任务脚本「给目标不给路径」原则。
• NN/g, "Concurrent vs. Retrospective Think-Aloud"（2024 复核版）— 并发 vs 追溯式取舍。
• v0 by Vercel 官方文档（2026 当周版本）— AI 快速原型工具。
• Figma Make 官方文档（2026 当周版本）— 设计稿转可交互原型。

SOTA检查 (2026-06 更新)

• 当前主流：NN/g think-aloud 5 人法（2024-09）仍是可用性发现的行业基线方法，current；v0 / Figma Make 为当前主流的「分钟级可交互原型」工具。
• 是否仍 SOTA：是。可用性工程的核心方法学十余年稳定，AI 工具只改变了原型生成速度，不改变「真人出声 + 小样本多轮」的方法内核。
• 过时黑名单：
  • AVOID 用合成「假用户」/ LLM 扮演被试替代真人 think-aloud——5 人指真实人类。
  • AVOID 用事后满意度问卷（SUS/NPS）冒充可用性测试——问卷定位不到具体缺陷。
  • AVOID 在原型上摆假数字而不标注——会污染 think-aloud 信号。
  • AVOID 把 think-aloud 与 A/B 混为一谈——前者小样本定性找问题，后者大样本定量证差异（B17）。
• 下次复查点：B17（Day 161+）把这里发现的痛点喂给 outcome 指标仪表盘前，复查 v0/Figma Make 当周版本是否仍支持所需交互保真度；2026-08-02 EU AI Act Art.50 生效后复查原型是否需补 AI 生成内容披露。

衔接

• 昨天：Day 155 — 评测独立性（Anthropic Demystifying evals 2026-01），把自评闭环拆成被测 + 独立 κ 评审。
• 今天：用真人 think-aloud 5 人法 + AI 原型工具，把「面板能不能被人读懂」变成可判定的任务成功率问题。
• 明天：Day 157 — AML 面板信息架构，把同一套方法用到 AML Copilot 的四段任务流原型上。