Framework Deep Dive

任务完成率测试

Task Completion Rate 是最基础的可用性指标：用户能做到这件事，还是不能？它不测量「用户喜不喜欢这个设计」，而是测量「用户能不能用这个产品完成他们的目标」。78% 是 Nielsen 的关键流程基准线。

下载 Skill
01 它解决什么问题

你的用户其实根本不知道怎么用你的产品

设计师和 PM 都对自己的产品太熟悉了——他们知道每个按钮在哪里、每个流程怎么走。这种「专家盲点」导致的结果是：他们觉得产品显而易见，而真实用户却在关键步骤上卡住。

用户调研中的口头反馈往往是乐观的：「我觉得还不错」「挺直观的」。但实际行为数据往往是残酷的：只有 48% 的用户能独立完成表单提交，没有任何错误。口头说好用，不等于真的好用。

任务完成率测试（TCR）用客观的行为数据替代主观的用户感受。「能完成 / 不能完成」是二进制的事实，不受表达方式或礼貌因素影响。配合失败点分析，TCR 不仅告诉你「有多少人失败了」，还告诉你「他们在哪一步失败的」——这才是设计改进的真正输入。

02 框架结构

测试设置 · 评分矩阵 · 完成率计算

TCR 测试的结构由三个核心要素组成：任务脚本、观察记录、完成率计算。以下展示一个完整的测试矩阵示例。

计算公式
TCR = (成功完成的任务数 ÷ 总尝试任务数) × 100%
完成率基准参考（Nielsen 研究标准）
0% 50% 危险线 78% 基准线 100%
低于 50%：必须重新设计
50–77%：需要显著改进
78%+：关键流程可接受基准
示例：8 用户 × 4 任务完成率矩阵
用户
任务 A
账户注册
任务 B
搜索商品
任务 C
添加到购物车
任务 D
完成结账
完成率
用户 01
✓ 完成
✓ 完成
✓ 完成
✗ 失败
75%
用户 02
✓ 完成
✓ 完成
✓ 完成
✓ 完成
100%
用户 03
✗ 失败
✓ 完成
✗ 失败
✗ 失败
25%
用户 04
✓ 完成
✓ 完成
✓ 完成
✗ 失败
75%
用户 05
✓ 完成
✗ 失败
✗ 失败
✗ 失败
25%
用户 06
✓ 完成
✓ 完成
✓ 完成
✓ 完成
100%
用户 07
✓ 完成
✓ 完成
✗ 失败
✗ 失败
50%
用户 08
✓ 完成
✓ 完成
✓ 完成
✗ 失败
75%
按任务
完成率
88%
88%
63%
25%
整体 66%
分析：任务 D（结账）完成率仅 25%，低于危险线，优先修复。任务 C（加购）63% 低于基准，需改进。
三种 TCR 变体
变体 01
二元完成率
最简单：完成或未完成，没有中间值。适用于有明确终点的任务，如「成功提交表单」。结果最干净，分析最直接。
变体 02
难度分级完成率
三级评分：独立完成 / 在提示下完成 / 彻底失败。区分「可以完成」和「容易完成」，对设计优化方向有更细颗粒度的指导。
变体 03
完成时间测量
记录每个用户完成任务的时间。离群值（异常慢）揭示摩擦点——即使用户「完成了」任务，耗时是基准的 3 倍也是设计问题。
03 适用场景

什么时候该用它？

TCR 测试最有价值的时机是有具体任务流程需要验证的时候——从注册到支付，从搜索到下单，每个关键路径都是 TCR 的测试对象。

🚦
上线前的最后质量关
新功能或重新设计的流程上线前，用 TCR 测试关键路径。低于 78% 就要推迟上线，而不是在线上用真实用户学习。
⚖️
A/B 设计方案对比
当有两个设计方案争论不下时，用 TCR 测试代替主观讨论。哪个方案的完成率更高，数据说话，结束辩论。
💸
转化率问题诊断
当漏斗数据显示某个步骤转化率异常低时，TCR 测试找到真正的失败原因——是用户不理解、找不到，还是操作出错？
♿
无障碍可用性评估
对特定用户群（老年人、视障用户、低数字素养用户）进行 TCR 测试，量化无障碍差距，为产品优先级提供数据支持。
📋
监管合规与政府服务
政府数字服务、医疗平台、金融工具等高风险场景中，TCR 是必需的合规证明，证明关键功能对所有用户可用。
📈
改进效果量化验证
设计改进之后，用相同测试方案重新测试，比较前后 TCR 变化。让「设计改进了用户体验」从定性描述变成可量化的数字。
04 真实案例

Gov.uk：用 TCR 数据
说服政府拨款 3500 万英镑

2013 年，英国政府数字服务局（GDS）对当时的「全民信用」（Universal Credit）福利申请流程进行了 TCR 可用性测试。这个测试的结果成为英国政府数字化历史上影响最大的一次数据报告。

Gov.uk / GDS
Universal Credit 申请流程可用性测试 · 2013–2014
2013–2014
测试前后对比
测试前
对真实申请用户进行 TCR 测试：完成表格全程（无需工作人员介入）的比率为 48%。即每两个申请人中，就有一个在没有人工帮助的情况下无法完成申请。这个数字被递交给了国会。
48%
主要问题
失败点分析显示：62% 的失败发生在「收入证明」上传步骤，30% 发生在「银行账户验证」步骤。用户不理解要上传什么文件，也不清楚验证失败的原因。
2个
问题点
重新设计
基于 TCR 失败点数据，GDS 重新设计了文件上传流程（添加了示例图）和账户验证提示。相同测试方案复测，完成率提升至 82%，超过了 78% 的基准线。
82%
48%→82%
任务完成率提升（+34 个百分点）
£35M
TCR 数据说服政府批准的重设计预算
2个
识别并修复的核心失败点
✓
为什么 TCR 数据有决策力
→
「一半人无法完成申请」是政策制定者能直接理解的语言，比 NPS 或满意度分数更有力
→
TCR 与失败点结合，直接指向了问题所在，不需要猜测解决方向
→
前后对比数据（48% → 82%）证明了改进有效，使项目具有可追责性
💡
关键启示
→
GDS 的整个设计准则（GOV.UK Design System）正是基于 TCR 为核心质量标准建立的
→
「用数据说话」在政府环境中尤其关键——TCR 是跨越技术与非技术受众的通用语言
→
这个案例已记录在 GDS Design Blog，成为政府数字化领域的标准参考案例
05 使用步骤

如何运行一轮完整的 TCR 测试

TCR 测试是标准化可重复的流程。从任务脚本到复测改进，每一步都有明确的操作规范。一轮完整测试可以在 2–5 个工作日内完成。

1
定义任务脚本
2 小时
写 3–5 个以真实场景为背景的任务描述，而非操作指令。任务脚本的质量直接决定测试数据的有效性。
✓「你收到一封邮件提醒你的账户即将到期，请完成续费。」（场景化，不含操作提示）
✗「点击账户设置，找到续费按钮，完成续费流程。」（含操作指引，无效测试）
参与者： PM + UX 研究员（必须由未深度参与该设计的人撰写，避免专家盲点）
关键提示：每个任务必须有明确的「完成标准」——什么状态算完成？例如：「用户停在订单确认页面」才算完成结账，而不是「点击了支付按钮」。模糊的完成标准会让评分人意见不一。
2
招募测试用户
2–3 天
招募 5–8 位匹配目标用户画像的参与者。远程工具（Lookback、UserTesting、Maze）或面对面均可。关键要求：他们之前没有见过这个设计。测试开始前的简介词要点：「我们在测试设计，不是在测试你。没有错误答案。如果你做不到，这是设计的问题，不是你的问题。」
参与者： UX 研究员 / PM 负责招募；确保用户招募筛选标准匹配真实目标用户
关键提示：5 个用户已经能发现 85% 的主要可用性问题（Nielsen 研究结论）。不要等到招满 20 人才开始测试——5 个人的快速测试比 20 人的长流程测试在多数情况下更实用。
3
执行观察
1–2 天
让用户尝试每个任务，全程观察并记录：是否完成、完成时间、发生的错误、用户表达疑惑或沮丧的时刻（犹豫超过 5 秒、叹气、说「这在哪里？」）。铁律：不论用户多么困难，不要给予任何帮助或提示。沉默对你来说很难，但对研究的完整性至关重要。
参与者： 研究员 1 人主持；1–2 人旁观记录（建议 PM 和设计师都要旁观至少 1 次真实测试）
关键提示：用「出声思考法（Think Aloud）」让用户说出他们正在思考什么。「我以为这个按钮会……」「我在找……但找不到」——这些语言是定位失败原因的最快方式。
4
计算与分析
3 小时
填写完成率矩阵，计算每个任务的 TCR。然后分析失败点：用户在哪一步停下来了？3 个以上用户在同一步失败 = 系统性问题，不是个人问题。重点关注：最低完成率的任务是哪个？该任务的失败集中在哪个操作步骤？用户在失败前尝试了什么（错误路径）？
参与者： UX 研究员主导分析；PM 参与结论讨论；设计师准备改进方案
关键提示：不要只关注整体 TCR，任务级别的完成率才是真正的行动输入。一个 75% 整体完成率可能隐藏着某个关键任务 30% 完成率的危机——分任务看数据。
5
修复并复测
1 周后
针对步骤 4 识别的前 3 个失败点进行设计改进。用完全相同的任务脚本、相同的测试环境，招募新的测试用户（不能是上次参与的人），重新测试。比较改进前后的 TCR 变化。重复这个循环，直到所有关键流程的 TCR 达到 78% 以上基准。
参与者： 设计师完成改进 → 研究员确认测试方案一致性 → 新用户参与复测
关键提示：每次只修复最严重的 3 个问题，然后立即复测，而不是一次修复所有问题再测试。这样你才能准确判断每个修复的效果，避免改动相互干扰的评估。
06 来源与历史

从人机工程学实验室走向产品度量标准间

任务完成率作为可用性测试的核心指标，起源于20世纪70至80年代人机交互（HCI）研究对"用户绩效"的量化探索。ISO 9241系列标准的制定将这一指标正式纳入国际规范，使其从学术研究工具演变为全球软件与硬件产品质量评估的通用语言。

1970s
人机工程学引入绩效测量
早期人机工程学研究者开始在受控实验室环境中测量操作员完成特定任务的成功率与时间，主要应用于航空、核电等安全关键系统的界面设计。此阶段的测量方法尚不统一，缺乏跨研究可比性。
1980s
个人电脑普及推动软件可用性研究
Apple、IBM等公司推出个人电脑后，软件界面的可用性问题开始进入公众视野。研究者将任务完成率引入软件评估，结合出声思维协议（Think Aloud Protocol），形成早期可用性测试的标准范式。
1998
ISO 9241-11正式定义可用性三要素
国际标准化组织发布ISO 9241-11，将可用性正式定义为效果（effectiveness）、效率（efficiency）与满意度（satisfaction）三个维度，其中"效果"直接对应任务完成率。这一标准使任务完成率成为国际公认的产品质量评估指标。
2001
SUPR-Q与基准测试方法成熟
Jakob Nielsen等研究者推动可用性基准测试（Benchmark Testing）方法的普及，系统化地使用任务完成率、任务时间与错误率组成评估矩阵。这一时期互联网企业开始将任务完成率纳入产品发布前的质量门控指标。
2010s至今
远程测试工具使大规模测量成为可能
UserTesting、Maze等远程可用性测试平台的兴起，使企业得以在全球范围内以极低成本收集任务完成率数据。与此同时，任务完成率被纳入HEART框架（Google）等产品度量体系，成为衡量用户体验健康度的核心指标之一。
配合使用

与这些工具搭配效果更好

用户测试五法则 — 互补使用：小规模测试快速定位任务失败根因 → PURE 可用性评估 — 深化评估：对问题任务做结构化可用性分析 → HEART 框架 — 上游输入：将完成率数据纳入整体体验指标体系 → A/B 测试框架 — 下游承接：针对低完成率任务做方案对比验证 →