2. Axure原型在RICE中的定位：从辅助工具到决策引擎
RICE决策模型依赖四个核心维度的量化评估：覆盖范围（Reach）、影响力（Impact）、置信度（Confidence）、努力程度（Effort）。在实际落地过程中，产品经理往往面临“需求描述模糊”、“干系人认知偏差”、“交互逻辑不可测”等问题，导致RICE评分失真。Axure原型在这一环节中，不再只是一个静态页面绘制工具，而是扮演了“需求可视化载体”与“数据收集探针”的双重角色，为每个RICE要素提供可量化的输入依据。
2.1 用户场景与业务问题
| 角色 | 用户场景 | 业务问题 |
|---|---|---|
| 高级产品经理 | 需向VP汇报Q2重点功能优先级，仅凭文档无法解释“为什么A功能置信度高但B功能覆盖大” | 缺乏可视化的决策辅助工具，评审会变成“谁声音大谁优先” |
| 交互设计师 | 基于低保真原型做A/B测试，但无法快速收集用户操作路径与停留时间作为RICE输入 | 原型与RICE评分之间断链，设计师只能凭感觉填写置信度 |
| 业务方 | 看到原型草稿后提出“这个按钮应该更明显”，但无法判断改动对影响力(Impact)的影响 | 需求变更缺乏量化验证通道，RICE评分被主观意见污染 |
核心洞察：RICE评分中的“置信度”往往是水分最大的指标。通过可交互原型收集用户行为数据，可将置信度从直觉猜测提升为证据驱动。
2.2 需求拆解：原型在RICE四要素中的映射
将Axure原型功能拆解为与RICE四要素对应的能力单元，形成可直接赋值的组件化结构：
- 覆盖范围（R） → 原型中标记潜在用户触及点（入口、弹窗、分享路径），使用条件显示逻辑模拟不同触达场景，统计原型点击热区数据推测真实覆盖。
- 影响力（I） → 原型内嵌入“用户预期价值评定”轻量问卷（如：完成此任务后您的满意度评分1-5），通过原型内的交互反馈直接采集单次任务的影响感受。
- 置信度（C） → 原型设置多分支路径（乐观/悲观/中间态），对比测试后的行为数据（如放弃率、任务完成时间）强化或修正假设证据等级。
- 努力程度（E） → 原型标注开发边界（使用元件备注或状态面板），将交互复杂度、异常逻辑分支数量转化为开发人天估算参考值。
2.3 方案表达：RICE决策辅助原型结构
下图为典型的Axure原型在RICE决策流程中的定位关系图，展示从“需求提出”到“RICE决策”再到“原型验证闭环”的信息流转方式：
方案设计原则：
- 原型中每个交互元件都应带有RICE标签（如：在按钮备注中写“影响R×1.2, I×0.8”），使评分直接绑定到元件级别。
- 使用Axure的“条件逻辑”模拟用户不同选择路径，用日志变量记录每个路径的停留时长与点击频次，作为置信度的原始证据。
- 努力程度评估时，将原型中状态变化数量（如：成功/失败/加载/空态）与分支判断逻辑分别用元件计数器标注，供开发估算人天。
2.4 指标验证与验收标准
| 验证维度 | 验证指标 | 验收标准 |
|---|---|---|
| 需求可视化完整性 | 原型覆盖需求条款的百分比 | ≥95% 的需求条目在原型中拥有对应交互状态 |
| 数据收集有效性 | 原型内置采集点的数据回传率 | 单次用户测试采集到8个以上RICE相关数据点（点击热区、路径时长、评分输入） |
| 决策辅助一致性 | 基于原型导出的RICE评分与最终开发优先级排序比对 | 排序偏差不超过1个位次（即原型评分前3的功能仍进入实际开发队列前3） |
常见陷阱：
- 原型制作的交互过于逼真以致测试者以为“这是最终版本”，拒绝提出改进建议——应在原型页脚标注“版本：RICE决策原型V1.0，非最终UI”。
- 忘记在原型中设置数据收集脚本，导致置信度=0——在原型发布前必须使用Axure“输出HTML并包含日志”功能验证数据通道。
- 将原型定位为“需求文档的附属品”而非“决策中心”——RICE决策流程中，原型必须成为所有评估者的统一参照物。
2.5 交付物模板
第2章对应的交付物模板为 《RICE决策原型说明书》，包含以下固定结构，供项目团队在原型评审时使用：
[章节内容] [原型对应内容] [RICE映射]
1. 需求概述 原型首页 + 全局导航 覆盖范围（R）
2. 用户路径清单 带编号的页面流程图 影响力（I）
3. 关键交互说明 标注了条件逻辑的原型组件 置信度（C）
4. 异常分支覆盖 原型中所有错误/空/加载状态 努力程度（E）
5. 数据采集点 Axure日志变量定义表 综合校验
6. RICE评分表 基于原型导出的评分单 输出结果
交付物验收规则：原型说明书必须在RICE决策会议前48小时交付，并确保至少经过1次内部走查（由非本需求的另一名PM完成），走查记录附着在说明书末尾。