原文：NN/g｜Project Postmortems for UX Teams: Learning from Success and Failure

作者：Laura Klein

发布日期：2026-02-27

摘要：尽管项目复盘是产品开发中最强大的学习工具之一，但大多数团队仍未真正学会如何有效地使用它。

项目复盘这个概念借自工程团队。多年来，工程团队一直用复盘来防止灾难性的 bug 再次发生。它是产品开发中最被低估、也最少被充分利用的工具之一。如果把它有意识地调整到适合 UX 与产品工作的语境中，它就能成为一种系统化方法，帮助我们同时从成功和失败中学习。但多数团队要么完全跳过复盘，要么把它做得过于敷衍，几乎等于白做。

让我们把这件事做好。

本文内容

• 复盘是什么，不是什么

• 什么时候做复盘

• 复盘应该包含什么

• 一次高质量复盘的结构

• UX 特有的考量

• 如何让复盘成为团队文化的一部分

• 目标：系统性改进

复盘是什么，不是什么

项目复盘（postmortem），是对一个已经完成的项目所做的结构化分析，关注发生了什么、为什么会发生，以及因此需要做出哪些系统层面的改变。

它的目标很直接：足够深入地理解这个项目，从而复制成功，避免失败。

请注意，我写的是“已完成的项目”，而不是“失败的项目”。这是团队首先需要打破的误解。是的，当你们新的引导流程把转化率拖垮时，当然应该做复盘；但当你们重新设计的结账流程让购买量提升了 40%，而你们原本只预期提升 15% 时，同样也应该做复盘。

成功往往比失败更能带来启发，前提是你真的去学习它。

复盘与 Sprint 回顾有什么不同

如果你们采用某种 Agile 工作方式，那你们很可能已经在做回顾会议了。回顾通常发生在每一个 sprint 结束后，重点关注团队过程：我们应该继续做什么？停止做什么？下一次尝试什么？它面向未来，关注的是过程本身。

如果你想把 UX 回顾做得更有效，那确实值得认真做。这里有一些关于如何开展高质量 UX 回顾的建议。常规回顾确实能够显著改善团队流程，但它并不能替代项目复盘。

复盘和回顾有相似之处，很多关于主持回顾的建议也适用于复盘，但两者在关键点上不同。复盘是向后看的、以结果为中心的。它在某个具体项目完成之后（或者你已经拿到了足够多的数据可以评价这个项目之后）进行，关注的问题是：这个项目是否成功？为什么成功或失败？我们能从这个结果中学到什么？

一次 sprint 回顾也许会暴露出你们团队需要更好的干系人沟通；一次项目复盘则可能揭示：你们上一次产品发布失败，是因为从未验证过自己真正要解决的问题，并最终形成一条新的团队要求：以后所有项目在进入设计阶段之前，都必须先完成问题验证。

两者都很有价值，谁也替代不了谁。

什么时候做复盘

时机比大多数团队想象的更重要。复盘做得太早，你就是在没有数据的前提下做决策；复盘做得太晚，人们会忘记关键细节，甚至已经转到别的团队去了。

对于有可衡量结果的项目，比如实验、发布或功能上线，应该等到你已经拥有足够数据、能够评估成败之后再做复盘。如果你衡量的是 30 天留存，就不要在第 2 天做复盘；但也别等上六个月。到那时，团队早已进入下一个阶段，很多细节也淡掉了。

对于没有清晰指标的项目，比如探索性研究、设计系统工作或流程改进，则应该在项目完成后的两周内开展复盘，这样一切还足够新鲜。

一个通用判断标准是：如果大家开始说“我已经不太记得我们当时为什么这么决定了”，说明你等太久了；但如果大家说“我们还不知道这次到底有没有效果”，那说明你做得太早了。

复盘应该包含什么

我们来看两个场景，一个是“失败”，一个是“成功”，借此理解一次好的复盘到底长什么样。

场景 1：指标实验失败了

你们团队假设：在产品注册页加入社会认同元素，能让转化率提升 30%。你们设计了不同方案，也正确执行了实验，但最终转化率只提升了 1%。本质上，几乎没有变化。

这种情况下，复盘需要检查两件事：为什么实验失败了，以及为什么你们一开始会相信它会成功。

第一个问题可能让你发现：你的用户是企业采购者，他们根本不在意面向消费者的社会认同；或者设计落地得太弱；又或者社会认同确实有用，但 30% 的预期实在太乐观。

第二个问题，也就是“为什么你们会相信它会成功”，往往更有启发性。你们是不是因为“自己挺确定的”，就跳过了用户研究？是不是引用了竞争对手的案例研究，却没有考虑对方用户和你们用户之间的差异？是不是干系人的热情压过了数据？是不是某位产品经理为了推动自己偏爱的项目而夸大了其潜力？

理解你们当时的推理过程，才能帮助你们修正这个过程。也许最终产出是一条新的要求：所有实验假设都必须有用户研究支撑；也许是做一次团队校准，让大家对现实中的效果量有更准确的判断；也许是决定不再把竞争对手案例研究当作主要证据来源。

场景 2：功能取得了超预期成功

你们上线了一个新的仪表盘功能，希望它能提升用户参与度。你们原本估计日活跃用户会增长 10%，结果实际增长了 45%；功能还提前两周交付，用户甚至开始要求产品的其他区域也做类似更新。

这次为什么会这么顺利？

一次高质量复盘也许会发现：设计师此前在这个领域工作过，对用户工作流有很深理解；或者你们异常早地把用户纳入进来，并在正式交付前先做了若干初步实验来验证方向；又或者整个项目期间团队非常稳定，没有人员流动；再或者工程负责人推动了一种更有利于快速迭代的技术方案。

无论原因是什么，你都应该把它们找出来，并系统性地提高它们再次出现的概率。也许你们会形成一种新做法：在复杂功能中引入领域专家；也许会坚持在战略项目中先做验证性实验；也许会在重要项目上更积极地争取团队稳定性。

成功并不是魔法。 它同样有原因，而这些原因是可以被识别出来的。

一次高质量复盘的结构

下面这些要素，能让复盘真正产生价值。

1. 把合适的人请进房间

至少应包括：

• 参与该项目的核心团队成员

• 产品经理或项目负责人

• 参与过关键决策的主要干系人

• 一位能够提供外部视角的相关团队成员（可选）

不要邀请 30 个人。你需要的是足够多的视角，能看清全貌；但人数也要足够少，保证每个人都能有意义地参与。通常来说，6 到 10 人是合适的规模。

2. 明确的成功标准（最好在项目开始前就定义）

如果你们在项目开始时没有定义什么叫成功，那么复盘就会困难得多。你们最终会陷入争论：5% 的提升到底算不算好？晚交付两周到底能不能接受？

对于未来项目，应该提前定义成功指标。对于当前这次复盘，则应在开头花一些时间先对齐：你们当初想达成的到底是什么，现在又是如何衡量它的。

3. 心理安全

这一点至关重要，尤其是在项目结果不理想的时候。如果人们害怕被责怪，他们就不会诚实表达，而你也就无法真正学到事情是如何发生的。

要明确说出来：我们来到这里，是为了理解发生了什么，并改善我们的系统，而不是为了责怪某个人。你甚至可以考虑请一位没有参与该项目的主持人来带这场复盘。

当错误被提出来时，问题永远应该是：我们的流程中有什么让这个错误得以发生？ 而不是：为什么某个人搞砸了？人会犯错，系统应该能兜住错误。

4. 根因分析

这一步是为了深入理解：某件事究竟为什么会发生。一个很有用的方法，来自我做工程的经历，叫“五个为什么”。

来看一个设计场景中的例子。

问题： 用户在新的结账流程中有很高的放弃率。

• 为什么？ 因为他们在支付信息这一步感到困惑。

• 为什么？ 因为表单没有清楚说明哪些字段是必填项。

• 为什么？ 因为设计里必填项标识不够明显。

• 为什么？ 因为设计师直接使用了组件库默认样式，没有做定制。

• 为什么？ 因为组件库文档没有说明：在涉及可访问性时，什么时候应该对组件做定制。

这样你就找到了一个真正的根因：组件库文档不足。解决方案不是“设计师以后要更仔细”，而是“更新组件库文档，加入可访问性指南与定制建议”。

当然，另一种解决方案也可能是直接更新组件实现，让“不符合可访问性的内容”根本不可能被发出去。有时具体方案取决于：你们团队自己能做到什么，或者你们能说服其他团队改进到什么程度。

你不一定非得问满五次。有时候三次就够，有时候可能需要七次。关键是不断往下追，直到你触及某个可以被系统性改变的层面。

其他有用的方法还包括：

• 时间线重建：梳理关键决策及其后果

• 资源配置分析：我们是否拥有合适的人、时间与预算

• 外部因素考量：市场变化、竞品动作或组织层面的变化是否影响了结果

5. 复盘必须产出可执行的改进项

这一点没有商量余地。每一次复盘都必须产出能够落地的系统性改动。

不好的复盘产出包括：

• “和干系人沟通得更好一些。”

• “招募研究参与者时更仔细一点。”

• “别再让这种事发生。”

• “大家聪明一点。”

这些说法模糊、不可执行、也无法追踪。而且它们默认人类在所有情境下都能一直做出正确选择。以我的经验看，这基本不会发生。

好的复盘产出包括：

• “为所有战略项目在研究阶段结束时新增一个必需的干系人评审关卡。”

• “更新研究招募清单，在安排时间前新增一步，用于核验参与者是否符合资格。”

• “建立一份上线前清单，其中包含与工程一起复核埋点实现。”

注意，好的产出一定是在改变系统。它们会引入新的流程、更新文档、修改清单，或者建立新的要求。它们并不依赖人们口头承诺自己会“做得更好”。

你应该重点关注两类改变：

• 流程改变：例如引入清单、增加新的评审步骤、修复已损坏的系统，以防止坏事再次发生

• 文化改变：例如调整团队心态，或让某些行为变得更自然、更常态化，从而改变团队的运作方式

也许你发现，设计师和研究员在早期结对时，工作成果最好，于是你把“早期结对”设成默认做法；也许你发现，配备专职项目经理能显著改善沟通与时间线执行，于是你开始为未来的重要项目争取项目管理支持。

6. 每一个复盘产出都必须有人负责

可执行的改进项如果没有人来做，就毫无意义。在复盘结束前，给每一个行动项指定负责人和截止时间。

然后持续跟进。这一步正是大多数团队会跳过的地方，也正因如此，很多复盘最终什么都没有改变。建立一个每月重复的提醒，定期检查这些行动项，并向团队同步进展。如果某项工作迟迟没有推进，就去弄明白原因：是优先级不对，还是根本不值得做？然后重新排序，或者干脆删除。

7. 记录与归档

把你们学到的内容写下来，并保存到全团队都能访问到的地方：共享盘、wiki、Confluence 页面，或者任何适合你们组织的地方。

而且要让它容易被找到。未来团队成员在即将启动新的结账改版项目时，应该总能看到上一次结账改版的复盘。

记录中应包括：

• 项目概览与目标

• 成功指标与实际结果

• 根因分析的关键发现

• 行动项及其负责人

• 时间线（如有必要）

不要写成长篇小说。通常两到三页就够了。

UX 特有的考量

虽然复盘源于工程领域，但 UX 与产品工作有自己的特殊挑战，这些内容值得被单独关注。

研究质量 vs. 研究影响力

有时候，非常好的研究会被忽视；有时候，平庸的研究却推动了重大决策。你的复盘应该同时检查研究本身的质量，以及它是否真的影响了结果。同时，也要承认某些项目里根本没有做研究，并审视这对最终结果产生了什么影响。

如果你做了严格的生成式研究，但最终没有人采取行动，这本身就值得分析。为什么它没有真正落地？是沟通问题？时机问题？是干系人没有理解其中含义？还是你没有把研究洞察和业务指标建立起足够清晰的联系？持续做复盘，可以帮助团队识别一种常见模式：忽视研究结果之后，项目往往更容易失败。

干系人参与模式

你何时让干系人参与、又是如何让他们参与，会极大影响项目结果。复盘应该明确检查这一点。

你是不是让领导层参与得太晚，以至于很多决策都已经做完了？你是不是让他们参与得太多，导致每一个小决定都演变成委员会式讨论？你是不是在错误的时点把他们拉进来，比如你真正需要的是战略方向，他们却在执行细节上给出大量反馈？

找出真正有效（或无效）的参与模式，并把它固化到未来项目中。

设计迭代节奏

UX 工作需要迭代，但“迭代多少才合适”并没有天然答案。复盘可以帮助你校准这件事。

也许你会发现，自己测试得太早了，拿着随手画的草图去测，反而让用户困惑、浪费时间；也许你会发现，自己测试得太晚了，结果不得不推翻大量高保真工作；也许你找错了测试对象，比如你需要主流用户，却找了早期采用者；或者你在做企业产品时，却找了消费者用户。

这些洞察都能帮助你优化未来的迭代周期。

区分相关性与因果性

要谨慎，不要因为 X 发生在 Y 之前，就武断地认定是 X 导致了 Y。对于 UX 工作尤其如此，因为很多因素可能同时影响结果。

你的新设计上线后，留存提升了。很好！但真的是设计导致了提升吗？还是说它恰好与一场营销活动、一次竞品涨价，以及你所在品类的季节性上升同时发生？

好的复盘会通过时间顺序之外的更多证据，去区分真正的信号和噪音。如果你做过 A/B 测试，那你已经有了一个很好的起点，因为你至少知道设计变更是否有效，接下来可以把重点放在：为什么你的假设成功或失败，从而改善未来决策。如果你没有做实验，那就要利用现有的定性数据做交叉验证，排除其他解释，并尽量理解真正推动结果的因素。

让复盘成为团队文化的一部分

前几次做复盘时，感觉通常都会很别扭。大家不知道该期待什么，会担心被责怪，也会怀疑这是不是在浪费时间。

坚持下去。

当你们做过三四次之后，人们开始看到行动项真的被执行，也亲眼看到团队确实在变好，复盘就会开始从“痛苦的流程”变成“有价值的实践”。

以下是建立这种习惯的方法：

• 从成功案例开始。 你的第一场复盘，最好分析一个做得不错的项目。这样能建立更积极的氛围，也能在没有失败情绪负担的情况下，帮助大家熟悉这种形式。

• 坚持无责。 每一次都要反复强调：我们在分析系统，而不是评判个人。当有人开始责怪自己或别人时，把讨论重新拉回流程层面。

• 狠抓落实。 如果你不去执行复盘产出，人们很快就不会再认真对待复盘。真正的价值，存在于执行之中。

• 广泛分享学习成果。 当某次复盘产出了有价值的洞察，就把它分享给其他团队。这能放大学习价值，也能鼓励更多人参与。

• 保持规律，但不要制造负担。 并不是每个很小的项目都需要做复盘。把重点放在战略项目、重大上线、关键实验，以及那些带来了意外结果的项目上，不论这个结果是好还是坏。

目标：系统性改进

我在做工程复盘时学到的一点是：当坏事发生时，比如一个 P0 级 bug 让生产环境宕机、安全漏洞，或者数据丢失事件，我们不能只修复眼前的问题。我们必须把根因理解得足够透彻，直到足以阻止同类问题再次发生。

同样的原则也适用于产品开发。当一个项目失败，或者比预期成功得多时，你其实获得了一个非常难得的机会：弄清楚为什么会这样，并系统性地改进团队的工作方式。

可惜，大多数团队都没有真正利用这个机会。他们上线，然后继续往前走；他们不断重复同样的错误，也无法复制自己的成功；他们即便会变好，也通常只是靠经验一点点慢慢累积，而不是通过有意识的系统性改进。

复盘的价值，就在于让这种改进真正发生。