Figma Specs：把设计图和「为什么这样做」放在一起
Figma Specs 是放在设计画布上的协作文档。团队可以把需求、界面和讨论放在一起，再把这份说明交给开发者或 AI 使用。
先给出你的方案与理由，再展开思路，检查是否遗漏了重要的取舍与验证。这些问题没有唯一答案。
01
产品思考中阶
怎样区分未决定的问题和已经确认的需求
场景：你在设计一个画布上的需求文档。报名页面旁有三条讨论：「可以加候补吗？」「按钮用绿色」「满员后禁止提交」。其中只有最后一条已被团队确认。
- 你的任务：设计读者如何看出建议、待确认问题和当前决定。不要只靠颜色区分。
- 需要考虑：决定后来改了；设计图已经更新，文字还没改；AI 汇总评论时把建议写成了确定规则。
- 请交付：一份简短的信息布局、两种状态变化的交互，以及交给开发者前的检查方法。
- 验证例子：让新加入的同事回答「满员后会发生什么」。说明怎样发现他读到了过时或未确认的信息。此题是自拟设计，不表示 Figma 已提供专门的审批状态。
查看思路
- 先区分内容的用途。 想法可以保留，但应与当前可执行的决定分开；为决定标出负责人和更新时间，比仅用颜色可靠。
- 把改变呈现为需要确认的差异。 图与文不一致时列出具体冲突，由负责人选择保留哪一项，不要默认最新时间就代表正确。
- 让 AI 汇总保留不确定性。 要求未确认问题仍以问题呈现；让人确认后再进入实现清单。少一层转抄，不应等于少一次判断。
- 检查读者能否据此行动。 给同事新旧材料混在一起的例子，观察他是否找到当前决定和相关画面；记录误解来自状态、位置还是措辞。
02
产品思考中阶
交给 AI 的说明，怎样做到足够而不混乱
场景：一个文件里有三个报名方案、两轮讨论和旧版流程图。现在只准备实现方案 B 的「满员提示」。
- 要解决的问题：让用户选出本次交接材料，既不遗漏关键规则，也不把废弃方案一起当作要求。
- 材料示例：方案 B 画面、满员规则、接口错误列表、方案 A 的旧文案，以及还没决定的候补想法。
- 请设计：选择材料、检查缺项、确认发送范围三个步骤。说明无权限打开某个链接时怎么提示。
- 请交付：一份交接预览及其说明文案，并解释如何检验接收方知道该做什么、什么暂时不做。
查看思路
- 从任务列必要材料。 本次需要满员状态的画面、触发条件和提示；候补探索应明确排除，不能仅因为出现在附近就一起采纳。
- 预览实际可读内容。 展示材料名称、用途和版本信息。链接打不开时标出缺项，不能把「已选择」显示成「已成功读取」。
- 让用户确认范围。 预览中同时写清本次包含和暂不包含的行为，避免接收方扩展任务。
- 用复述验证。 请接收方列出触发条件、预期界面和待确认问题，与确认清单比较。检查是信息完整，不是信息最多。