设计评审与可用性度量

设计评审与可用性度量

设计好不好，不能靠"我觉得"。设计的价值靠证据说话：专家评审、可用性测试、量化指标与实验，是设计决策的四种证据来源。本文是通用方法论深讲，面向有经验的产品经理、设计师与候选人；AI 产品的设计评审检查表与「对话式 UI 的可用性测试要点」见产品设计与原型总览，AI 输出质量的评测见 AI 输出质量评测——两页与本页互补，合起来才是完整的"怎么证明设计行不行"。

为什么评估

设计是假设，需要证据

任何设计方案都隐含一组假设："用户能看懂这个入口""这样写用户更信任""缩短一步能提高转化"。这些假设在没有证据之前都是猜测。评估要做的事就是把每个关键假设变成可检验的问题，再用最便宜的方法回答它：

评估的成本应当与决策的风险匹配：风险越高、越难回头的决策，越要花力气评估。改一个按钮颜色不值得跑完整可用性测试，但"是否上线自动执行能力"值得。

形成性评估 vs 总结性评估

两者不是二选一：形成性评估告诉你往哪改，总结性评估告诉你改完有没有效。成熟团队通常是"小步迭代 + 形成性测试"为主，到里程碑再用总结性评估验收。

评估方法谱系总览

谱系的逻辑：从专家到实验，成本递增、证据强度递增。专业做法不是一律上最贵的，而是先问"这个决策的证据缺口有多大"，再选最便宜且够用的方法。四种方法也可以串成一条证据链：专家评审发现问题 → 可用性测试确认问题真实存在 → 量化指标度量严重程度 → A/B 测试验证修复方案有效。

专家评估方法

专家方法的核心是不打扰用户、靠专业判断找问题。速度快、成本低，适合在开发早期反复跑，但它发现的是"疑似问题"，必须与用户验证配合。

启发式评估（heuristic evaluation）

由 Jakob Nielsen 与 Rolf Molich 于 1990 年提出：请评估者对照一组可用性原则（启发式）逐屏检查界面，记录违反原则的地方。1994 年 Nielsen 定稿的十条启发式是行业事实标准：

评估流程

1. 选评估者：3~5 名。不是越多越好——Nielsen 的研究显示，第 5 名之后的评估者发现的新问题急剧减少；1 名评估者的覆盖率通常只有 30% 左右，5 名约可覆盖 75%~85%
2. 独立评估：评估者各自对照十条启发式逐屏检查，互不讨论（讨论会互相污染、收敛到同几个人人都看得到的问题，丢掉各自的独特发现）；每发现一个问题记录：位置、违反哪条启发式、场景、建议
3. 严重度分级：每个问题独立打 0~4 分（见下表）
4. 汇总评审：评估者碰头合并问题清单、去重、统一严重度，产出带优先级的修复清单

严重度分级（Nielsen 0~4 制，综合"出现频率 × 影响程度 × 是否一次学会"判断）：

局限

• 专家 ≠ 用户：专家发现的是"可能的问题"，是否真实存在、影响多大，必须由用户测试确认
• 发现 ≠ 验证：启发式评估回答"违反原则了吗"，回答不了"用户真的失败了吗""改完有效吗"
• 依赖评估者水平：资深可用性工程师的发现数量与质量远高于新手，跨专业评估（如让工程师评）漏检率高
• 对 AI 产品不完全适用：十条启发式诞生于 GUI 时代，对对话式界面、生成式输出的新问题（如幻觉、不确定性表达、过长输出）覆盖不足，需要配合本文「AI 产品评估的特别议题」一节补充

认知走查（cognitive walkthrough）

认知走查不检查"界面是否漂亮"，而是从新手的视角模拟完成任务的心智过程。做法：选定一个代表性任务，把它分解成一系列动作序列，然后对每一步追问四个问题：

任一步答"否"，就记一个走查问题并说明卡在哪一步、为什么。走查者以"原型界面 + 用户画像 + 任务定义"为输入，一个人半天就能走完一个核心任务，比启发式评估更适合：

• 首次使用类场景：新用户引导、注册流程、第一次对话
• 无教学的自助界面：用户没有说明书、没有客服可问
• 与启发式评估搭配：启发式擅长找"违反原则"，走查擅长找"新手具体在哪一步卡住"，两者发现的重复率低

局限：走查者是"假装用户"，对用户知识背景的假设可能不准；它假设用户按理性目标行动，对探索式、情绪化行为解释力弱。

设计评审（design critique）与设计走查（design review）

这两件事经常被混为一谈，其实目标不同：

给反馈的结构：描述 → 影响 → 建议

评审里最有杀伤力的反馈是"我不喜欢""感觉不对"——没有信息量，还让人防御。专业的反馈格式是三步：

1. 描述：只说你看到的事实，不带评判。"这个按钮用了灰色，和旁边的主按钮区分度低"
2. 影响：说这个事实对用户的影响。"用户可能注意不到这是可点击的，错过主路径"
3. 建议：给一个具体的改进方向。"建议提高对比度，或改用主色描边"

配套纪律：反馈针对设计，不针对设计师；一次聚焦一个点，不攒一堆再倒出来；不确定对方意图时先提问（"这个入口的目标用户是谁？"），而不是先下结论。

评审会节奏

• 会前：设计者提前 24 小时发出材料与本次要回答的问题清单，与会者先看材料；评审会不是读稿会
• 会上：设计者 5 分钟讲背景与目标 → 按问题清单逐项过 → 每项 3~5 分钟给反馈 → 记录员当场记下决策与待办
• 会后：24 小时内发出决策记录；下次评审先过上次的待办
• 规模：5~8 人为上限，人多了每个人都说得少、责任分散

决策记录（ADR 思想）

评审最大的浪费是"同一个问题被讨论两次"：上周否决的方案这周又提上来，因为没人记得为什么否决。解决方法是给设计决策写记录，借鉴架构决策记录（ADR）的格式：背景 → 决策 → 理由 → 备选方案（及为何不选） → owner 与日期。不要求长篇，几行即可：

背景：对话式问答的"重新生成"放底部（2026-08-01） 决策：放输入框右侧，不放回答尾部 理由：用户反馈"回答太长时翻到尾部才看到按钮"；热区分析显示底部点击率低 备选：回答尾部（已试，2026-07 版）——用户需滚动，放弃 owner：@design-xx

有了决策记录，"为什么这么设计"就不用靠记忆，改动时也能先翻旧账，避免反复横跳。这也是总览「每次设计走查都留决策记录」的落地方式。

可用性测试（usability testing）

目标与时机

可用性测试是让真实用户在受控条件下完成任务，观察其行为与困难。它同时产出两类证据：定性（卡点、困惑、用户原话）与轻量定量（任务完成率、时间、错误）。适合在以下时机做：

• 新功能交互定型前后（验证核心任务流）
• 重大改版前后（对比新旧方案的完成率）
• 发布后抽查（验证真实使用与假设一致）
• 争议决策时（"用户到底能不能找到？"——测一下，别吵）

形式对比

组合建议：早期用「现场 + 主持 + 任务式」，挖深度；成熟期用「远程 + 非主持」，跑批量。任务式与自由探索可以混用——先让用户自由玩 3 分钟，再进入任务环节。

出声思维（think-aloud）

出声思维是可用性测试的默认要求：请用户边做边说，把脑子里想的讲出来。原理（Ericsson & Simon 的 Protocol Analysis）：出声让研究者获得认知过程的第一手数据，而不是事后的回忆重构——事后访谈里用户会"合理化"自己的行为（"我当时知道要这么点"），出声数据里则能听到真实的犹豫与猜测。

引导技巧：

• 开场说明："我们测的是产品不是您，您觉得哪里奇怪，正是我们想知道的东西"
• 别打断：用户安静操作时忍住不插话；一插话就污染了行为数据
• 统一追问语：用户卡住或操作奇怪时，问"你现在在想什么？"或"你现在想做什么？"，而不是"你为什么不点那个按钮？"
• 用户说"这里应该点 X"但犹豫时，让他继续："你可以照你想的点"

注意出声思维的边界：出声会轻微降低任务速度（双重任务效应），所以计时数据与出声测试混用时解释要谨慎；用户不说话时可用"接下来你想做什么？"温和推动，不要替用户解释。

样本量：5 个用户为什么够（以及什么时候不够）

Nielsen 与 Landauer（1993）给出了可用性测试问题发现率的数学模型：设某设计共有 N 个可用性问题、单个用户发现任一问题的平均概率为 λ（实测典型值约 0.31），则 n 名用户能发现的问题数约为：

1

已发现问题数 ≈ N × (1 - (1 - λ)^n)

代入 λ = 0.31 可得：1 人约发现 31%，3 人约 67%，5 人约 85%，10 人约 97%。直觉解释：用户越用越熟练、发现的重复问题越多，每人带来的"新问题"越来越少——收益递减曲线在 5 人之后变得很平，性价比大幅下降。

实操法则：核心任务用 5~8 人做 2~3 轮（每轮修完问题再来一轮），比一次性找 20 人更有信息量；定量基准测试另算样本量。这也与用户研究的访谈样本量建议一致。

任务设计

• 具体目标，而非"随便看看"：❌"请随便逛一下这个页面"；✅"请把文档分享给同事并设置只读权限"
• 场景化：给任务一个故事与动机，让用户进入角色："你刚入职，HR 发来一个文档链接，你需要确认自己能不能编辑"
• 避免引导性措辞：❌"点击右上角的分享按钮"（把答案告诉用户了）；✅"请把这份文档分享出去"
• 从真实场景来：任务来自埋点里最高频的路径与客服投诉，而不是设计师想象的路径
• 数量：一场测试 60~90 分钟，任务 5~8 个为宜；每个任务前念任务卡，完成后问一个"刚才哪里让你卡住了？"

被试招募与筛选

• 代表性比数量重要：被试应来自目标用户群体（年龄、岗位、产品熟练度、设备），而不是办公室同事与朋友——"内部人测试"发现的问题严重偏少
• 筛分问卷：用 3~5 个问题筛掉不合格者（如要求"过去一年用过同类产品""从未在本公司工作"）
• 新手 vs 老手：首次使用的用户测"学得会吗"，高频老手测"用得顺吗"——不同阶段的问题不同，先明确这次测谁
• 伦理与合规：告知录音、签知情同意、报酬照付、数据匿名；AI 产品测试注意不要让被试误以为在跟真人聊天（见「实验伦理」）

数据采集与分析

采集（测试中）：

• 录屏 + 语音：屏幕与表情都要录；AI 产品建议同时录"输入了什么、模型返回了什么"的时间线
• 行为指标：任务是否完成、完成时间、错误次数、求助次数、路径偏离
• 主观表达：出声数据、卡点时的原话、测试后问卷（SUS/SEQ，见下节）

分析（测试后）：

1. 按任务逐人回放，标注关键事件（卡点、错误、成功路径）
2. 汇总成问题清单：每条含证据（用户原话/录像时间点）、严重度（借用 0~4 分级）、出现人数
3. 去重合并：同一根因的问题合并（"找不到分享按钮"与"以为分享在设置里"可能是同一个 IA 问题）
4. 排序输出：按严重度 × 出现人数排序，附修改建议，交付开发

测试脚本与主持技巧

• 脚本三件套：开场白（目的、保密、可随时退出）→ 任务卡（逐任务）→ 收尾访谈（总体感受、最困惑处、SUS 问卷）
• 不教：用户卡住时，先等 10 秒；仍卡住就问"你现在想做什么"，不要上手演示——一演示，这个任务的数据就废了
• 不评判：用户操作"奇怪"时不说"很多人都会用"，不纠正、不解释、不引导
• 观察：重点记录"行为 + 原话"，克制自己的解释冲动；把解释留到分析阶段

量化度量指标

定性测试告诉你"哪里有问题"，量化指标告诉你"问题多大、是否在变好"。两套结合，才构成完整证据。

行为指标

• 基准（baseline）：上线前先测当前版本数据，作为后续对比的锚点；没有基线，"新版本更好"就没有参照
• 目标设定：指标要配目标（如"成功率 ≥ 90%"），目标来自业务目标反推或行业参考，而不是拍脑袋；同时警惕把指标当 KPI 后产生的「指标游戏」（见「常见误区」）
• 采集方式：基准测试（受控条件下人工采集）适合上线前；埋点（生产环境自动采集）适合上线后；两者口径必须一致才能对比

满意度问卷

SUS（System Usability Scale，Brooke 1996）

SUS 是行业最常用的整体可用性问卷：10 题、5 点李克特（1=非常不同意，5=非常同意），奇数题正向、偶数题反向，交替排列防止用户惯性作答。典型题项（偶数题已反向表述）：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10

1. 我愿意经常使用这个产品
2. 我觉得这个产品没必要这么复杂
3. 我认为这个产品用起来很简单
4. 我觉得需要有经验的人帮助才能使用这个产品
5. 我觉得这个产品的各项功能整合得很好
6. 我觉得这个产品功能太多、不一致
7. 我觉得大部分人都能很快学会使用
8. 我觉得这个产品用起来很麻烦
9. 使用中我感觉很自信
10. 使用前我需要学习很多东西

计分公式：奇数题得分 = 该题分值 − 1；偶数题得分 = 5 − 该题分值；10 题得分求和后再 × 2.5，得到 0~100 的 SUS 总分。

1

SUS = (Σ奇数题(分值−1) + Σ偶数题(5−分值)) × 2.5

解读：SUS 分数不是百分比，是 0~100 的综合分。行业基准（Jeff Sauro 汇总的大量研究）：

使用要点：SUS 测的是整体感知，不是诊断工具——分数低要知道"哪里低"，必须配合任务级数据；样本建议 ≥ 12 人再报告均值（小样本方差大）。

SEQ 与 UMUX

• SEQ（Single Ease Question）：任务结束后问一题"这个任务对你来说难度如何？"，1（非常难）~7（非常容易）。任务级指标，和 SUS（整体级）互补；在可用性测试里逐任务采集，能定位"哪个任务最难"
• UMUX（Usability Metric for User Experience）：4 题的轻量版 SUS（2 题可用性 + 2 题体验），7 点量表，与 SUS 高度相关；当问卷篇幅受限、或需要反复追踪时用

NASA-TLX

NASA-TLX 测任务负荷：脑力需求、体力需求、时间压力、绩效、努力、受挫感 6 个维度，加权合成 0~100 分。适用场景：操作员/客服工作台、长流程任务、高压力场景——"任务完成了，但累得要死"时，成功率和 SUS 都看不出问题，TLX 能。日常消费级产品的表单、浏览场景用它偏重，SEQ 就够。

CSAT / NPS 的适用边界

• CSAT（客户满意度）：单题"你对本次体验满意吗"，1~5 分；适合交易后即时测量，反馈快
• NPS（净推荐值）："你有多大可能向朋友推荐？"0~10，减去贬损者占比；衡量忠诚与口碑，样本要大、低频收集

边界提醒：两者都是态度指标，不是行为指标——用户说满意不等于用得好（可用性测试里经常有"完成了但很生气"的反例）；NPS 在样本 < 100 时噪声极大，不宜拿来做设计决策；它们回答"用户喜不喜欢"，回答不了"哪里不好用、怎么改"。设计团队可以把 NPS 当北极星的组成部分，但不能拿它当设计迭代的输入。

产品级度量框架：HEART vs PULSE

Kerry Rodden 等（Google，2010）提出 HEART 框架，专门解决"产品指标与用户体验脱节"的问题：

每个维度按"目标（Goal）→ 信号（Signal）→ 指标（Metric）"展开：先写目标（如"新用户快速学会提问"），再列可观察的信号（如"首个问题在 30 秒内发出"），最后才是可统计的指标。先有目标和信号，才有指标——直接抄指标列表是常见错误。

对比：PULSE（Page views 页面浏览、Uptime 可用性、Latency 延迟、Seven-day active users 7 日活跃、Earnings 收入）是业务/技术指标，问题在于：它们滞后（页面浏览下跌时已经发生了）、受设计与体验之外的因素驱动（投放、价格）、不能指导设计决策（"页面浏览量降了"然后呢？）。HEART 的价值是把用户体验本身变成可追踪的产品指标。实际运营中两者并用：PULSE 管业务健康，HEART 管体验健康。

北极星指标与设计度量

北极星指标是"产品核心价值是否达成"的唯一关键指标（如网盘产品的"每周活跃文件数"）。设计度量与它的关系：北极星回答"业务方向对不对"，设计度量回答"体验层面哪块拖了后腿"——北极星下跌时，靠 HEART 类框架分解定位是参与度问题、任务成功问题还是留存问题，再下钻到具体流程的行为指标。设计团队应维护一张"北极星 → HEART 维度 → 行为指标"的指标树（见「设计度量体系的搭建」），保证每个设计改动都能回答"它服务哪个上层指标"。

情绪曲线

对长流程（如开通企业账号、AI 生成长报告），可以按阶段自报情绪：让用户在流程的每个关键节点后打分（1~7 分），连成曲线。用处：定位情绪低谷——流程总时长相同，但情绪低谷在"上传资料"还是"最后确认"，改进方向完全不同。注意自报数据有记忆偏差，阶段间隔短一些、尽量当场采集。

实验方法：A/B 测试

问卷与埋点只能证明"相关"，A/B 测试是获得因果证据的黄金标准：把用户随机分到两个版本，只有改动不同，观察指标差异。

设计一个干净的实验

样本量估算公式（两组比例型指标对比，α = 0.05、功效 80%）近似：

1

每组所需样本 ≈ 16 × p(1−p) / (p1 − p2)²

其中 p 为对照组基准转化率，p1 − p2 为想检测的最小提升。例：基准 10%，想检测 10%→11%（提升 1 个百分点）的变化，需要每组约 16 × 0.1 × 0.9 / 0.01² = 14400 人——想检测的差异越小，需要的样本越大。检测"提升 20%"（10%→12%）则只需约 3600 人/组。开跑前先算这笔账，能避免"跑了两周没结论"。

常见陷阱

• 多重比较：同时看 10 个指标，纯随机也会有 40% 概率出现至少一个"显著"（0.95¹⁰ ≈ 0.6 全不显著的逆事件）——指标看越多，假阳性越严重；主指标预注册，其余指标标注"探索性"
• 偷看数据：每天都在跑中途数据，看到"显著"就提前收——多次偷看会显著抬高假阳性率；提前终止需要专门的序贯方法
• 低基数追显著：新功能日活只有几百人，硬跑两周出不了结论，还延误上线节奏
• 忽略长期：短期指标涨（如点击率），长期指标跌（如留存）——A/B 只测窗口内，长期效果要另配追踪

适用与不适用

灰度发布与实验平台

• 灰度发布（渐进式上线）：1% → 10% → 50% → 100% 逐步放量，任何一级指标异常就回滚；灰度与 A/B 常结合：灰度是"控制风险地放量"，A/B 是"放量时做因果对比"
• 实验平台：企业级平台（如内部自建、开源平台）提供分流、埋点、显著性计算与防偷看机制；小团队至少要有：稳定分流 key、实验标识写入埋点、统一的显著性计算脚本——没有工具的 A/B 很容易做成"伪实验"

实验伦理

• 知情同意：用户应知道自己的行为可能被用于实验；至少要在隐私政策里明确"我们会进行产品实验"
• 最小伤害：不拿用户做高风险实验（如把支付按钮藏起来、对弱势群体测试有害内容）；不确定 AI 输出质量时，实验组要有人工兜底
• 透明的边界：灰度中发现问题应立即回滚并补偿受影响用户；涉及内容安全/隐私的实验需要合规评审
• 与「AI 产品开发生命周期」的审批与审计思想一致：实验本身也是产品决策，要留痕、可追溯

设计度量体系的搭建

从问题到指标：指标树

指标体系的正确起点不是"有哪些现成指标"，而是业务问题。自顶向下建树：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10

业务目标：提升 AI 助手的用户价值
├─ 北极星：每周完成任务的活跃用户数
├─ HEART 分解
│  ├─ 任务成功：任务完成率、平均任务时长、错误率
│  ├─ 留存：次日/7 日留存
│  └─ 参与度：人均会话数、周使用天数
├─ 下钻到具体流程
│  ├─ 对话式问答：首问成功率、追问率、转人工率
│  └─ 文档总结：生成采纳率、编辑率、放弃率
└─ 每条指标配：定义、口径、目标值、owner、采集方式

原则：每个上层指标都能下钻到可行动的下层指标（指标下跌 → 能定位到流程 → 能对应到设计改动）；每个下层指标都要挂到上层（没有上层的指标是虚荣指标）。

定性 × 定量的三角互证

单一证据类型会被系统性偏差污染：问卷里的"满意"可能只是不好意思；埋点里的"用时短"可能因为用户直接放弃。三角互证的逻辑：

互证法：定性发现生成假设 → 埋点验证规模 → 问卷补充态度 → 结论交叉确认。例：访谈发现"用户不知道能追问"（定性）→ 埋点发现"首问后 24 小时内追问率仅 12%"（定量）→ 追问率低与满意度低相关（问卷）→ 三重证据一致，才值得立项改引导。

度量报告的结构

度量结果要能推动决策，标准结构（每次度量都按这个模板写）：

1
2
3
4
5

目标（Goal）：这次度量要回答什么问题、服务什么决策
假设（Hypothesis）：我们预期什么、依据是什么
证据（Evidence）：数据与定性发现（带样本量、采集时间、口径）
结论（Conclusion）：假设是否成立、证据强度如何
行动（Action）：具体要做什么改动、谁负责、何时复查

报告忌讳：只贴图表不给结论（读者无法行动）；只有结论不给证据（无法核验）；不写口径与样本量（不同版本的数据无法比较）。

常见误区

• 虚荣指标（vanity metrics）：累计注册数、页面总浏览量——只涨不跌、不可行动；换成"每周活跃、完成率、留存"才有决策价值
• 指标游戏（metric gaming）：指标一旦挂钩 KPI 就会被优化指标本身而非用户价值（客服响应时间被刷成"点一下就算响应"）；对策：指标多元化、定期审计、指标与价值挂钩
• 忽略长期：短期指标全绿、长期信任与留存悄悄下滑；给长周期指标（留存、NPS、回访）设固定复查节奏
• 指标无主：每个指标没有 owner 和复查频率，三个月后口径已变，历史对比全部失效
• 以指标代替理解：指标告诉你"什么变了"，不告诉你"为什么"——指标下跌后不做定性研究就改版，等于蒙眼开车

AI 产品评估的特别议题

输出质量评测与设计评测的分工

AI 产品的"行不行"由两条证据链共同回答，别混在一起：

分工原则：设计评测把"模型输出质量"当给定输入（测的是界面是否把输出呈现好），输出质量评测把"界面"当给定输入（测的是模型本身）。但两者必须对话：设计测试里发现的"用户因错误答案流失"，要反馈给评测体系补评测用例；评测里发现的"模型常答非所问"，要反馈给设计补兜底界面。

AI 产品可用性测试的挑战

• 输出不可复现：同一任务两次测试，模型回答可能不同——测试脚本要定义"可接受结果范围"而非唯一答案；判定"任务成功"时，给用户和观察者都配"期望要点清单"（与评测集的标注思路一致，见 AI 输出质量评测）
• 模型能力漂移：提示词、模型版本更新后，上次测试的结论可能失效——测试结论要标注模型版本与日期；重大模型升级后，核心任务至少重跑一轮冒烟测试
• 结果方差大：任务成败很大程度上取决于模型发挥，5 个用户的完成率可能因"这次抽到的回答质量"大幅波动——AI 任务的测试结论更依赖"卡点定性发现"，对"完成率数字"要更谨慎
• 测试的其实是"人机协作"：用户的任务结果 = 模型能力 × 界面引导 × 用户操作；测出来"完成率低"，要先分解是模型答得差、还是界面没引导好——可对照"错误注入"思路（总览）人为控制模型输出，分别测界面

人机协作效率的度量

AI 产品的核心承诺是"人机协作比人单独干更快更好"。度量这个承诺需要对比基线：

典型陷阱：只测"生成 1000 字耗时 3 秒"就宣布"效率提升 100 倍"——用户还要读、还要改、还要核对。度量人机协作效率，永远以"用户交付整个任务"为单位，不是以"模型输出"为单位。

不确定性表达与信任的度量

AI 产品里，信任是设计的核心资产，而信任来自"不确定性是否被诚实表达"（见总览的文案契约）。信任的度量分两层：

• 态度层（信任问卷）：可用性测试后追加 3~5 题信任问卷（"你相信这个 AI 给出的答案是可靠的吗？""出错后你愿意再给它一次机会吗？"），1~7 分；或直接引用 NPS 的推荐意愿
• 行为层（代理指标）：行为比问卷更诚实——采纳率（建议被采用的比例）、重试率（出错后是重试还是放弃）、转人工率（信任崩塌的信号）、反馈率（愿意花时间纠正 = 还愿意给它机会）

两者结合才能完整判断：问卷说"信任"但重试率极高，说明用户嘴上信任、行为上不敢；问卷低但采纳率高，可能只是"没别的选择"。设计上的不确定性表达（置信度提示、引用来源、"我不确定"的明示）做了之后，用这两层指标前后对比，就能量化"诚实表达到底值多少信任"。

来源说明

以下来源均于 2026-08-24 整理，以官方最新页面为准；页面可能随时更新。

经典论文与著作

• Jakob Nielsen & Rolf Molich, "Heuristic evaluation of user interfaces"（CHI '90）；Jakob Nielsen, "10 Usability Heuristics for User Interface Design"（1994, nngroup.com）——十条启发式与严重度分级
• Nielsen & Landauer, "A mathematical model of the finding of usability problems"（CHI 1993）——5 用户发现约 85% 问题的数学模型
• John Brooke, "SUS: A 'quick and dirty' usability scale"（1996）——SUS 问卷与计分
• K. Anders Ericsson & Herbert A. Simon, Protocol Analysis: Verbal Reports as Data（1984）——出声思维的理论基础
• Bill Albert & Tom Tullis, Measuring the User Experience（Morgan Kaufmann）——可用性度量方法论与基准测试
• Jeff Sauro & James R. Lewis, Quantifying the User Experience——SUS 68 分行业均值、评级与样本量估算

行业文章与框架

• Kerry Rodden 等, "Defining and measuring user experience with HEART"（Google Design, 2010）——HEART 框架
• Nielsen Norman Group（nngroup.com）：usability testing、moderated vs unmoderated testing、A/B testing 系列文章
• NASA Task Load Index（TLX）官方说明（humansystems.arc.nasa.gov）——负荷测量

标准与站内相关页

• ISO 9241-11（可用性的定义：有效性、效率、满意度；按需查阅）
• 产品设计与原型总览（AI 产品设计评审检查表、对话式 UI 可用性测试要点、错误注入与压力测试）
• AI 输出质量评测（评测集、线上指标、LLM-as-Judge，与设计评测分工）
• 用户研究（访谈与样本量，与可用性测试被试招募互补）
• 交互设计基础（心智模型、反馈与导航，启发式评估的具体落点）
• AI 产品开发生命周期（CC/CD）（灰度发布、审批与审计，实验伦理的落地）

发现错误？想一起完善？ 在 GitHub 上编辑此页！
本页面贡献者：AI-PM Wiki Team
本页面的全部内容在 CC BY-SA 4.0 和 SATA 协议之条款下提供，附加条款亦可能应用