从原型图到UI设计稿的交接，应在核心流程、内容层级和必要状态已经明确后开始。交接不是把一组线框图发给UI设计师，而是同步已确认的决策、未定问题、界面状态、业务规则和本轮不处理的范围。
如果需要先分清两类交付物的职责，请查看原型图和UI图的六维区别。本页只解决一个更具体的任务：已有原型如何交给UI设计并组织后续评审。
1. 交接准入条件：先确认哪些内容已稳定
| 检查项 | 可交接标准 | 未通过时的动作 |
|---|---|---|
| 核心任务 | 入口、主路径和成功结果已确认 | 回到原型层继续验证 |
| 内容层级 | 标题、按钮、表单和列表有可靠样本 | 先补关键真实内容 |
| 页面状态 | 正常、空白、加载、错误和权限已列出 | 建立状态清单并标记优先级 |
| 未决问题 | 责任人和最晚确认时间明确 | 不把假设隐藏在UI图中 |
| 本轮范围 | 要设计、保留原型和暂不处理的页面均已标注 | 先锁定范围再安排设计 |
原型不必所有页面都达到同一精细度。已稳定的核心路径可以先进入UI设计，仍在快速变动的分支继续保持低保真。不确定是否应该提高细节时，可根据原型保真度的选择标准进行判断。
2. 产品侧需要交付什么
- 任务说明：目标用户、触发场景、成功条件和业务价值。
- 页面与流程：主路径、必要分支、返回逻辑和终止条件。
- 真实内容：会影响布局的标题、按钮、字段、列表与提示文案。
- 业务规则：输入校验、权限、排序、数据来源和异常处理。
- 范围标记：已确认、待确认、仅示意和不在本轮内的页面。
产品侧不应只交付一条“正常演示”链路。如果异常状态未确定，应明确记录为待决策项，不要由UI设计师根据单个页面推测。
3. UI设计师需要确认和补充什么
UI设计师收到原型后，应先检查内容是否足以支撑视觉决策，而不是立即进入页面精修。需要确认的包括内容优先级、品牌与设计系统、设备范围、响应式规则、可访问性需求和页面状态。
对于原型中没有明确的变动范围，UI设计师可以先制作一个代表性页面和一组核心组件，评审通过后再扩展到其他页面，避免在方向未确认前批量精修。
4. 用三轮评审完成从原型到UI的转换
- 交接评审：产品、UX/UI设计共同走查核心任务，标记遗漏的状态与未决问题。
- 方向评审：只审查代表性页面、信息层级和核心组件，确认视觉方向。
- 完整性评审：对照原型检查页面、分支、组件状态和设计规范，再进入研发交付。
每轮评审要预先说明要做的决定。交接评审不讨论阴影和色彩，方向评审不要被所有边缘页面拖慢，完整性评审则需要逐项回看交付清单。
5. 交付研发前的验收清单
| 验收对象 | 检查标准 |
|---|---|
| 页面范围 | 原型与UI图的页面数量、名称和版本对得上 |
| 主任务 | 入口、操作、反馈和结果在两套交付物中一致 |
| 页面状态 | 正常、加载、空白、错误、成功和权限均有定义 |
| 组件 | 命名、状态、变体和使用边界与设计系统一致 |
| 真实内容 | 关键文案与数据密度足以验证布局 |
| 未决项 | 每个未决问题都有责任人、影响页面和截止时间 |
验收不是比较两套图的像素是否完全相同，而是确认流程决策、内容层级、状态和实现规则没有在转换过程中丢失。
6. 常见返工问题与处理方式
- 真实文案放不下：先确认内容优先级，再调整布局，不要为了保留原型尺寸而随意删减关键信息。
- 业务流程在UI阶段变更：先更新原型和变更说明，再标记受影响的UI页面。
- 组件状态遗漏：用状态矩阵检查字段、按钮、弹窗、列表和导航，不只检查默认状态。
- 两套文件版本不一致：为每轮评审保留版本名称和结论，避免只靠口头同步。
7. 用Pixso组织原型与UI交接
在Pixso中，团队可以通过原型设计与评审确认页面跳转、交互事件和任务路径，再在UI设计协作环节补齐组件、视觉规范与状态。评论应指向具体页面和版本，便于后续追溯。
准备开始实际项目时，可以进入Pixso建立一份可追溯的交接文件，先放入核心任务、状态清单和未决项，再开始UI精修。
交接时必须所有页面都定稿吗？
不必。核心路径可以先交接，但必须明确标出未定分支及其影响范围。
原型改了，UI图怎么同步？
先记录流程或规则变更，再建立受影响页面列表，由产品与UI设计共同确认是否需要重新评审。
