第3章 评审材料准备清单

原型评审会不是一次「看图说话」式的随意讨论，而是一次基于完整信息输入的集体决策。如果评审材料不齐全、版本不一致或信息缺失，评审会就会变成需求澄清会或技术调研会，完全失去「评审」的意义。因此，在评审会召开之前，必须系统性地收集、整理和核对以下五类核心材料，确保各方基于完整、一致的信息进行评审。

评审材料五维结构图 评审材料包 原型文件 交互说明 用户场景 业务需求文档 技术约束文档 五类材料缺一不可，版本号必须全局对齐

3.1 适用场景

本章流程适用于以下具体场景，只要满足其中任意一项，即应启动材料准备工作：

  • 计划内评审会：项目里程碑节点（如需求评审、交互评审、视觉评审）前 2～3 个工作日。
  • 临时加开评审：因重大需求变更或技术方案调整需要跨角色紧急决策时。
  • 外部交付评审：向客户、合作伙伴或监管方交付原型方案前的正式评审。
  • 阶段复盘评审：对已上线功能的迭代优化方案进行集体评审。
💡 判断信号：当会议邀请中包含了「原型评审」「设计评审」「方案评审」等关键词时，默认需要执行本材料准备流程。

3.2 前置条件

在开始准备评审材料之前，必须确认以下条件全部满足，否则材料准备将缺乏基础依据：

  1. 原型设计已至少完成一轮内部自审，无重大逻辑遗漏或视觉硬伤。
  2. 业务需求文档（BRD / PRD）已形成结构化初稿，且经过产品负责人确认。
  3. 技术负责人已完成初步技术可行性评估，形成了技术约束的书面记录。
  4. 所有参与材料准备的角色（设计师、产品经理、技术负责人）已明确各自的任务分工。
⚠️ 硬性门槛：前置条件未全部满足时，强行准备材料会导致后续评审中反复修改、信息不一致。建议先补齐条件，再启动本流程。

3.3 操作步骤

按照以下 5 个步骤依次执行，每个步骤完成后需在核对表中打勾确认。

步骤 1：收集原型文件

从设计团队获取最新版原型文件，并导出可离线查看的格式。注意核对文件命名规范和版本号。

  • 确认文件格式为可评审格式（Figma / Sketch / Axure 源文件 + HTML 可交互导出 或 PDF 标注稿）。
  • 检查命名规范：项目名_原型_v版本号_YYYYMMDD，例如 商城App_原型_v2.3_20250610。
  • 导出离线包，避免评审时因网络问题无法打开。

典型的原型文件目录结构示例：

market_app/
├── prototypes/
│   ├── v2.2/
│   │   ├── home.fig
│   │   ├── search.fig
│   │   └── cart.fig
│   └── v2.3/
│       ├── home.fig
│       ├── search.fig
│       ├── cart.fig
│       └── checkout.fig
└── exports/
    ├── market_app_v2.3.html
    └── market_app_v2.3.pdf

步骤 2：编制交互说明文档

为每个页面和关键组件编写交互说明，确保评审时所有参与者都能理解操作逻辑。

  • 触发方式：点击、长按、悬停、滑动、键盘快捷键等。
  • 状态转换：默认态 → 加载态 → 空态 → 错误态 → 正常态，每个转换标明触发条件。
  • 动效参数：时长（ms）、缓动曲线（ease-in / ease-out）、位移距离。
  • 手势操作：移动端特有的左滑删除、下拉刷新、长按拖拽等。

步骤 3：梳理用户场景

按优先级整理用户在真实环境下的使用路径，分为主场景、次场景和边缘场景。

  • 主场景：典型用户完成核心任务的完整路径（如「新用户注册 → 浏览商品 → 下单支付」）。
  • 次场景：非典型用户或扩展功能路径（如「老用户使用优惠券下单」）。
  • 边缘场景：异常操作、网络中断、数据为空、超长文本、快速连击等。
  • 每个场景需标明：前置条件、操作步骤、预期结果。

步骤 4：整合业务需求文档

将业务需求文档（BRD / PRD）按功能模块结构化整理，标注优先级和需求来源。

  • 功能需求清单：模块 → 功能点 → 描述 → 优先级（P0/P1/P2）。
  • 非功能需求：性能指标（响应时间 < 2s）、安全要求（HTTPS、数据脱敏）、兼容性要求。
  • 需求来源：用户调研 / 竞品分析 / 业务方提出 / 监管合规，便于评审时追溯。

步骤 5：汇总技术约束文档

由技术负责人提供书面技术约束，包括技术栈、性能指标和平台兼容性等信息。

  • 技术栈限制：前端框架、后端语言、数据库版本、第三方 SDK 版本。
  • 性能指标：页面加载时间、API 响应时间、最大并发用户数、数据存储上限。
  • 平台兼容性：支持的浏览器（Chrome 90+ / Safari 15+）、移动操作系统（iOS 14+ / Android 11+）。
  • 第三方依赖：地图服务、支付网关、推送服务的 API 限制与许可要求。

技术约束文档的典型结构示例：

{
  "techStack": {
    "frontend": "React 18 + TypeScript",
    "backend": "Go 1.21 + Gin",
    "database": "PostgreSQL 15",
    "cache": "Redis 7"
  },
  "performance": {
    "pageLoad": "< 2s (FCP)",
    "apiResponse": "< 500ms (P95)",
    "concurrentUsers": "≥ 1000"
  },
  "platform": {
    "browsers": ["Chrome 90+", "Safari 15+", "Edge 90+"],
    "mobile": ["iOS 14+", "Android 11+"],
    "miniProgram": ["微信 8.0+"]
  },
  "thirdParty": {
    "mapService": "高德地图 JS API v2.0",
    "payment": "支付宝 / 微信支付 标准版",
    "push": "极光推送 SDK v4.0"
  }
}
📌 关键检查点：每完成一个步骤，立即在核对表中打勾，避免遗漏。建议按照「步骤 1 → 2 → 3 → 4 → 5」的固定顺序执行，不要跳跃。

3.4 输入输出物

类别 输入物 输出物
原型文件 设计稿源文件（.fig / .sketch / .rp） HTML 离线包 + PDF 标注稿
交互说明 设计稿中的交互备注 / 口头约定 结构化交互说明文档（.md / .confluence）
用户场景 用户调研记录 / 产品需求文档 用户场景清单（主场景 + 次场景 + 边缘场景）
业务需求文档 BRD / PRD 初稿 功能需求清单 + 非功能需求 + 需求来源追溯表
技术约束文档 技术可行性评估记录 技术约束清单（JSON / 文档）

3.5 责任边界

五类材料的准备涉及三个核心角色，职责划分如下表所示。跨角色协作时，以「谁输出、谁负责」为原则。

角色 负责材料 交付物 核对人
产品经理 业务需求文档、用户场景 功能需求清单、场景描述文档 业务负责人
交互 / UI 设计师 原型文件、交互说明 可交互原型、交互说明文档 设计负责人
技术负责人 技术约束文档 技术约束清单、平台兼容性矩阵 架构师 / 技术总监
⚠️ 常见责任模糊点：用户场景文档经常出现产品经理和设计师「双不管」的情况。建议在项目启动阶段就明确：产品经理负责场景的业务逻辑，设计师负责场景的界面适配，双方联合签字确认。

3.6 记录材料

材料准备过程中，必须填写《评审材料准备清单核对表》，作为评审会前的交付凭证。该表格由产品经理统一维护，并在评审会前 1 个工作日发给所有参会者。

序号 材料类别 具体内容 责任人 状态 备注
1 原型文件 HTML 离线包 + PDF 标注稿，版本 v2.3 设计师 ✅ 已就绪 2025-06-10 导出
2 交互说明 包含主页、搜索、购物车、结算四页交互说明 设计师 ✅ 已就绪 与原型版本一致
3 用户场景 主场景 3 个 + 次场景 2 个 + 边缘场景 4 个 产品经理 ✅ 已就绪 场景清单已结构化
4 业务需求文档 功能需求 24 项（P0:12 / P1:8 / P2:4） 产品经理 ✅ 已就绪 需求来源可追溯
5 技术约束文档 技术栈、性能指标、平台兼容性、第三方依赖 技术负责人 ✅ 已就绪 JSON 格式已提交
💡 建议：核对表使用在线协作文档（如飞书、Confluence）维护，责任人自行更新状态，产品经理只做最终审核，减少沟通成本。

3.7 异常处理

材料准备过程中可能遇到以下异常情况，请按对应的处理方案操作：

异常类型 具体现象 处理方式
材料缺失 某类材料完全未准备（如缺少交互说明） 立即通知责任人加急补交，同时评估是否延期评审；若无法补交，需在评审会前 24h 书面告知所有参会者缺失内容及影响。
版本不一致 原型文件版本为 v2.3，但交互说明仍为 v2.2 以原型文件版本为准，要求交互说明在 4h 内完成版本对齐；未对齐前，评审材料包标注为「待对齐」状态。
文档格式不兼容 技术约束文档为 .docx，但团队统一要求 .md 或 .json 要求技术负责人按统一模板重新输出，同时保留原格式作为附件备查。
责任人失联 某项材料的负责人在准备期间无法联系 上升至项目经理或团队负责人，指定临时替代人完成材料准备；并在团队周报中记录该风险。
📌 异常升级原则：单个材料缺失且无法在 24h 内补全时，建议推迟评审会，避免因信息不全导致评审结论无效。不要为了「按时开会」而牺牲评审质量。

3.8 验收标准

评审材料包通过验收必须同时满足以下所有条件，任何一项不满足则材料包视为「未就绪」：

  1. 完整性：五类材料（原型文件、交互说明、用户场景、业务需求文档、技术约束文档）全部就位，无缺失。
  2. 版本一致性：所有材料的版本号统一，且与最终确认的版本一致（可通过版本号或提交时间戳交叉校验）。
  3. 格式合规：每类材料均符合团队约定的格式（原型 → HTML+PDF，文档 → .md/.json/.confluence）。
  4. 可评审性：原型可交互打开、交互逻辑可追踪、用户场景可理解、需求与技术约束可对应。
  5. 签字确认：产品经理、设计师、技术负责人三方在核对表上签字（或在线确认），表示对各自交付物负责。
💡 验收完成后：将评审材料包打包为统一文件夹（命名格式：项目名_评审材料_v版本号_YYYYMMDD），上传至评审会文档共享目录，并在会议邀请正文中附上链接。
← 上一章 📖 返回目录 下一章 →