figma-design-critique-pm

Figma 设计评审 — PM 视角技能

此技能专为评审设计的产品经理打造，重点在于设计是否实现了用户目标和业务成果，而非外观是否美观。它不同于涵盖 UX 美学的通用设计评审技能；此技能侧重产品思维。

不太符合你的需求？ 如果你需要检查实现是否忠实于规范，而非评估产品成果，请使用 figma-design-qa。

必需输入

• 设计描述或屏幕摘要
• 用户目标（用户想要完成什么？）
• 业务目标（产品需要实现什么成果？）
• 原始需求（设计原本要实现什么？）
• 关键指标（如果设计奏效，哪些指标会发生变化？）

输出结构

1. PM 评审摘要

重述用户目标和业务目标。 结论： 方向正确 / 大体正确 / 需要重新思考

用一段话总结：从产品角度看哪些方面有效，以及最需要解决的一件事。

2. 目标一致性检查

目标	设计是否支持？	依据
[用户目标]	是/部分/否	[具体观察]
[业务目标]	是/部分/否	[观察]
[关键需求]	是/部分/否	[观察]

3. PM 反馈（以成果为重点）

每项关注点都必须与成果相关。“我不喜欢这个布局”不是 PM 反馈。“这个布局把主要操作放在首屏下方，会降低移动端转化率”才是 PM 反馈。

[关注点] — 高/中/低影响

• 观察：[对设计表现的客观描述]
• 用户影响：[这对用户目标意味着什么]
• 业务影响：[这对指标意味着什么]
• 依据：[研究/数据/类似模式/假设——如实说明]
• 给设计师的问题：[需要探索什么——而不是直接指示]

4. 设计做得好的方面

列出 2–4 项从产品角度看行之有效的具体做法，并提供依据。不要说“配色不错”，而要说“主要 CTA 是最醒目的元素，符合转化目标”。始终包含此部分。

5. 下一轮迭代前的问题

问题	回答者	重要性
[问题]	设计师/PM/Eng	[影响]

6. PM 建议

批准 / 修改后批准（列出修改项） / 修改后重新评审（仅聚焦一个方面）

PM 评审规则

• 反馈理由中绝不提及美学，只关注成果
• “我更喜欢”不算反馈，“用户很可能会”才算反馈
• 先说明哪些方面有效，再说明哪些方面无效
• 先提问，再给指示
• 只给出一项主要建议，不要用项目符号列出一份改版方案

质量检查

• 每项关注点都与用户或业务成果相关
• “有效之处”部分真实且具体
• 包含问题部分（而非只有指示）
• 明确给出 PM 建议
• 如实说明依据

反模式

• 不要评审视觉美学——PM 反馈必须聚焦产品成果、用户目标和业务需求
• 不要在未说明依据的情况下提供反馈——区分观察到的设计事实与对用户行为的假设
• 不要给出“流程感觉很混乱”之类的模糊反馈——每项关注点都必须指明具体的屏幕状态或交互
• 不要忽略有效之处——平衡的评审应明确肯定执行得当的设计决策
• 不要在不了解设计限制的情况下进行评审——评判设计决策前，务必询问技术、时间或资源限制

示例触发语句

• “请从 PM 视角评审这个设计”
• “从产品角度审查这个设计”
• “我对这个 Figma 设计有哪些产品方面的反馈？”
• “请以非设计师的视角评审这个设计”
• “这个设计能实现用户目标吗？”