Figma 设计简报技能

将产品需求或功能请求转化为结构化的设计简报——让设计师打开 Figma 后能够自信地开始构建。

必需输入

• 功能或需求（粘贴 PRD 摘要、工单内容，或描述该功能）
• 用户目标（用户试图完成什么？）
• 平台（iOS / Android / Web / 响应式 / 全平台）
• 现有可用组件（可选）
• 时间安排（设计需在何时完成？）

输出结构

1. 简报标题

功能名称、产品经理、设计师、平台、设计完成日期、开发交接日期。

2. 我们正在设计什么以及原因

• 目标： [一句话概括 — 解决的用户问题]
• 背景： [2–3 句话。为什么现在需要？由什么触发？]
• 成功标准： [具体可观察的结果]

3. 需要设计的用户流程

流程 N：[流程名称]

• 入口点：[用户从何处开始]
• 步骤：[编号的关键步骤]
• 退出点：[流程结束位置]
• 边界情况：[空状态、错误状态、加载状态]

4. 所需页面

5. 所需组件

6. 限制条件与要求

• 必须包含：[不可妥协的约束条件]
• 必须避免：[禁止使用的设计模式]
• 可访问性：[WCAG 标准等级，触摸目标尺寸]

7. 待澄清问题

• [ ] [问题 — 标注负责人]

质量检查项

• [ ] 目标聚焦于结果（而非“设计这个功能”）
• [ ] 所有流程均包含边界情况
• [ ] 组件表格明确区分创建与复用
• [ ] 限制条件包含可访问性要求
• [ ] 待澄清问题均已指定负责人

反模式

• [ ] 不要编写描述解决方案的设计简报 — 简报应聚焦问题和约束，而非具体设计方案
• [ ] 不要跳过成功标准 — 设计师需要在开始前就清楚“完成”的样子
• [ ] 不要忽略可复用的现有组件 — 忽视设计系统会导致实现不一致
• [ ] 不要留待澄清的问题未解决 — 应在设计工作开始前提出并跟进，而非中途处理
• [ ] 不要将需求与设计指令混淆 — 简报定义“做什么”，而非“怎么做”

示例触发短语

• “为 [功能] 写一份 Figma 设计简报”
• “将这段 PRD 转换为 Figma 设计简报”
• “向设计师说明 [需求] 的设计要点”
• “为 [功能] 在 Figma 中创建一份设计规范”
• “设计师需要了解哪些信息才能开始设计 [功能]？”