产品原型评审常见的困境是：一场会开完，业务说“这不是我们要的”，研发说“这个做不了”，意见混在一起，没人能判断哪些该改、谁来改。问题往往出在收集环节——业务和研发被问的是同一组问题。本文给出一套分角色收集反馈的做法：会前按角色准备提问清单，会中分栏记录，会后归并定状态并指定责任人，最后用检查表确认反馈是否收齐。评审意见的归并和跟踪可以放在ONES的工作项与文档协作中承载，便于逐条闭环。
要点总览（TL;DR）
- 业务侧反馈围绕目标用户、场景完整性、价值判断和验收口径；研发侧反馈围绕实现路径、数据来源、异常边界和依赖风险，两类问题分开问。
- 评审前把原型准备到关键页面、主流程和状态变化可走查的颗粒度，按角色分发五到八个问题的提问清单，让参与者带着问题到场。
- 现场按主流程逐屏走查，每屏先由业务侧讲场景与判断，再由研发侧讲实现与风险，记录人分栏记录并标注原型位置和提出人。
- 会后24小时内归并同类意见、单列冲突意见，将每条反馈归入待确认、需修改、暂不处理三种状态，指定唯一责任人和回复时限。
- 用完成检查表核对两类角色是否都有实质反馈、每条反馈要素是否齐全、冲突意见是否指定裁决人，未通过项补充收集后再进入修改。
先定反馈分工：业务看什么，研发看什么
收集反馈前先明确分工：业务侧回答“这个方案是否解决目标用户的问题、验收时怎么算通过”，研发侧回答“按当前方案实现会遇到什么阻碍、哪些条件还没定”。两类问题分开问，反馈才有可比性，不会出现业务在讨论技术方案、研发在猜测业务意图的场面。
下表列出两类角色各自的反馈维度和共用的记录字段，评审前可直接作为反馈表的表头。
| 角色 | 反馈维度 | 要问的具体问题 |
|---|---|---|
| 业务侧 | 目标用户与场景 | 这个原型覆盖的用户角色和主场景是否完整？有没有遗漏的高频场景？ |
| 业务侧 | 价值判断 | 每个页面或步骤对业务目标的贡献是什么？哪些环节可以简化？ |
| 业务侧 | 验收口径 | 上线后用什么指标或业务结果判断这个方案有效？ |
| 业务侧 | 优先级 | 如果范围要压缩，哪些功能必须先上，哪些可以后置？ |
| 研发侧 | 实现路径与工作量 | 主流程的实现方式是否清晰？哪些部分工作量明显超出预期？ |
| 研发侧 | 数据来源与字段 | 页面展示的数据从哪来？字段定义、口径和更新频率是否明确？ |
| 研发侧 | 异常与边界条件 | 空数据、超时、重复提交、权限不足等情况下页面如何表现？ |
| 研发侧 | 依赖与风险 | 依赖哪些外部系统、接口或第三方能力？哪些依赖尚未确认？ |
两类反馈共用同一组记录字段，保证后续能合并处理：原型位置（页面名加屏号或流程节点）、问题描述（一句话说清现象或疑问）、提出人、影响范围（影响哪个角色、哪个流程环节、是否阻塞开发）、建议处理方式（提出人自己的倾向，供决策参考）。
本文讨论的是产品方案层面的原型评审。视觉设计制作、需求文档本身的质量评审、原型工具操作教学不在范围内，这些环节有各自的评审方法，混入同一次会议会稀释反馈质量。
评审前的准备：材料、角色与提问清单
评审效果很大程度上取决于到场的人是否带着问题来。准备工作包括三件事：原型达到可评审的颗粒度、角色到位且职责清楚、提问清单提前分发。
原型准备到什么颗粒度
适合评审的原型应包含关键页面、主流程和状态变化。关键页面指承载核心业务动作的页面，不必每个页面都精细；主流程要能从头走到尾，让参与者看到完整路径；状态变化包括正常态之外的加载、空数据、失败、无权限等表现。颗粒度不足时，评审容易变成对未画出的部分做口头想象，反馈难以落到具体位置。
参与角色与职责
- 产品负责人：讲解方案背景与设计意图，现场判断哪些意见当场采纳，会后负责原型修改。
- 业务代表：来自实际使用方或业务归口部门，负责场景完整性、价值判断和验收口径。
- 研发代表：负责实现路径、数据、边界条件和依赖风险，最好包含前端与后端各一名。
- 记录人：由产品团队中不主讲的人担任，负责分栏记录和会后整理，避免主讲人边讲边记遗漏意见。
分角色提问清单
提问清单按角色分别准备，随原型材料提前至少一个工作日分发，让参与者带着问题到场。业务侧清单围绕场景与验收，例如“这个流程里哪一步对用户最耗时”“如果只能保留三个页面，保留哪三个”。研发侧清单围绕实现与边界，例如“这个交互需要哪些接口支持”“哪些字段当前系统里没有”。清单不必长，每个角色五到八个问题即可，重点是让反馈有落点。
评审中的收集流程：逐屏走查与分开记录
现场操作的核心是控制节奏和隔离两类发言。建议按以下步骤推进：
- 开场说明规则（约5分钟）：产品负责人交代评审目标和范围，主持人说明发言顺序——每屏先由业务侧讲场景与判断，再由研发侧讲实现与风险。
- 按主流程逐屏走查：以主流程为线索，一屏一屏过。每屏控制在五到八分钟，产品负责人先讲该屏的设计意图，然后按“业务先、研发后”的顺序收集意见。
- 分栏记录：记录人把记录表分成业务意见和研发意见两栏，逐条记录，每条都带上原型位置和提出人。分栏的目的不是制造对立，而是让后续归并时能看清每类问题的来源和性质。
- 当场分流：能在会上由产品负责人直接判断的（如文案调整、页面顺序），当场记录处理结论；涉及数据口径、外部依赖、业务规则未定的，标记为待确认，指定会后确认的对象。
- 收敛跑题：出现方案争论或技术方案设计时，主持人及时打断，把问题记入待确认清单，回到当前屏的走查。整场评审控制在预定时间内，未走完的屏另约时间，不压缩记录质量。
先业务后研发的顺序有实际原因：业务侧先讲清场景和验收标准，研发侧才能在明确的目标下判断实现约束；反过来先讨论技术方案，业务代表容易失去参与感，场景类问题被技术细节淹没。
分栏记录模板可直接使用下表结构：
| 原型位置 | 业务意见 | 研发意见 | 提出人 | 影响范围 | 当场结论/待确认 |
|---|---|---|---|---|---|
| 订单确认页-屏3 | 缺少修改收货地址入口 | 地址修改涉及订单状态回滚，需确认规则 | 业务-张；研发-李 | 影响下单主流程 | 待确认：地址修改的订单状态规则 |
评审后的归并与闭环：状态、责任人与回复
会后24小时内完成反馈归并，是保证评审成果不流失的关键动作。归并时先合并同类项：同一页面、同一问题的多条意见合成一条，保留不同提出人的视角；相互冲突的意见单独列出，例如业务要求简化步骤而研发指出简化会丢失必要校验，这类冲突不能靠合并解决，需要指定裁决人。
每条反馈归入三种状态之一：
- 待确认：问题成立但缺少判断依据，如业务规则未定、数据口径不明、外部依赖未确认。判定依据是“需要会外信息才能决定怎么改”。
- 需修改：结论明确、修改范围清楚，直接进入原型修改。判定依据是“产品负责人已能给出修改方案”。
- 暂不处理：意见合理但超出本次范围，或与已确认的方案方向冲突。暂不处理要写明原因和重新评估的条件，不能只写“不处理”。
每条反馈指定唯一责任人，待确认项同时约定回复时限，通常不超过三个工作日。回复时对业务侧侧重说明场景和验收口径如何落实，对研发侧侧重说明数据、边界和依赖问题的处理结论。原型修改完成后，判断是否需要二次评审：涉及主流程变化、新增外部依赖或验收口径调整的，组织小范围二次评审；仅文案、顺序、样式调整的，修改后通知提出人确认即可。
反馈条目多、跨角色流转时，可以把每条反馈登记为工作项，用状态字段对应待确认、需修改、暂不处理，责任人和回复时限直接落在工作项上，原型文档与反馈记录放在同一处，提出人能看到处理进展。ONES的项目工作项与文档协作可以承载这类跟踪，具体配置按团队现有流程设置。
示例：一次订单流程原型的双角色反馈收集
以下为演示情景，用于说明流程如何落地，不代表真实项目数据。
背景与范围：某零售业务的线上下单流程改版，原型覆盖商品选择、订单确认、支付三个环节共八屏，目标是缩短下单路径。参会角色为产品负责人、两名业务代表（运营与客服）、前端与后端研发各一名、记录人一名。
业务侧反馈：运营代表在订单确认页提出缺少优惠券手动选择入口，客服代表提出支付失败后的重试路径不清晰，并给出客服工单中的高频问题作为依据。两条意见均记录在业务栏，标注屏号和提出人。
研发侧反馈：后端研发指出优惠券叠加规则当前系统未定义，需要业务先确认；前端研发指出支付失败重试涉及订单状态回滚，需明确重复支付的防护规则。两条意见记录在研发栏，标记为待确认。
归并与状态判定：优惠券入口与叠加规则合并为一条，状态为待确认，责任人为产品负责人，约定三个工作日内与运营确认规则；支付重试路径与状态回滚合并为一条，状态为需修改，责任人为产品负责人与后端研发共同给出方案；客服提出的工单高频问题中有一条涉及退款流程，超出本次范围，状态为暂不处理并注明原因。
修改后确认：原型更新后，产品负责人将修改点逐条回复给提出人，业务代表确认优惠券入口和重试路径符合预期，研发确认状态规则已写入方案说明。因涉及支付状态变化，组织了一次小范围二次评审，仅邀请研发与运营代表参加。
完成检查：这次评审的反馈收齐了吗
评审结束后，用下表逐项核对，判断本次反馈收集是否完整可用。任何一项未通过，都应补充收集后再进入修改。
| 检查项 | 通过标准 |
|---|---|
| 两类角色都有实质反馈 | 业务侧与研发侧各自提出至少若干条具体意见，没有出现单方主导、另一方全程沉默的情况 |
| 每条反馈要素齐全 | 均有原型位置、问题描述、提出人和处理状态，缺项已补齐 |
| 冲突意见已单列 | 相互矛盾的意见单独列出，并指定了裁决人和裁决时限 |
| 待确认项有回复时限 | 每条待确认反馈都约定了回复时间和确认对象 |
| 修改已通知提出人 | 原型按需修改后，修改结果已回复给相关提出人并得到确认 |
这套检查表也可以作为下一次评审的准备参照：上次未通过的检查项，往往提示会前准备或现场记录环节需要调整。
常见问题
业务代表在评审中提不出具体意见，只表示“整体可以”，怎么办？
这种情况通常说明会前提问清单没有落到具体场景。可以在现场改用场景追问：请业务代表针对主流程中耗时最长或投诉最多的一个环节，指出原型中对应哪一屏、当前设计能否解决。也可以请业务代表按验收口径逐条判断，例如“上线后用什么指标判断这个方案有效”，把笼统的认可转化为可记录的具体判断。若业务代表仍无法给出意见，应标记为待确认，会后补充业务数据或用户反馈后再收集。
研发在评审中直接给出技术方案并否定原型，主持人应该怎么处理？
主持人的动作是把技术方案讨论转为风险记录。先请研发说明当前原型在实现上遇到的具体阻碍，例如缺少哪个接口、哪个字段口径未定、哪个状态变化未覆盖，记录为研发侧反馈并标注待确认。技术方案本身另约时间讨论，不占用原型评审的逐屏走查时间。这样既保留了研发提出的约束，也避免业务代表在技术细节中失去参与感。
评审后业务和研发对同一条反馈的处理结论不一致，以谁为准？
冲突意见不靠合并解决，应单列并指定裁决人。裁决人通常是产品负责人；涉及业务规则和验收口径的，由业务归口负责人裁决；涉及外部依赖能否满足的，由研发负责人给出可行性结论后再由产品负责人决定方案取舍。裁决结果和依据写入反馈记录，并回复给双方提出人，避免同一问题在后续评审中反复出现。
原型修改后，什么情况下需要组织二次评审？
涉及主流程变化、新增外部依赖或验收口径调整的修改，建议组织小范围二次评审，只邀请受影响的业务代表和研发人员参加。仅文案、页面顺序、样式调整的修改，产品负责人更新原型后通知提出人确认即可。二次评审的范围应聚焦修改点，不重复走查已确认的页面，控制在一屏到三屏的范围内。
反馈条目很多、跨角色流转时，用什么方式跟踪比较合适？
可以把每条反馈登记为工作项，用状态字段对应待确认、需修改、暂不处理，责任人和回复时限直接落在工作项上，原型文档与反馈记录放在同一处，提出人能看到处理进展。ONES的项目工作项与文档协作可以承载这类跟踪，具体字段和流程按团队现有配置设置。条目较少时，一张分栏记录表加责任人列也能完成闭环。
