在 Figma 组织中移除成员，通常不会把他参与的团队文件一起删除：共享文件仍可由有权限的同事继续使用，但文件不会自动全部改归管理员所有。草稿则要看所在方案和空间，由管理员接收适用范围内的未分配草稿。正常离职应先盘点文件、完成责任人与权限交接，再按约定时间移除成员；“移出组织”和“删除 Figma 账号”是两个不同动作。
设计负责人最需要确认的是：人离开后，接手人还能否找到、编辑并持续维护正确的文件。团队、文件与协作的基础关系，可在 Figma 团队使用与文件管理专题中查看。交接不要只发一个文件夹链接，还要检查草稿、组件库、评审入口和外部协作者。
先分清移出团队、移出组织和删除账号
| 动作 | 主要作用范围 | 交接时要确认 |
|---|---|---|
| 移出某个团队 | 该团队的成员关系 | 是否还在其他团队，以及是否仍有直接文件权限 |
| 移出组织 | 组织内的团队、文件与资源访问 | 组织文件保留、草稿接收和公司身份系统同步 |
| 删除 Figma 账号 | 账号本身及其关联资源 | 账号不可恢复，必须先处理文件与订阅事项 |
公司离职流程通常需要撤销公司资源访问，不等于要求员工永久删除整个 Figma 账号。外部合作方也可能同时参与其他客户项目，不能把“移除我方组织访客”理解成删除他的全部工作空间。
对 Organization 和 Enterprise 组织，Figma 会保留成员对共享文件的贡献；移除成员后，团队和文件夹可能需要重新分配所有者，文件也不会统一自动转给某位管理员。官方规则见 从 Figma 组织移除成员。能继续编辑与已经完成责任交接，不能画等号。
离职前先做一张“文件在哪里、谁接手”的清单
以一位负责订单系统的设计师离职为例：正式订单页面在团队文件夹里，新退货流程还在草稿中，表单组件由他维护，最新评审链接发在项目群里。只把正式订单文件交出去，会漏掉尚未转正的退货流程和后续组件维护。
可以让离职设计师与接手人一起填写下面的记录。文件链接比文件名更重要：同名文件可能分布在个人草稿、团队和恢复副本中。
| 交接对象 | 必须写清的内容 | 确认人 |
|---|---|---|
| 正式设计文件 | 原链接、所在团队与文件夹、当前交付版本 | 业务设计负责人 |
| 工作中草稿 | 用途、完成状态、是否纳入团队、后续位置 | 接手设计师 |
| 组件与资源库 | 主文件、维护人、近期未发布改动、下游使用范围 | 组件维护者 |
| 评审与研发入口 | 正式链接、未解决问题、需要继续执行的结论 | 产品或研发负责人 |
| 团队管理与订阅 | 管理员、付款与账单联系人、身份系统责任人 | 管理员与采购/财务 |
把文件标成“已交接”前，接手人至少要做一次真实操作：打开文件，找到一项指定设计，确认可以按职责编辑或查看，并知道主组件在哪里。不要只检查管理员账号，因为它可能拥有普通接手人没有的访问能力。
如果涉及客户资料或未公开业务，交接记录保持在公司批准的位置。没有必要把设计文件设置成公开链接来证明“大家都能打开”；应验证指定接手人的权限。
移交所有权后，还要确认文件位置和原成员权限
文件所有权、文件位置、访问权限是三件事。转移所有权不会自动把个人草稿移动到团队，也不会自动撤掉原所有者的访问权限。对于仍在草稿里的退货流程，先确定团队接收位置，再由当前所有者完成对应交接；不能只换一个所有者名称就结束。
在 Figma 文件的 Share 面板中，当前所有者可以找到已加入的协作者，将其角色改为 Owner，并确认 Transfer ownership。付费方案中，文件所有权转移还受对应产品席位权限影响。接收者未出现在列表时，先邀请正确的账号，不要临时改用私人邮箱绕过公司成员管理。具体规则见 文件与文件夹所有权转移说明。
团队层级也要分方案处理：Starter 和 Professional 团队由管理员管理，没有单独的 Owner 角色；至少要留下一个管理员。Organization、Enterprise 中的团队则有所有者角色，可由当前所有者转给已有团队成员。相关路径见 团队所有权与管理员交接。
对订单项目，接手设计师应负责正式页面，组件维护者负责资源库，管理员负责成员管理，不必把所有角色都集中给同一个人。原付款联系人离职时，账单资料也需另行处理，成员角色变化不会自动完成公司内部付款交接。
成员已经移除，管理员怎样接收草稿？
Professional、Organization 和 Enterprise 方案提供未分配草稿管理。成员移除后，适用范围内的草稿会收集到 Admin 中；Organization、Enterprise 的组织访客草稿也在相应规则范围内。对于个人 Starter 草稿，不应假设公司管理员也能从同一个入口接回。
- 管理员从文件浏览器进入 Admin。
- 打开 Content → Unassigned drafts，按离职成员查找对应草稿文件夹。
- 对照交接清单检查文件用途，先找到退货流程这样的工作中内容。
- 打开单个文件的更多菜单，选择 Move，移到团队的正确文件夹。
- 让接手人从目标位置打开并确认，再更新交接清单中的位置与负责人。
Organization 和 Enterprise 可以把整份未分配草稿文件夹移动到团队；Professional 当前不支持这个整文件夹操作，应逐个移动需要接收的文件。把文件夹移动到团队后，团队成员获得的查看或编辑能力与团队权限有关，接收前应先看目标团队的成员范围。
不要在完成接收前使用 Admin 中的永久删除。未分配草稿文件或文件夹从此处永久删除后不能恢复；也不要把它当成普通回收站清理。需要找已删除的草稿时，可以先查看该管理区域的 Show trashed files。以上入口和限制见 管理已移除用户的草稿。
到离职节点，再完成成员移除与访问检查
常规交接可由设计负责人确认资产，管理员确认账号和权限，按公司约定的离职时间执行撤权。如果属于需要立即限制访问的紧急情况，优先按公司安全流程处理，管理员随后接收资产；不要为了等待本人补齐文件而无限延长其访问。
组织管理员可在 Admin → People 中找到成员，在更多菜单选择 Remove，并阅读确认提示后操作。Enterprise 的工作区或账单组管理员只能管理自己的授权范围；涉及跨工作区资产时，应由具备对应范围的管理员共同完成，而不是假设一个局部管理员能处理全组织。
使用公司 SAML SSO 时，还要与 IT 对齐身份提供方的处理。只在一个系统中改状态，不能代替对完整账号链路的确认。域名捕获、组织成员与访客身份，也会影响移除后能否继续访问组织外空间。因此，交接记录至少要写明使用的公司账号、所移除的组织以及身份系统动作，不只写一句“账号已删”。
- 接手人验证：用其自己的账号打开正式文件、草稿接收位置和组件库。
- 项目负责人验证：研发与评审仍访问正确版本，未完成任务已有新责任人。
- 管理员验证：成员已退出应撤销的范围，临时分享与外部访问已按清单处理。
- IT 验证：公司身份系统中的账号停用、组成员变更与账号预配动作符合预期。
撤销云端访问不能收回已经下载到其他设备的副本。涉及本地交付包、第三方插件或外部服务中的资料，应按公司既有的数据与设备管理流程一并交接，不把 Figma 的成员移除当成全部资产治理。
已经离职才发现缺文件，按这个顺序找
第一步，找原始链接。从需求文档、研发任务和评审记录中定位文件，不凭记忆搜索同名副本。原链接显示无权限时，先核对当前账号和组织，不直接认定文件已被删除。
第二步，查团队和未分配草稿。正式文件与草稿分开查；有编辑权限的人仍可继续维护共享文件，管理员可按方案接收未分配草稿。找到后先放到正确团队位置，再完成责任交接。
第三步，核对真实发生的动作。移除成员、删除文件、删除团队和删除账号需要不同恢复路径。若已经删除账号，按 Figma 账号删除说明检查原方案与资产位置；不要承诺所有草稿都能找回，也不要重新创建一个同名账号来冒充恢复。
第四步，整理支持材料。保留原文件链接、成员公司邮箱、所在组织、发现时间及已尝试的查询路径，由公司管理员联系官方支持。需要共享文件内容时，只授予解决问题所需的范围，避免把整套企业设计库开放出去。
把“离职时找文件”提前变成日常交接
在订单项目完成首次研发交付时，就可以让接手人参与维护一次：通过同一份设计稿找到订单详情、异常状态和主组件，并说明下一轮迭代该改哪个文件。到了正式离职节点，交接只需要确认增量，而不是重新理解整个项目。
使用 Pixso 管理这类项目时，可先把接手者加入对应团队、项目或文件，再由所有者执行 Pixso 所有权移交。订单设计稿与组件资产分别落实接收人，在画布中保留交接范围与未完成事项，完成后再按成员管理流程撤销离职者权限。所有权交接和访问撤销分别确认，才能让文件持续维护与人员离开同时完成。
一份有效的离职交接记录，最后应能回答：正式文件在哪里，谁继续维护，哪些工作未完成，原成员还能访问什么。四个问题都有明确答案，团队才真正接住了设计资产。
