使用场景

从 Excalidraw 草图到 Figma 原型，再把任务交给 GitHub

先把流程画明白，再把关键界面做成可点击原型，最后用可观察的验收条件交接实现。

资料核对2026-10-22

编辑建议，基于官方文档整理，未逐项实测。页面上的资料核对日期表示本次检查了所列来源，不代表产品测试或持续监测。

所用工具官网

适合产品、设计和开发需要共同澄清一个小功能，但目前只有口头想法或零散截图的团队。

示例：设计一个活动报名流程。参与者浏览活动、查看余位、填写信息、确认提交；组织者需要在名额满时看到明确状态。团队先讨论流程和异常，再决定界面，而不是一上来争论按钮颜色。

在 Excalidraw 画主路径
用方框和箭头标参与者、主路径及“名额已满”“提交失败”等分支。草图便于快速讨论，也可导出 PNG 或 SVG。^[1]
把不确定处写成问题
标注谁能修改报名、重复提交怎么办、满额后是否候补。请相关人定规则；未决项写“待定”，避免把视觉稿误当成决定。
在 Figma 展开关键界面
制作列表、详情、表单和错误等必要画面，再连接主路径原型。此流程用 Figma Design 表达意图；真实数据、权限和工程验证仍需单独评审。其原型功能可连接画板、组件和变量。^[2]
写 GitHub 验收清单
按可独立交付的部分建 issue：有余位且信息有效时显示确认；满额时阻止提交并说明原因；失败时保留输入并给出重试方式。GitHub Issues 可记录、讨论和跟踪工作。^[3]
附上交接材料并确认责任
在 issue 附原型、草图、字段、状态和未决问题，拆分任务并指定负责人及验收人。开发者反馈可行性，设计者更新，双方确认完成标准。

草图能早发现流程缺口；精细原型更适合讨论状态，但更费维护。GitHub 清单帮助追踪完成条件，不能替代技术评估、代码审查或设备测试。开发仍需判断实现方式。

要先做完整的高保真设计吗？

不一定。先用草图确认角色、状态和失败分支，只把待评审路径做成原型。需求仍不清楚时，细化视觉会增加返工。

Figma 原型能直接交付可用代码吗？

原型表达界面意图；真实数据、权限、响应式、无障碍和错误处理仍需工程评审。和开发者一起确定验收条件，再选择代码生成或组件复用流程。