navigating-design-jira-process

产品与设计 Jira 流程指南

本指南依据设计团队当前的实践，说明如何接入工程团队的 Jira 工作流。目标是让设计决策与工程工作并行可见，而不必维护单独的设计跟踪系统。设计直接附加到所属的工程工单上，所有实质性内容（30/60/90 评审迭代、文案、注释）都保存在 Figma 中。

关于下文状态名称的说明。 Jira 状态标签在此处保留 Jira 使用的大小写形式——IN DESIGN、IN PROGRESS、DONE、DESIGN NEEDED、Ready for Dev。转换工单状态时，请原样照用。

结构规则

设计直接附加到工单上。 Figma 文件保存在工程 Epic 的“Design”字段中（对于单独的工程 Story，则保存在该 Story 的“Design”字段中）。没有单独的设计项目、单独的设计看板，也没有按阶段拆分的设计任务。

这句话概括了设计团队使用 Jira 的要点。其他一切都是围绕这一规则进行的协调安排。

Epic 驱动的流程

初始设置

• PM 为其正在处理的每份产品计划文档至少创建一个配套 Epic。
• PM 将 Epic 分配给指定的设计师。

设计中

• 设计师（或 PM）将 Epic 移至 IN DESIGN。
• 设计师在 Figma 中按 30/60/90 的节奏进行评审；每个阶段不单独创建 Jira 任务。各阶段的迭代、附加材料（利益相关方演示文稿、研究）以及跨迭代反馈，都与设计工作一起保存在 Figma 文件中。

设计完成

• 在 Figma 中，将最终设计归到同一个页面，并为每个 Story 级别的设计界面设置命名 Section。
• 设计师在 Epic 的“Design”字段中添加 Figma 文件链接。
• 设计师将 Figma Section 标记为 “Ready for Dev”。
• EM 将 Epic 移至 Ready for Dev，表示工程团队可以接手该工作。（有些团队配置了自动化来处理此步骤；目前请将其视为 EM 的职责。）

工程技术拆分

• 工程团队在技术拆分期间创建 Story 时，设计师、PM 和负责拆分的工程师会一起评审这些 Story。
• 确保每个 Story 都关联到正确的 Figma Section，且该 Section 的内容仅涉及这个 Story。一对一对应。

进行中（及开发支持）

• 开发开始时，PM 或 EM 将 Epic 移至 IN PROGRESS。
• PM/EM 创建一个标题为 [project name] - dev support 的开发支持任务，将其分配给项目设计师，并将其与所有需要设计支持的工程 Story 关联为“relates to”。（即使其他单独设计任务的做法已逐步取消，目前仍沿用此约定。）
• 此任务会告知设计师其项目已进入开发阶段，并代表整个过程中所需的各类支持。
• 最后一项工程任务完成后，开发支持任务也标记为 DONE。

单独的工程 Story

有些 Story 不隶属于 Epic，UI Foundation 团队就经常遇到这种情况。流程较短：

• 在 Epic 之外创建一项工程 Story；PM 或 EM 发现需要设计支持。（或者：负责 UIF 组件改进工作的设计师自行创建该 Story。）
• PM 或 EM 将 Story 移至 DESIGN NEEDED，并分配给功能团队的设计师。
• 设计师在 Figma 中完成设计工作。不创建单独的设计任务。
• 设计完成后，设计师：
  1. 将 Figma 文件链接添加到 Story 的“Design”字段。
  2. 取消将自己分配给该 Story。
  3. 在工单中添加评论，注明设计已准备好，可供接手。

这三个收尾步骤——添加链接、取消分配、添加评论——缺一不可。任何一步遗漏，都会导致 Story 卡在某人的队列中，或虽可见却难以发现。

与其他技能组合

• preparing-design-handoff。 In Design 阶段结束时的过渡步骤（关联 Figma、将版块标记为 Ready for Dev、EM 推进 Epic）是交接流程的前置环节。交接技能是关卡／检查清单；此技能定义了标准生命周期。
• evolving-design-system-components。 组件库工作会在 Component Library board 上生成 Jira issue。这些 issue 遵循相同规则（将设计附加到工单），但由功能团队负责的方案会在功能团队的项目中创建 story，而不是在 Component Library 项目中创建。请向设计师明确说明这一差异。

需要留意的常见错误

• 忘记将 Figma 版块标记为“Ready for Dev”。 工程团队无法找到最终稿。这是 Design Done 的一部分，不是可选项。
• 版块与 story 未对应。 工程团队创建 story 时，每个 story 都应对应一个 Figma 版块，且该版块的内容应_仅_包含该 story。对应不一致会导致评审时产生歧义。
• 一次性工程 story 在设计结束时仍未完成。 必须完成全部三个收尾步骤 — 将 Figma 链接到 story 的“Design”字段、取消指派自己、发表评论说明设计已就绪。漏掉任何一步都会让工单状态含糊不清。
• PM 太晚创建开发支持任务，或根本没有创建。 如果 Epic 上看不到开发支持，开发支持请求就会毫无预警地落到设计师头上。检查项目的 Jira 状态时，请指出这一缺漏。

输出格式

当被要求设置 Jira 流程或推进工作时：

1. 项目类型 — 这是由 Epic 驱动的项目，还是一次性工程 story？
2. 当前状态 — 存在哪些 Jira 实体（Epic、story、开发支持任务），以及它们当前的状态。
3. 需要执行的操作 — 要进行的具体状态转换和要应用的 Figma 链接，并注明负责人（设计师、PM、EM）。
4. Figma 链接 — 要将哪些内容附加到哪里（Epic 的“Design”字段、story 的“Design”字段）。
5. 注意事项 — 上述哪些常见错误适用于此项目。