UI设计外包验收，先用甲方账号打开可编辑源文件，再检查页面与状态、组件依赖、字体素材和访问权限。效果图好看，只能说明视觉方向得到认可；能独立修改一个字段、复用一个组件、继续维护一个流程，才说明成果真正接到了手里。把未通过项写成“对象、问题、负责人、修复期限”，修好后针对同一对象复验，不以“已发网盘”代替签收。
外包团队如果参与长期迭代，可以从项目开始就把成果放进甲方可管理的协作空间。Pixso企业版的团队协作与资产管理适合用于集中维护设计文件、资源与成员权限；具体交接时，仍需要甲乙双方逐项确认文件归属和可操作范围。
先把“交了多少页”换成“接手后能完成什么”
以一个企业采购门户为例：外包范围包括采购申请、审批列表、申请详情、供应商档案和移动端审批。甲方最终要接手的是可维护的设计，而不是若干张展示截图。验收前，先把需求中的每个页面映射到源文件中的确定位置，写明设备尺寸、角色和关键状态。
例如“审批详情完成”至少要回答：审批人能看到什么、申请人能否撤回、已拒绝如何显示、附件加载失败怎么办。是否包含这些状态，先以双方确认的范围为准；未约定的新增需求应另列，不能临到结项才把所有新想法算成漏交。反过来，已经确认的失败状态也不能因为视觉稿不够漂亮就被省略。
| 任务 | 应找到的成果 | 甲方当场完成的动作 |
|---|---|---|
| 提交采购申请 | 表单、必填提示、提交成功与失败状态 | 定位字段说明和错误提示，确认设计不是只有一个正常页面 |
| 审批一条申请 | 待处理、通过、拒绝与无权限状态 | 沿原型走完批准及拒绝两条路径 |
| 维护供应商资料 | 列表、详情、编辑与空内容状态 | 替换一组测试资料，检查长名称、空值和布局 |
| 调整整站按钮 | 按钮组件、状态和使用说明 | 在验收副本中修改组件并检查代表性页面 |
这张映射表比“共交付多少张图”更重要。同一个页面拆成多个画板，不应自动增加成果量；一个画板包含多个复杂状态，也不能简单算作只交了一页。
用甲方账号做一次“改得动”的验证
不要让供应商分享屏幕演示完就结束。由接手设计师在甲方环境打开文件，确认自己能进入对应项目、编辑必要对象，并找到最终版本。测试使用副本或约定的验收区，避免误改已经投入研发的基线。
- 改文字。把申请单标题改成长一些的名称，检查文字是否可编辑、字体是否缺失、容器是否合理换行。整张图片或大量不可编辑路径，不能当作可维护的UI源文件。
- 改内容。将供应商名称换成较长名称，给联系人留空，替换一个头像或附件图标。观察内容变化是否暴露遮挡、截断和固定高度问题。
- 改组件。在副本中更改按钮的一个视觉属性，查看页面实例能否按预期跟随。若实例全部脱离组件，需要明确这是有意保留的特例还是交付缺陷。
- 找依据。从审批详情回到对应需求或交互说明，能确定这一版为何与旧版不同。不要只剩“最终版”“最终版2”“真的最终版”三个无法判断的文件。
跨工具交付要额外做一次实际导入：查看字体、组件关系、图层、约束和原型连线，而不是用“支持这个文件格式”推断所有能力都能完整保留。若转换结果不满足后续维护，保留原生源文件，并把转换后的可编辑范围写进签收记录。
组件看得到，还要确认离开供应商账号后用得了
采购门户的表单和按钮可能引用供应商自己的公共库。验收时页面看起来正常，不代表之后还能发布更新或补做页面。接手方应列出库名称、管理主体、使用文件和后续维护人，并在甲方环境验证新页面能否调用需要的组件。
把“采购申请表单”和“审批状态”放到同一个验收画布，旁边保留组件来源说明与待办评论。接手设计师分别修改字段名称、切换状态、替换图标；组件负责人记录哪些实例保持关联、哪些已独立处理。这样能把抽象的“组件交付完整”变成可以逐项确认的动作。
如发现依赖供应商控制的组件库，不要急着一键解除所有实例：那样可能让文件暂时独立，却丢掉后续统一维护的能力。先选择交接库管理、迁入甲方资源空间，或重新建立受控组件等可实施路径，再复查引用关系。使用现有品牌组件时，也要区分哪些来自甲方原有资产，哪些属于本次新增成果。
字体和素材交付，不是把所有文件打包给甲方
为字体、图标、图片和插画各留一条来源记录：名称、版本或下载日期、提供方、使用位置，以及相应授权材料由谁保存。能在设计稿中显示，不等于可以把原始字体安装到服务器，也不等于可以随项目转交所有素材文件。
以Adobe Fonts为例，其字体许可说明区分了接收静态成果与继续编辑并使用字体：客户如果需要直接使用字体进行编辑，需要自己的相应许可；字体文件也不能直接随设计打包转交。其他字体和素材应检查各自条款，不能套用这一个例子的规则。
对于采购门户，正文中文字体、金额数字字体、供应商Logo和空状态插画应分别登记。若一项材料缺少可确认的使用依据，先更换为已批准的资产或暂停该项接收，不让“后面再找授权”变成无人负责的遗留问题。合同中的权利归属和使用范围由负责人员确认；设计验收负责把素材和证据对应起来。
把视觉问题、流程缺口和资产风险分开处理
一张长问题清单容易陷入“到底算不算做完”的争论。对同一采购门户，可以按后续工作是否被阻断来分类，不用把所有问题都叫紧急。
- 无法接手：文件打不开、主要页面只有图片、必要权限未交、关键组件由无法联系的外部账号控制。这些问题会阻断维护，应先修复再接收对应成果。
- 无法实现完整流程：已经约定的审批拒绝路径缺失、提交失败状态没有说明、角色差异矛盾。写明影响的需求编号与状态，再确认修复范围。
- 可以继续但需要修正：局部图层命名混乱、少量间距不一致、个别说明遗漏。记录明确对象与截止时间，不用一句“优化细节”结案。
每个缺陷至少附文件位置、期望结果、实际结果和截图或评论入口。修复后由原验收人回到同一位置确认；如果修改了公共组件，抽查所有受影响的代表性页面，而不是只关闭最初的一条评论。
用一张签收表锁定版本、遗留项和责任人
下面的表可以直接复制进项目文档。结果栏填“通过、待修、范围外”，不要只有一个无法解释的勾号；签收日期对应明确的版本基线。
| 签收项 | 需要填写 | 验收证据 |
|---|---|---|
| 成果范围 | 页面与状态清单、约定需求编号、排除项 | 需求到源文件位置的映射 |
| 版本基线 | 文件地址、版本标识、交付时间、提供人 | 定稿记录与预览 |
| 可编辑性 | 测试账号、接收环境、发现的限制 | 改字、替图、组件操作结果 |
| 外部依赖 | 组件库、字体、素材来源和维护主体 | 来源记录与授权材料存放位置 |
| 权限与归属 | 甲方负责人、外部协作范围、结束日期 | 甲方独立访问及维护结果 |
| 遗留问题 | 问题对象、责任人、修复期限、复验人 | 问题记录与关闭依据 |
| 接收结论 | 通过范围、未接收范围、甲乙双方确认人 | 签收时间与确认记录 |
最后再做撤权，而不是交付开始就删账号
先确认甲方拥有需要的文件、组件和说明，再调整供应商的访问范围。仍在保修或补交期的成员，只保留完成约定任务所需的权限；验收结束后检查共享链接、外部协作者和相关集成，避免只删一个成员却留下另一条访问路径。
撤销在线访问不能收回对方此前下载或导出的副本。保密与留存要求应通过已确认的约定和相应流程处理，不把平台权限按钮当作远程删除保证。甲方也应记录谁接替日常维护，避免项目负责人离岗后又形成新的资产孤岛。
外包结项之后，研发还需要依据同一基线进行实现；涉及标注、资源和设计变更的交付，可继续参照设计稿向研发交付的方法。这时项目的状态应是“甲方可以继续维护和迭代”，而不仅是“供应商已经发完文件”。
