现有 App 要改版，怎样用任务完成率和耗时找到业务卡点？
结论：现有 App 改版，先选一条对业务重要的用户任务，观察真实用户能否独立完成、花了多久、在哪里求助，再确定需要改的范围。界面、操作流程、等待反馈和后台处理可能分别造成阻塞；只换视觉风格，未必能让客户更顺利地下单、预约或报修。完成率和耗时要有一致口径，也要与任务正确性、客服负担及后续业务结果一起看。
适用对象：已有用户，却说不清该改哪里
这套方法适合已经上线 App、准备投入下一轮改版的企业负责人和产品负责人，尤其适合门店服务、设备售后、客户订货和预约类产品。常见起点是：销售说客户不会用，客服说电话越来越多，管理层觉得页面旧，而开发团队收到的需求只有“重新设计一下”。
此时应先回答一个可验证的问题：哪个人，在什么场景下，要完成什么事情，却被哪一步挡住了？品牌视觉更新可以有独立价值，但应与任务体验改善分开立项、分开验收，不能用一套新截图证明业务效果。
Nielsen Norman Group 的可用性测试方法强调观察目标用户执行真实任务；Google Research 的用户体验度量研究强调从产品目标映射到指标。两者结合支持“先确定任务，再用观察和数据决定改动”的思路，而不是提供统一的改版收益保证。下文以国内企业服务 App 为应用情境，给出可与业务和开发团队共同确定的诊断方案。
第一步：把“提高体验”改成一张任务卡
不要一次要求研究全部页面。可以先从客服反复解释、客户经常放弃、或者出错代价较高的一条路径开始，例如“给已购买的设备提交一次报修，并找到受理结果”。这是示例情境，不是对某个真实 App 的缺陷判断。
一张任务卡至少写清：目标用户、新用户还是熟练用户、进入 App 的起点、事先掌握的信息、允许使用的帮助、任务结束条件，以及关联的后台状态。报修任务的结束不宜只是“按下提交”，而应是生成正确设备的报修记录，后台能收到，用户能辨认单号和下一步处理方式。维修是否最终完成，是另一段服务流程的指标。
同样，预约提交成功与门店确认有空位应分开；支付页面打开与付款成功应分开；报价申请交付与客户接受报价也应分开。负责人要明确本次改版究竟改善哪一段，哪些后续结果由门店、客服或其他系统共同负责。
第二步：先统一指标，避免不同团队各算各的
建议为每条任务保留以下记录，而不是只汇报一个平均分。
| 记录项 | 本轮可以怎样约定 | 容易造成的误判 |
|---|---|---|
| 独立完成 | 无操作提示且达到预定正确结果的尝试数 / 有效任务尝试数 | 主持人带着操作也算独立完成 |
| 求助后完成 | 记录求助发生步骤、帮助内容和最终结果 | 把人工支持成本藏在完成率里 |
| 未完成或错误完成 | 放弃、超时、错误对象、重复业务记录分别标记 | 只看到成功页面就认为业务正确 |
| 操作耗时 | 统一起止点，分别记录成功、失败和中断的尝试 | 把迅速放弃当成效率提升 |
| 系统与服务等待 | 区分页面响应、上传处理、门店确认等等待 | 所有等待都归因于页面设计 |
这里的“有效任务尝试数”必须在测试前定义，不能为了好看而事后删除失败。若一个人重复尝试，保留尝试之间的关联，并说明统计单位是人、一次任务还是业务单据。若允许跨天保存后继续，需约定观察期；尚在等待中的任务不要提前算作最终失败。
GOV.UK 的完成率指南以已完成交易占已开始交易的比例为基础，并要求明确起止点。迁移到企业 App 时，可借鉴这种口径清晰的做法，但英国公共服务的统计制度不等于中国企业的合规要求，也不能直接当作行业完成率基准。
耗时建议同时报告样本数、中位数与较慢的实际案例，并保留求助和失败记录。小样本的结果主要用于定位问题，不宜据此声称“全体客户转化率将提高多少”。若一边操作一边解释想法，应注明该测试条件，不与静默操作的线上时长直接比较。
第三步：让用户完成任务，而不是跟着演示点击
参与者应覆盖真实使用情境。例如设备服务 App 可能同时面对首次报修的采购人员和经常处理设备的现场人员；只请熟悉内部流程的员工试用，会漏掉客户不懂产品编号、找不到凭证等问题。
任务描述可以是“这台设备无法启动，请联系售后并确认申请已被收到”，不宜写成“点击首页右下角报修按钮，再选择第二个菜单”。测试前准备适当的测试账号、设备与订单资料，避免真实付款、真实派工和误发客户通知。涉及录屏或访谈时先取得参与同意，只收集必要信息，限制访问范围与保存时间。
记录观察时，将三类内容分开：
- 观察事实：参与者停在设备选择页，反复切换两台名称相近的设备，并询问应选哪一台。
- 改进假设：增加设备安装位置和易辨认图片，可能减少选错。
- 验证动作：在修改后的原型中使用同类任务，检查选择是否正确、是否仍需求助。
不能仅凭一次犹豫就断言后台架构有问题；同样，用户说“很好用”也不能代替操作证据。线上事件数据可以帮助识别异常集中在哪一段，访谈与任务观察再帮助解释原因；若埋点尚不可靠，应先核对事件与业务记录的一致性。
第四步：把卡点分配给正确的改动范围
对报修示例，可以按以下方式形成待办，而不是统一归为“优化 UI”。
找不到入口，先验证信息布局和入口命名；不确定选哪台设备，检查设备信息与账号关联；资料要求不清，调整表单说明和必要字段；照片上传后没有反馈，检查进度、失败提示和重新提交；申请已送达却一直无人处理，则核对后台队列、责任人与通知。最后一种情况仅改 App 前台不会解决问题。
优先级应综合业务影响、证据充分程度、预计改动量及依赖。导致错误付款、错选设备或遗漏客户请求的问题，应由团队评估其风险优先处理；纯偏好差异可以进入后续视觉迭代。尚无证据但成本很高的重构建议，先做专项诊断，不直接装进改版报价。
一个可交付的改动条目应包括：问题证据、影响的用户和任务、需要修改的前台与后台范围、依赖方、验收场景，以及本轮明确不做的内容。只有当这些信息足够清楚时，报价和排期才有共同基础。
第五步：先验证一条关键路径，再安排发布
可以把项目分为三个可独立判断是否继续投入的阶段。
诊断阶段交付任务清单、样本与环境说明、基线记录、问题证据和优先级。此阶段不是承诺所有问题都能靠设计解决。
方案阶段交付关键路径原型、后台协同说明和复测结果。涉及等待、失败、返回修改及重复提交的状态，也要进入原型或交互说明，不能只画顺利完成的几张页面。
开发上线阶段实现已确认范围，完成业务与技术测试，在可控用户范围观察，再决定扩展。新旧版本比较应保持任务、用户构成和计时条件尽量一致；同一批人重复操作会有学习效应，需要在报告中说明，不能把熟练了全部算作改版效果。
诊断、设计、实现、后台接口、数据埋点、用户招募和上线后的观察支持应分别列清是否包含。费用取决于路径数量、角色差异、设备覆盖、已有系统可改程度和证据收集工作量，不能只按页面张数估计整项改版。
验收时，负责人应该拿到什么
验收至少需要确认以下事项：
- 当前交付版本和测试环境有记录，基线与复测的比较条件说得清楚；
- 关键任务有明确、可重复的成功与失败判定，而不是“整体感觉顺畅”；
- 改动解决了已记录的问题，或对未解决原因、剩余风险与后续计划有说明；
- 业务记录与前台反馈一致，关键异常和求助路径可以继续处理；
- 每个统计值能追溯到样本和计算口径，不把小样本结果包装为市场表现；
- 上线观察有负责人、监测周期、暂停条件和恢复方案。
量化目标应在看到基线并理解风险后由双方约定。没有足够用户或数据时，可以先验收问题复现与修复、关键路径正确性和证据完整性；更大范围的效果判断留到真实使用阶段，不凭空填写一个漂亮的百分比。
常见误区与上线后的持续改进
“页面停留越久越好。” 对内容阅读可能是兴趣，对报修提交却可能是找不到按钮。先看任务目标。
“投诉少就说明改好了。” 也可能是用户不再尝试。应结合有效任务量、未完成情况和客服渠道变化。
“流程越短越好。” 必要确认能防止误操作。减少无价值重复，不等于取消有价值的校验。
“做完一次测试就可以永久沿用。” 产品增加服务、改变价格、调整登录或更换后台系统后，同一条路径可能重新出现阻塞。
上线后定期复看关键任务、求助类型和失败集中步骤；把新问题放回同一套证据记录。业务负责人决定问题价值，产品与设计团队形成方案，开发与测试确认实现和风险，客服或运营验证后续处理是否接得住。改版的结束点不是新界面发布，而是关键改动得到验证、未解决事项有人负责。
若团队还没有统一的任务和范围说明，可先参考 需求尚不清晰时的产品设计与业务梳理，再确定本轮诊断和开发的交付边界。
参考来源
- Nielsen Norman Group：Usability Testing 101：支持以真实用户任务与观察定位体验问题，区分定性发现和量化基线。（访问：2026-09-11）
- Google Research：Measuring the User Experience on a Large Scale：支持从产品目标选择用户体验指标；不是针对本文示例 App 的实验结果。（访问：2026-09-11）
- GOV.UK Service Manual：Measuring completion rate：提供完成率、交易起止与后续完成的统计参考。（访问：2026-09-11）