1.1 原型评审会概述与目标

原型评审会是产品设计流程中的关键质量关口，通过结构化评审机制，在正式开发前验证原型的可用性、需求匹配度与技术可行性。本章作为课程起点，系统定义评审会的适用边界、运作流程与交付标准，为后续各章的准备清单提供框架性指引。

适用场景

原型评审会并非所有项目阶段都必须召开，以下场景是启动评审的典型触发条件：

• 里程碑节点评审：产品设计从低保真进入高保真阶段、或高保真原型完成准备移交开发时。
• 关键决策点：交互方案存在多路线分歧、或核心功能的技术可行性存疑时。
• 客户/ stakeholder 确认：外部客户或内部决策层需要验收原型是否符合业务需求时。
• 跨团队对齐：设计、产品、开发、测试等多角色对原型理解不一致、需统一认知时。
• 风险控制触发：原型涉及高风险交互（如支付、权限、数据展示）或合规审查要求时。

评审全景视图

下图从「类型→阶段→目标→产出」四个递进层级，展示原型评审会的完整架构。每一层都建立在前一层基础之上，形成可追溯的评审链路。

前置条件

以下条件全部满足后方可启动原型评审会：

• 原型设计稿达到当前阶段要求的完整度（低保真阶段需包含核心交互流程，高保真阶段需包含视觉细节与动效说明）。
• 需求文档（PRD / 用户故事 / 功能列表）已锁定版本，并与原型版本号一一对应。
• 评审议程与参与角色清单已提前 48 小时发出，所有参会者确认收到。
• 评审环境（设备、投影、网络、原型可交互版本）已准备就绪。
• 主持人已指定，并熟悉评审流程与时间盒（通常不超过 90 分钟）。

操作步骤

标准原型评审会按以下 6 步执行，每步均有明确的输出物与时间控制：

1. 议程说明（5 min）：主持人宣读评审类型、阶段目标、时间盒与决策规则。
2. 原型演示（15–20 min）：设计师按用户操作路径完整演示原型，同步说明设计意图与备选方案。
3. 分模块评审（40–50 min）：按功能模块逐一评审，记录每个模块的通过/修改/驳回意见。
4. 争议讨论与决策（10–15 min）：对评级为「修改」或「驳回」的议题进行集中讨论，形成明确结论。
5. 汇总并宣读结论（5 min）：主持人当场宣读评审结论、修订项清单与责任人、时间节点。
6. 签署确认（2 min）：所有决策角色在评审记录表上签字，电子签或纸质签均可。

输入输出物

类别	输入物（会前准备）	输出物（会后交付）
原型文件	当前版本原型（可交互 / 静态标注稿）+ 版本变更记录	标注了修订标记的新版原型（如有修改）
需求文档	PRD 或用户故事地图，含验收标准	需求-原型对照矩阵（标注评审结论）
评审通知	评审议程 + 角色清单 + 预读材料包	—
评审记录	空白评审记录表（模板）	已填写并签字的评审报告 + 修订清单
决策依据	用户测试报告 / 竞品分析 / 技术可行性评估（如有）	决策纪要（含否决/推迟原因）

责任边界

角色	职责边界	决策权限
主持人	控制议程与时间盒，引导讨论，宣读结论	有权中止发散讨论，有权裁定流程争议
设计师	演示原型，解释设计理由，记录修改意见	对设计实现方案有建议权，无最终决策权
产品经理	确认需求覆盖度，判定需求变更	对需求匹配度有一票否决权
技术负责人	评估技术可行性与实现成本	对技术不可行项有一票否决权
测试代表	从测试视角提出可测性与边界条件问题	建议权，无最终决策权
决策者	做出最终通过/修改/驳回决定	终审决策权，对争议项有最终裁决权

记录材料

评审过程中必须形成以下三类记录，缺一不可：

• 评审报告：包含评审基本信息（时间、地点、参与人）、各模块评审结论、通过/修改/驳回数量统计。
• 修订清单：逐条记录修订项编号、模块名称、问题描述、责任人、要求完成日期、验收标准。
• 签字确认页：所有决策角色手写签名或电子签名，确认对评审结论知情并接受。

异常处理

异常情形	处理预案	升级路径
关键决策者缺席	改期或授权代表（需提前出具书面授权书）	缺席者审阅会议录像后 24 小时内补签
评审议题严重超时	主持人将争议项标记为「待定」，进入线下专题会	专题会结果需在 3 个工作日内返回主流程
原型与需求版本不一致	立即暂停评审，确认正确版本后重新排期	版本管理员更新版本矩阵，通知所有参会者
评审结论无法达成一致	决策者行使终审权，或升级至更高级别决策者	升级裁定结果作为最终结论记入评审报告
原型演示出现技术故障	切换至静态标注稿或录屏演示，会后补交互演示	故障记录纳入工具改进清单

验收标准

← 上一章 📖 返回目录 下一章 →