第1章 原型边界评审概述

1.1 定义与核心目标

原型边界评审（Prototype Boundary Review，PBR）是指在Figma与Confluence协作环境下，对原型设计所覆盖的功能边界、交互流程、视觉规范以及与对接系统（API/后端/数据）的约束条件进行系统性审查的活动。其核心目标是在设计阶段及早发现边界模糊、逻辑遗漏或协作失配，降低返工成本。

1.2 适用场景

• 跨团队协作启动前：当Figma原型需要交付给开发、测试或产品经理时，需评审原型所描述的“边界”是否清晰。
• 新功能/迭代版本发布前：确保原型覆盖所有业务场景，包括异常态和边界值。
• 设计与工程对接点：涉及后端接口、前端组件库、数据模型约束时，评审原型与Confluence中功能文档的一致性。
• 客户/外包验收阶段：作为质量门禁之一，验证原型与需求规格是否对齐。

1.3 前置条件

1.4 操作步骤（宏观流程）

1. 提案与定界：设计师在Confluence中创建“边界评审任务”，标注本次评审覆盖的Figma画板范围。
2. 自检与预评：设计师对照检查清单（如：缺失态、loading态、空态、错误态）进行自查，并将结论记录至Confluence。
3. 同步评审会：团队在线或线下会议，逐屏过Figma原型，同步核对Confluence中的功能描述与约束。
4. 决议与标记：对于争议点，使用Figma评论或Confluence任务标记“待确认/通过/驳回”。
5. 闭环确认：所有标记解决后，设计师更新原型，评审人签章，归档到Confluence基线。

1.5 输入与输出物

1.6 责任边界

• 设计师：提供完整原型，准备自检，修正问题。
• 产品经理：提供需求边界，裁决争议。
• 前端开发：验证原型中前端控件、布局、响应式是否可实现。
• 测试工程师：确认原型中的交互路径覆盖测试用例。
• 技术负责人：判断接口约束与数据流是否合理。

1.7 记录材料

所有评审记录必须沉淀在Confluence空间下的固定页面模板，包含：

• 评审编号、日期、参与人
• 需评审的Figma原型链接（含版本号）
• 每项评审结论（通过/驳回/待讨论）及负责人
• 风险登记表（影响范围、概率、方案）
• 最终签章及归档路径

1.8 异常处理

1.9 验收标准

以下条件全部满足视为评审通过：

1. 所有Figma画板均已过审，无“待讨论”标记；
2. Confluence文档中所有关联接口约束、数据字段已与原型一致；
3. 至少 80% 的评审意见被关闭或解决方案明确；
4. 评审报告已归档至Confluence基线，版本号锁定。