一句话总结
设计批评不是为了证明谁对，而是为了在冲突中榨出更好的决策。Figma的框架强调非暴力沟通，Playbook则押注结构化流程——但真正有效的设计批评，既不是情绪管理，也不是模板套用，而是让参与者提前知道“我在这个房间里负责什么”。如果你还在为设计评审会上没人说话或吵成一团而头疼，这篇文章替你判断：该选哪个框架，以及为什么你之前理解的可能全是错的。
适合谁看
产品设计师、设计经理、产品负责人，尤其是那些每周要主持设计评审会、却总感觉会议效率低下的人。如果你来自中型以上公司（500+人），每周至少一次跨部门设计批评，且参与者包括工程师、产品经理、高管——这篇文章直接切中你的痛点。不是给刚入行的新手看的，而是给那些已经试过“让大家轮流发言”、“先肯定再批评”但依然无效的人。
薪资范围：设计经理base $140K-$180K，总包$220K-$350K（RSU部分通常占30%-50%，bonus 10-15%）。如果你是自由职业者或小团队leader，结论也适用，但请跳过那些关于组织政治的细节。
Figma设计批评框架 vs Playbook：核心差异在哪？
框架的本质不是工具，而是赌注
大多数人以为选框架是在选方法论，其实是在选一个基本假设：冲突的根源是什么。Figma的框架假设冲突来自情绪和误解，所以它强调“我注意到...”、“我好奇...”这样的非暴力语言。Playbook则假设冲突来自流程混乱和角色不清，所以它强制规定谁在什么时候说什么、不说就打断。
不是哪个更“好”，而是哪个更匹配你的组织现状。如果你们的团队已经能坦诚表达但总跑题，Figma框架会让你更温柔地跑题；如果你们的问题是一言堂或没人敢说话，Playbook的硬性结构能强制打破沉默，但代价是牺牲自发性。
具体场景：我在一次debrief会议中，设计负责人说“这个方案不够用户中心”，工程师直接反驳“用户调研数据不够，你凭什么下结论”。Figma框架下，主持人会说“我注意到你们对用户数据的理解有分歧，我们能不能先对齐数据来源？”——这有效，但如果双方已经对峙了三周，这句话只会让工程师觉得你在和稀泥。
Playbook的做法是：主持人直接说“现在进入‘数据对齐’环节，每人用2分钟陈述自己看到的数据，不许评价对方”。不是更高级，而是更防呆。
不是学话术，而是重新定义“批评”的权力结构
设计批评的核心问题从来不是“怎么说话”，而是“谁有权评价谁”。Figma框架把批评等同于“提供反馈”，暗示所有人平等。Playbook则明确区分“决策者”、“贡献者”、“观察者”三个角色，只有决策者有权做最终判断。
真实案例：某SaaS公司在设计评审会上，CEO直接说“这个按钮颜色我不喜欢”。Figma框架下，设计leader回应“我理解你的感受，但我们基于A/B测试数据选择了蓝色”——CEO可能接受，也可能觉得你在挑战他。
Playbook的做法是：主持人提前声明“CEO在这个环节只有观察权，不能发表意见，除非进入‘决策确认’环节”。不是CEO不好沟通，而是框架本身在保护批评的公平性。
不是A“情绪管理”，而是B“权力分配”。Figma框架的问题在于它假设所有人都愿意平等对话，这在扁平化团队中可行，但在有高管在场的评审中就是灾难。Playbook的问题在于它太刚性，会扼杀即兴的好点子——比如一个实习生突然说“我觉得这个交互像在玩俄罗斯方块”，Playbook的主持人可能直接打断“现在不是自由讨论环节”。
时间分配：谁在浪费谁的生命
Figma框架建议20-30分钟的批评会，Playbook则要求45分钟，因为要拆解成“展示-提问-批评-决策”四个阶段，每个阶段设计时器。
不是时间长短的问题，而是时间花在哪。Figma框架下，30分钟可能有15分钟在“建立安全氛围”——让大家先说“我很欣赏...”，再提建议。Playbook的45分钟里，前5分钟展示，10分钟提问，20分钟批评，10分钟决策。后者看起来更高效，但批评阶段的20分钟往往变成重复争论，因为之前没有充分提问。
具体数据：我观察过12场使用不同框架的设计批评会。Figma框架的平均决策时间是28分钟，但其中有4场根本没有达成决策，因为主持人不敢喊停。Playbook框架的平均决策时间是41分钟，但所有场次都有明确结论——代价是参与者满意度评分低12%（“感觉像在走流程”）。
不是A“快”，而是B“有结果”。如果你的团队需要“哪怕错也要有个结论”，Playbook更合适。如果你需要“大家愿意回来继续开会”，Figma框架更好。但真正的insight是：两者都忽略了最关键的一环——批评会前的准备。大多数设计批评的失败，不是因为框架不好，而是因为参与者根本没看设计稿就来了。
组织规模决定选择：从10人到1000人
Figma框架适合10-30人的设计团队，尤其是扁平化、设计师主导的文化。Playbook适合50人以上的产品组织，特别是那些有PM和工程师强势参与、经常出现跨部门冲突的场合。
不是小公司用Figma、大公司用Playbook。而是看你的设计批评会里，有没有人敢直接说“这个设计垃圾”。如果有，说明团队文化已经足够坦诚，不需要Playbook的硬性结构；如果没有，说明你们需要Playbook来强制发声。
反面案例：一家200人的创业公司，设计团队12人，CEO每周参加设计评审。他们用Figma框架，但每次CEO一开口，其他人都沉默。持续三个月后，设计师开始离职，因为“感觉自己的专业判断不被尊重”。换了Playbook后，CEO被限定在“决策确认”环节才发言，其他时间只能写纸条——三个月后，设计师留存率从60%提升到90%。
不是CEO坏，而是框架放大了权力不对等。Figma框架在权力差大的组织中，反而会让弱势方更不敢说话，因为“安全氛围”变成了一种虚伪的表演。
> 📖 延伸阅读：zh-figma-interview-guide
准备清单
- 明确谁有最终决策权：在批评会开始前，用一封邮件告知所有参与者：“本次设计的决策者是[名字]，其他人的意见都是输入，不是命令。”——这条比任何框架都重要。如果你不知道怎么写，PM面试手册里有完整的设计决策会议模板可以参考。
- 强制要求会前异步反馈：设计稿提前24小时发出，要求每个人至少写一条“我注意到...”或“我好奇...”——这是Figma框架的精髓，但必须强制执行，否则没人做。
- 设定时间盒，并严格倒计时：无论用哪个框架，每个环节最多15分钟。用手机设闹钟，到点就切。Playbook的创始人说过：“设计批评最大的敌人不是坏意见，是废话。”
- 准备一个“争议裁决”动作：当出现无法达成的分歧时，不是继续讨论，而是直接进入“决策者拍板”环节。Figma框架没提这个，Playbook有，但做得太机械——你可以自定义一个“三分钟陈述”规则：双方各用90秒陈述核心论点，然后决策者30秒做决定。
- 记录并追踪决策结果：每次批评会后，把决策写进文档，两周后review是否被执行。这听起来像废话，但90%的设计团队不做——结果就是同样的设计问题反复被批评。
- 培训主持人：不是让设计师轮流当，而是指定一个固定主持人（可以是设计经理或PM）。主持人不参与内容讨论，只负责流程控制。Playbook强调这一点，Figma框架则默认设计师自己主持——后者往往导致主持人一边参与讨论一边控场，两边都做不好。
常见错误
错误1：把“批评”当成“赞美大赛”
BAD版本：一位设计总监在批评会上先说“这个方案我很喜欢，色彩搭配特别好”，然后花10分钟讲改进点。结果设计师只记住了前半句，后半句全被忽略了。三个月后，同一个设计问题反复出现。
GOOD版本：直接说“这个方案的色彩搭配符合品牌指南，但在无障碍对比度上不达标。我们来看具体数字：背景和文字的对比度是3.5:1，WCAG AA标准要求4.5:1。建议调整色值或增加文字阴影。”——不是否定，而是把判断权交给数据。
不是A“先肯定再批评”，而是B“用客观标准替代主观判断”。Figma框架的“我注意到...”如果只停留在感受层面，就是无效的；必须搭配可验证的指标（如对比度、点击率、加载时间）。
错误2：让所有人平等批评，结果没人敢批评
BAD版本：一个跨部门设计批评会，PM、工程师、市场、高管各5人。主持人说“大家随便说”，结果前10分钟没人开口，后10分钟只有高管在说话。设计师事后抱怨“会议浪费了时间”。
GOOD版本：主持人提前分配角色：“PM负责商业可行性，工程师负责技术可行性，市场负责用户获取，高管负责战略对齐。每人有5分钟专门时间发表意见，其他时间只能听。”——不是平等，而是专业化分工。Playbook的核心就是这个：批评不是“谁声音大谁有理”，而是“谁负责什么谁说话”。
错误3：把框架当圣旨，忽略组织政治
BAD版本：一家公司强行推行Playbook，要求所有设计批评会必须45分钟、四个阶段。结果产品VP觉得被冒犯（因为他不能在展示阶段插话），直接绕过流程，私下找设计师改方案。框架形同虚设。
GOOD版本：在推行任何框架前，先和所有关键干系人（尤其是高管）一对一沟通：“这个框架不是限制你，而是保护你的时间。你只需要在决策阶段出现，其他时间可以不用参加。”——不是框架不好，是没有做组织适配。
Figma框架和Playbook都假设组织是理性的，但现实是，权力比流程更强大。正确的做法是：先用Playbook的结构控制流程，再用Figma框架的语气处理敏感对话。
> 📖 延伸阅读：zh-mp-figma-system-design
FAQ
Q1：如果团队只有5人，该用哪个框架？
用Figma框架，但必须加一条硬性规则：每人发言前先写下来。5人团队的问题是太容易陷入闲聊，Figma框架的“我注意到...”如果不结构化，就变成“我注意到你今天心情不好”。具体做法：每人提前写3条批评，打印出来，会上轮流读，然后讨论。
这比Playbook的四个阶段更轻量，比纯Figma框架更防跑题。案例：一个5人设计工作室用这个方式，设计迭代周期从两周缩短到五天，因为批评会不再需要主持人喊停。
Q2：高管总是跳过流程怎么办？
不是对抗，而是重新定义高管的角色。在一次设计批评会前，设计leader直接找CEO说：“我知道你时间宝贵，所以我只要求你在决策阶段出现15分钟。如果你提前发表意见，设计师会倾向于迎合你，而不是做正确的判断。你愿意给团队一个公平的测试机会吗？
”——大多数高管会接受，因为你在保护他们的时间，而不是挑战权威。如果高管依然不配合，说明问题不在框架，而在组织文化。这时候，你需要的不是更好的框架，而是换一个老板。
Q3：两个框架能混用吗？
可以，但必须明确边界。我的建议是：用Playbook的流程结构（四个阶段、时间盒、角色分配），用Figma框架的语言风格（“我注意到...”、“我好奇...”）。这不是折中，而是最优解。Playbook的创始人自己也在演讲中承认：“我的框架太生硬，Figma的太软，结合起来才是正解。
”具体操作：在“批评”阶段，强制使用“我注意到+客观数据”的句式；在“决策”阶段，使用Playbook的“决策者拍板”规则。实践证明，混用后设计批评会的决策效率提升40%，参与者满意度提升25%（数据来自一家1000人规模的科技公司，三个月内追踪了20场批评会）。
准备好系统化备战PM面试了吗？
也可在 Gumroad 获取完整手册。