figma-design-review

Figma 设计评审 Skill

执行结构化的 PM 设计评审——检查设计是否符合产品需求、涵盖所有用户流程，并已准备好交付工程团队。这是一次针对需求和结果的评审，而非审美评判。

不太符合你的需求？ 如果需要严格对照规格进行检查，请使用 figma-design-qa。

必需输入

• 设计描述或界面摘要
• 原始需求（PRD 片段、工单或验收标准）
• 正在设计的用户流程
• 评审阶段（概念阶段 / 中保真 / 交付前最终版）

输出结构

1. 评审标题

功能、评审阶段、评审人、日期。 总体状态： 已批准 / 修改后批准 / 需要修改

2. 需求覆盖检查

需求	已覆盖？	备注
[来自 PRD 的需求]	是/否/部分	[具体观察]

未覆盖需求摘要：[尚未处理的需求——批准前必须解决]

3. 用户流程完整性

流程步骤	已设计？	问题
[步骤]	是/否/部分	[问题]
错误状态	是/否
空状态	是/否
加载状态	是/否

4. PM 关注事项

[关注事项] — 阻塞 / 应修复 / 可选修复

• 内容：[具体观察]
• 重要性：[对业务或用户的影响——而非审美偏好]
• 建议解决方案：[PM 希望看到的内容]

5. 待解决问题

问题	负责人	截止日期
[问题]	设计师/Eng/PM	[日期]

6. 批准决定

已批准 / 修改后批准（列出修改项）/ 需要修改（重点领域 + 下次评审日期）

质量检查

• 已评估每项需求
• 已检查所有流程状态（错误、空、加载）
• 关注事项聚焦于结果，而非审美
• 待解决问题均有负责人
• 已明确说明批准状态

反模式

• 不要在没有需求清单可供对照的情况下评审设计——务必先索要 PRD、设计简报或验收标准
• 不要给出含糊的批准状态——必须明确决定为“已批准”“有条件批准”或“未批准”
• 不要混淆需求缺口与 UX 关注事项——应分别跟踪，以便工程师和设计师各自采取行动
• 不要提出关注事项却不说明解决问题所需的信息
• 不要跳过待解决问题——评审时未解决的假设会在工程交付后变成 Bug

示例触发语

• “根据需求评审这个 Figma 设计”
• “对 [功能] 进行 PM 设计评审”
• “检查这个设计是否符合产品规格”
• “这个设计是否已准备好交付工程团队？”
• “在开始构建之前，这个设计还缺少什么？”