原型评审意见要能追踪，不能只记“改了什么”，还要留下为什么改、谁确认、改在哪个版本、怎样证明这条问题已经解决。把零散评论整理成有编号的决策记录，再让每条记录对应到原型页面和下一次确认动作，团队才不会在下一轮重新讨论同一件事。
如果会议流程还没统一，可以先按产品原型评审的前中后流程组织讨论；会后则在墨刀原型中整理需要调整的页面与交互，另用团队共享文档或表格记录决定。页面负责呈现方案，记录负责说明方案为何变成现在这样。
哪些意见需要单独留一条决定
不是每个错字、对齐问题都值得建立决策单。直接修复且不影响理解的小问题，留在页面评论里即可。涉及业务规则、操作结果、用户权限、范围取舍或者方案被否决的原因，就应该单独编号。否则一次“把按钮改清楚”的讨论，很容易把产品规则也悄悄改掉。
| 收到的意见 | 合适的处理 | 需要留下什么 |
|---|---|---|
| 确认按钮错写成“确人” | 直接修正 | 对应页面与修正结果 |
| “取消订阅”不知道什么时候生效 | 建立决策记录 | 生效时点、权益变化和页面反馈 |
| 希望增加一个退款入口 | 先确认规则与范围 | 是否提供退款、适用条件、决定人 |
| 本期先不做撤销取消 | 记录暂缓决定 | 不做的原因、受影响用户、重新讨论的触发条件 |
记录的最小单位应是一项需要确认的规则。把十条意见合成一个“订阅页优化”任务，关闭任务时仍然不知道退款规则、到期日期和操作反馈是否分别得到确认。
把“取消订阅不清楚”拆成三个可回答的问题
以下用一个订阅服务的评审练习说明方法。设定是：业务准备提供“立即取消”和“到期取消”两个入口，但初稿只有一个“取消订阅”按钮。这里先不替业务规定退款政策，而是把必须由产品与业务确认的内容暴露出来。
- 什么时候停止服务？立即取消意味着操作成功后终止权益；到期取消意味着停止后续续费，本期权益保留到明确日期。按钮、确认页和结果页要表达同一规则。
- 剩余费用怎么处理？能否退款、退款如何计算、由谁处理，不能从按钮文案推断。规则未定时，把退款问题列为未决项，不能先在确认页写“将退还剩余费用”。
- 用户凭什么知道操作成功？确认前需要看到影响，提交后需要看到取消状态、生效时间和下一步。只弹出“操作成功”，无法告诉用户权益是否还在。
给三个问题分别编号为 D-031、D-032、D-033。D-031确认生效时点，D-032确认退款规则，D-033确认结果反馈。即使它们修改同一个页面，也不强行合成一个决定。
一条记录要分清原话、依据和最终决定
评审原话是“这个按钮有点吓人”，依据可能是“确认页没有解释生效日期”，决定才是“拆分两种取消操作并分别说明影响”。三者不能互相替代。尤其不要把同事偏好写成用户研究结论，把“大家觉得更清楚”写成“验证了转化提升”。
可以直接使用下面这条填写方式。版本和编号用于演示组织方法，迁移到你的项目时替换为实际记录。
| 记录字段 | D-031：取消生效时点 |
|---|---|
| 待决定的问题 | 用户能否区分立即终止权益与本期结束后停止续费？ |
| 涉及位置 | 订阅详情、取消确认、取消结果；原型 v1 |
| 已知依据 | 当前确认页未列出生效日期；两种业务操作共用“取消订阅”文案 |
| 候选方案 | A：保留单入口，在下一步选择；B：在详情页区分两种操作 |
| 决定与理由 | 采用 B，让用户发起操作前知道生效差异；确认页再次展示权益截止日期 |
| 未决依赖 | D-032 退款规则待确认；任何退款金额文案不得随 D-031 一起定稿 |
| 决定人与执行人 | 产品负责人确认操作规则；设计负责人调整页面；研发负责人核对接口状态 |
| 完成条件 | 各入口与其确认、结果状态的生效时点相互对应；取消返回不改变原订阅状态 |
| 目标版本与状态 | 原型 v2；已决定，待改图 |
| 重新打开的条件 | 业务取消其中一种操作，或权益生效规则发生变化 |
“已知依据”只写手里已有的材料。没有用户观察记录时，写页面缺口和业务规则就足够；需要后续研究验证的问题单列行动项，不补造观察人数和访谈结论。
在原型里把决定落到可核对的位置
打开墨刀中的订阅流程，先将页面命名为“订阅详情”“立即取消确认”“到期取消确认”“取消结果”，用文字说明标出各状态对应的决定编号。编号可以写在页面旁的说明区域，也可以写入团队使用的评审文档；无需等待工具提供专门的决策管理功能。
接下来只改 D-031 承诺的内容，不顺手重做整套订阅页：
- 在详情页区分“立即取消”和“到期取消”，分别说明权益何时终止。是否将两者作为同等显著的入口，由产品根据业务场景决定。
- 在两个确认状态中展示实际适用的权益截止日期。退款规则没有确认时，保留对应评审问题，不用一个看似确定的金额掩盖空缺。
- 连接“返回”和“确认”路径：返回应回到原订阅状态，确认则进入与所选操作一致的结果状态。
- 在结果页说明本次操作是什么、何时生效、用户还能做什么。到期取消后仍保留权益的场景，不应显示“服务已终止”。
把上述文字规则与页面摆在一起核对，往往比只看界面是否漂亮更容易发现矛盾。涉及权益、金额、服务端状态的判断还要进入研发说明；可以沿用原型标注的方法，把触发条件与反馈写在相关状态旁。
意见冲突时，先确认争议究竟在哪里
运营希望减少立即取消，客服希望用户迅速停止服务，研发希望只保留一个接口。三方看似在争论按钮，其实分别在讨论留存目标、服务体验和实现约束。决策记录应保留这些差异，再由有权确定相应规则的人做决定。
可以在会上这样追问：“我们现在决定的是操作入口，还是是否允许立即终止权益？如果后者还未确认，先不以按钮方案代替业务决定。”把争议收窄之后，再列出各方案的后果：多一步选择是否更容易理解，两种操作是否共用确认页，暂缓某种操作是否会让用户失去必要出口。
信息不足就保持“待确认”，并指定谁在什么条件下补齐什么资料。例如“产品负责人补充退款规则，经业务确认后再定退款提示”。不要只写“会后讨论”，也不要用多数投票替代权限、收费等必须由责任人确认的规则。
改完图不等于决定已经闭环
把一条记录分成“待确认—已决定—已改图—已核对”几种工作状态即可。对延期事项另标“暂缓”，同时保留回看条件。状态名称可以调整，但“有了决定”和“页面已经符合决定”必须分开。
D-031改完后，让另一位评审者按记录中的完成条件走一遍：从订阅详情分别进入两个取消入口；在确认前说出何时停止权益；返回后查看原状态；确认后检查结果页的时间与入口是否一致。若任一步仍需作者额外解释，就记录具体缺口并继续修改，而不是凭截图已更新关闭问题。
若后来业务把“立即取消”改为“提交人工处理申请”，应新增一条决定并引用 D-031，说明它替代了哪些规则。旧记录保留原结论及其适用版本，不能悄悄改成新内容，让此前依据失去解释。
完成一次迭代后，交给团队的是同一份原型入口、一组已确认的决定、尚未解决的依赖及各自负责人。一个新成员应能从页面编号追到决定，再从决定找到改动位置。它比冗长的会议逐字稿更适合持续维护，也更容易发现“文案变了，规则却没确认”的问题。
从下一次评审开始，只挑一项会改变业务行为的争议建立记录，完整跟到核对结束。需要继续完善页面、交互和协作方式时，再按原型设计专题补齐相邻环节。
