实验、评审与持续迭代
很多产品不是没有做体验改进，而是改进停在了"交付"那一刻。
1. 导读
页面改了，流程上线了，文案替换了，设计稿归档了，团队在复盘会上说"这一版体验更顺了"。1但用户真的更顺了吗？新问题有没有出现？旧问题是不是只是从一个入口转移到了另一个入口？这次改动带来的数字变化，是因为体验变好，还是因为活动、价格、流量、客服话术、销售策略同时变化？
如果没有实验、评审和持续迭代，体验改进很容易变成一次性项目。项目开始时声势很大，项目结束后，问题列表没有持续跟踪，指标没有复盘，设计决策没有沉淀，下一次团队又从头争论同样的问题。2
持续迭代不是无休止地换版本，而是让每一次改动都有来处、有证据、有去向。这里讨论的不是某一种工具，而是一套改进机制。A/B 测试、启发式评估、设计走查、质量评审、复盘和 backlog 都只是这套机制中的不同部件。3
2. 核心问题
核心问题是：如何让体验改进形成持续闭环，而不是一次性项目？
这个问题背后有三个常见困境。第一个是"上线即结束"：很多团队把上线当成项目终点，但对用户来说，上线只是体验的开始。第二个是"意见替代证据"：设计师觉得清楚，产品经理觉得转化会提高，老板觉得颜色不够醒目；当所有判断都停留在意见层面，团队就很难知道哪个判断真正成立。第三个是"数字替代理解"：只要 A/B 测试胜出就认为方案更好，只要转化率上升就认为体验改善。数字提供信号，但数字不会自动解释原因。4
持续迭代的目标，不是证明设计师"猜对了"，而是帮助团队更快学到真实情况。
3. 关键概念与定义
A/B 测试，是把用户随机分配到两个或多个方案中，比较不同方案对预设指标影响的在线受控实验。Microsoft Research 强调，受控实验可以帮助软件团队更科学地评估功能对用户行为的影响。 但 A/B 测试不是"两个页面谁赢了"的投票。它至少需要假设、样本量、随机分配、成功指标、护栏指标、实验周期、显著性判断和异常监控。5
体验实验，可以是 A/B 测试，也可以是原型测试、可用性测试、灰度发布、文案理解测试、树测试或任务表现对比。体验实验不一定都在线上，也不一定都追求商业指标。
启发式评估，是由具备 UX 经验的人依据一组可用性原则检查界面或流程，发现潜在体验问题。
设计走查，是沿着用户任务路径检查设计方案。设计质量评审，是组织层面把关体验质量的机制。复盘，是在项目或实验结束后，回顾目标、过程、证据、结果、决策和后续行动。持续迭代，是围绕用户任务和体验目标的连续改进机制。6
4. 概念边界与相近概念区别
A/B 测试不等于可用性测试。专家评估不等于用户研究。设计评审不等于领导拍板。灰度发布不等于实验。迭代不等于反复改。
5. 方法、流程或框架
持续迭代可以用一条简单链路来理解：假设、验证、判断、行动、沉淀。
先看假设。体验团队不应该只说"我们要优化结账页"，而要说"我们认为用户在支付前退出，可能是因为费用变化出现得太晚，导致信任下降"。这句话里包含问题、原因、改动、目标和边界，比"优化结账页"更可验证。7
然后选择验证方式。不是所有假设都适合 A/B 测试。如果问题是"用户能不能理解"，先考虑可用性测试；如果问题是"两个成熟方案在真实流量中哪个更有效"，再考虑 A/B 测试。8
接着定义指标。好的实验至少有成功指标和护栏指标。成功指标回答"我们希望变好的是什么"，护栏指标回答"哪些东西不能变坏"。
再控制实验条件。A/B 测试需要随机分流、稳定周期、排除明显异常、关注样本量和统计显著性。对于低流量 B2B 产品，强行做 A/B 测试往往得不到可靠结论。
然后做决策。实验结果通常不是简单的"赢"或"输"。有时成功指标上升但护栏指标变差，说明方案需要调整。
最后沉淀。每一次实验和评审都应该留下可复用材料。没有沉淀，团队会反复踩同一个坑。
6. 实际工作场景
消费级产品里的实验最常见：测一个按钮文案、一个入口位置、一个推荐策略。样本量大，几周就出结论。
电商结账尤其适合持续迭代——流程短，决策集中，每个步骤的流失都能被追踪。
B2B 和 SaaS 就难得多。用户基数小，一个季度都攒不够显著性样本。这种场景下，可用性测试比 A/B 测试更实际。
企业后台的迭代主要靠设计评审和灰度发布。批量操作错误一次影响几百条数据，风险太大，不能等实验跑完再说。
AI 产品又不一样。模型更新后，上周的实验结论这周可能就失效了。除了看转化，还要盯着错误率、人工接管率和过度依赖。
7. 案例
Microsoft 的在线实验平台是大型软件组织实施受控实验的典型案例。 当产品有足够多的流量和足够完善的实验基础设施时，几乎每个改动都可以先跑实验再全量，让团队不再只凭直觉判断"有没有变好"。但这条路的前提条件相当苛刻——B2B 产品几乎都不具备足够样本量，此时需要转向可用性测试、专家评审和灰度发布等替代验证方式。
对于不具备大规模实验条件的产品，专家评估和设计走查可以形成低成本的验证补充。实践中建议在每次迭代前先写清假设和验证方式，再根据产品规模选择验证手段：高流量产品优先实验，低流量产品优先评审和测试。
持续迭代的真正含义不是"改到满意为止"，而是"改完以后继续观察它是否还能在变化的环境里正常工作"。无论是实验还是评审，单次结论都有时效性——用户习惯、设备环境、业务规则都在变化，迭代应该是持续的、有证据的、有沉淀的。
8. 数据、指标或衡量方式
实验和迭代的指标应围绕"要验证什么"来选。如果验证理解问题，看文案理解正确率。如果验证流程效率，看任务成功率和完成时间。如果验证转化路径，看漏斗流失率和转化率，同时必须设置护栏指标。如果验证持续价值，看留存和核心功能真实使用。如果验证风险，看用户是否犯严重错、误操作能否恢复。
实验指标需要区分成功指标、诊断指标和护栏指标。成功指标像终点线，诊断指标像路线图，护栏指标像刹车。
9. 常见误区
把 A/B 测试当成万能裁判。不是所有假设都适合做 A/B 测试——低流量产品、高风险场景、探索性问题，都不应该简单地"跑个实验看看"。
把"转化率赢了"直接写成"体验更好了"。转化率受促销、库存、流量质量共同影响。赢了可能是界面更清楚，也可能是折扣更深。
把专家评审当成用户证据。专家能快速发现问题，但专家不是用户。评审通过的设计在真实用户手里仍然可能卡住。
只评审视觉，不评审任务。评审时讨论半天圆角和间距，没人问"用户能不能在五分钟内完成一次配置"。
复盘只写成项目总结。"已上线"不是复盘。"上线后两周，配置错误率从12%降到3%"才是。
把迭代理解成不断加功能。迭代的核心不是加新的，是在已有基础上验证假设、修正错误、沉淀经验。
10. 小结
体验改进如果只做到交付上线为止，就很难真正产生持续价值。实验、评审和迭代的意义，就是让团队不再只凭感觉判断"有没有变好"。
这一章最重要的边界，可以归结为四个提醒：实验有适用条件，数字需要解释，专家评审需要用户证据补足，转化也只是体验结果的一部分。
下一次做改版时，不妨先写出假设和验证方式，再进入方案。判断一个体验团队是否可靠，也是同一套逻辑：能不能拿出证据定位问题、验证假设、控制风险、沉淀知识。
11. 延伸阅读
Ron Kohavi、Diane Tang 和 Ya Xu 的 Trustworthy Online Controlled Experiments 适合深入学习在线受控实验。
Microsoft Research 的 Online Experimentation at Microsoft 适合理解大型软件组织为什么需要实验平台。
NN/g 的 10 Usability Heuristics for User Interface Design 可作为启发式评估和设计走查的基础参考。
注释 1 Ronny Kohavi et al., Online Experimentation at Microsoft / Microsoft Experimentation Platform。🔗 https://exp-platform.com/
2 Kohavi, Tang, Xu, Trustworthy Online Controlled Experiments。🔗 https://experimentguide.com/
3 Jakob Nielsen / NN/g, 10 Usability Heuristics for User Interface Design。🔗 https://www.nngroup.com/articles/ten-usability-heuristics/
4 GitLab UX Scorecards。🔗 https://handbook.gitlab.com/handbook/product/ux/ux-scorecards/
5 Baymard Cart & Checkout Usability Research。🔗 https://baymard.com/research
6 Measuring the User Experience。🔗 https://www.elsevier.com/books/measuring-the-user-experience/albert/978-0-12-818192-8
7 Belmont Report / ACM Research Involving Human Participants。🔗 https://www.hhs.gov/ohrp/regulations-and-policy/belmont-report/index.html
8 NN/g, Usability Testing 101。🔗 https://www.nngroup.com/articles/usability-testing-101/