figma-design-brief

Figma 设计简报技能

将产品需求或功能请求转化为结构化的设计简报——为设计师提供所需的一切信息，让他们可以放心地打开 Figma 并开始设计。

不太符合这个场景？ 如果设计已经完成，需要对照规格进行检查，请使用 figma-design-qa。

必需输入

• 功能或需求（粘贴 PRD 片段、工单，或描述该功能）
• 用户目标（用户想要完成什么？）
• 平台（iOS / Android / Web / Responsive / All）
• 现有可用组件（可选）
• 时间线（设计需要何时就绪？）

程序化辅助工具

对比度无法靠目测判断。AA 标准线为 4.5:1，白色背景上的 #777777 对比度为 4.478（不通过），而 #767676 为 4.54（通过）——无论怎么看 截图，都无法分辨两者。请计算：

npx --yes notugly fix "#8ab4f8" "#ffffff"     # ratio, APCA, and the nearest passing colour
npx --yes notugly onepager <url> --out review.html   # every pairing, printable
npx --yes notugly vision                      # which colours merge for colour-blind viewers

notugly fix 会返回对比度、APCA 亮度对比度，以及与已选颜色最接近且 符合要求的颜色——色相相同，彩度相同。请将这些数值填入下方表格，而 不要自行估算。

结果确定、零依赖，且不会调用模型——因此运行无需花费，并且每次 都会得到相同的答案。

如果简报指定了颜色，请说明每组预期文本与背景搭配的实测对比度。简报 中指定无法达到的搭配，会在大家发现之前白白浪费一个设计周期。

输出结构

1. 简报标题

功能、PM、设计师、平台、设计截止日期、开发交接日期。

2. 我们要设计什么，以及为什么

• 目标： [用一句话说明要解决的用户问题]
• 背景： [用 2-3 句话说明为什么是现在？是什么触发了这项需求？]
• 成功的表现： [具体、可观察的结果]

3. 要设计的用户流程

流程 N：[流程名称]

• 入口点：[用户从哪里开始]
• 步骤：[编号列出关键步骤]
• 退出点：[流程在哪里结束]
• 边缘情况：[空状态、错误状态、加载状态]

4. 所需界面

界面	新增 / 更新	备注
[界面]	新增	[关键要求]

5. 所需组件

组件	在组件库中？	操作
[组件]	是/否/需要变体	使用/创建/扩展

6. 约束和要求

• 必须满足：[不可妥协的约束]
• 必须避免：[不应使用的设计模式]
• 无障碍：[WCAG 等级、触控目标尺寸]

7. 未解决的问题

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

质量检查

• 目标关注结果（而非“设计此功能”）
• 所有流程都包含边缘情况
• 组件表明确区分新建与复用
• 约束包含无障碍要求
• 未解决的问题均有负责人

反模式

• 不要在设计简报中描述解决方案——简报必须描述问题和约束，而不是设计答案
• 不要跳过成功标准——设计师在开始前需要知道什么才算“完成”
• 不要遗漏可复用的现有组件——忽视设计系统的简报会导致实现不一致
• 不要让未解决的问题悬而未决——应在设计工作开始前升级处理，而不是等到设计过程中
• 不要混淆需求与设计指示——简报定义的是做什么，而不是怎么做

示例触发短语

• “为 [功能] 编写设计简报”
• “将这份 PRD 转换为 Figma 设计简报”
• “向设计师说明 [需求] 的构建内容”
• “为 Figma 创建 [功能] 的设计规格”
• “设计 [功能] 时，设计师需要了解什么？”