第3章 原型设计类型与选择：低保真原型、高保真原型、交互原型、数据原型的选择标准与适用场景
在数据产品迭代中，原型类型的选择直接决定验证效率与迭代质量。本章围绕四种核心原型类型，给出从场景判断到决策记录的全套SOP，帮助团队在项目不同阶段匹配合适的原型形态，避免“过度原型化”或“原型不足”两类典型偏差。
核心原则：原型保真度与项目阶段、验证目标、受众群体、资源约束四维匹配。高保真 ≠ 更好，合适才是关键。
适用场景
四种原型类型在不同项目阶段、验证目标和使用场景下的适配关系如下表所示：
| 原型类型 | 项目阶段 | 验证目标 | 受众群体 | 典型场景 |
|---|---|---|---|---|
| 低保真原型 | 概念期 / 探索期 | 核心结构、信息架构 | 内部团队、产品组 | 需求对齐、早期可行性验证 |
| 高保真原型 | 设计期 / 开发前 | 视觉细节、品牌感知 | 客户、 stakeholders | UI评审、设计确认 |
| 交互原型 | 设计期 / 可用性测试 | 交互流程、操作路径 | 目标用户、测试组 | 可用性测试、流程验证 |
| 数据原型 | 开发期 / 数据验证 | 数据逻辑、指标口径 | 数据工程师、业务方 | 数据管道验证、看板模拟 |
选型口诀：概念阶段用低保真，设计阶段用高保真，交互测试用交互型，数据验证用数据型。四类原型可组合使用，不必拘泥于单一选择。
前置条件
在选择原型类型之前，必须完成以下准备工作：
- 产品需求文档（PRD）初稿 — 至少包含核心功能列表与业务目标描述。
- 用户画像与场景定义 — 明确目标用户及其核心使用路径。
- 项目阶段与时间计划 — 确认当前处于概念期、设计期还是开发期。
- 资源与工具盘点 — 团队具备的原型工具能力（如Figma、Axure、Tableau）及可用时间预算。
- 受众沟通计划 — 明确原型将展示给谁（内部团队、客户、测试用户），以及期望获取的反馈类型。
常见前置遗漏：跳过用户画像直接选型，容易导致原型保真度与受众期望错位。每次选型前务必确认“给谁看”和“验证什么”。
操作步骤
原型类型选择遵循以下6步标准化流程：
- 明确验证目标 — 定义本次原型要回答的核心问题（结构合理性/视觉感受/交互效率/数据正确性）。
- 评估项目阶段 — 判断当前属于概念探索、设计细化还是开发验证阶段，不同阶段对应不同的原型深度要求。
- 分析受众群体 — 内部团队可接受低保真草图，外部客户或高管需要更高保真度的呈现，测试用户需要可操作的交互原型。
- 盘点资源约束 — 可用时间（天/周）、工具熟练度、数据准备成本三个维度综合评估。
- 匹配原型类型 — 将以上四维信息输入决策框架，定位到最合适的原型类型（可多选组合）。
- 记录选型决策 — 填写《原型类型选择决策记录表》，包含选择理由与备选方案，供后续追溯。
以下流程图展示了从需求输入到原型类型选择的完整决策路径：
输入输出物
| 类别 | 具体内容 | 格式 / 载体 |
|---|---|---|
| 输入 | 产品需求文档（PRD）初稿 | 文档 / Wiki |
| 输入 | 用户画像与场景定义 | 文档 / 卡片 |
| 输入 | 项目阶段与时间计划 | 甘特图 / 计划表 |
| 输入 | 资源与工具能力盘点 | 清单 / 表格 |
| 输出 | 原型类型选择决策记录表 | 结构化文档 |
| 输出 | 原型制作任务书（含选型理由） | 任务卡片 / Jira |
责任边界
| 角色 | 职责内容 | 决策权限 |
|---|---|---|
| 产品经理 | 主导选型决策，定义验证目标与受众 | 最终决策权 |
| 设计师 | 评估工具能力与制作成本，提供专业建议 | 建议权 |
| 数据工程师 | 数据原型场景下评估数据准备成本与可行性 | 技术否决权 |
| 项目经理 | 确认时间与资源约束，协调优先级 | 资源确认权 |
决策机制：产品经理拥有最终决策权，但需在决策记录中注明“四维匹配理由”。若出现分歧，以“验证目标”为最高优先级裁决维度。
记录材料
每次原型类型选择完成后，须填写《原型类型选择决策记录表》，结构如下：
{
"项目名称": "数据产品迭代任务名称",
"迭代版本": "v1.2.0",
"验证目标": "核心交互流程可用性",
"项目阶段": "设计期",
"受众群体": "目标用户（8人可用性测试）",
"资源约束": "2周时间 / Axure可用",
"原型类型选择": "交互原型",
"备选方案": "高保真原型（若时间充裕可升级）",
"决策理由": "验证目标为交互效率，受众为测试用户，需可操作原型",
"决策人": "产品经理 张XX",
"评审确认": "设计师 李XX / 项目经理 王XX",
"决策日期": "2025-03-20"
}该记录归入产品档案，作为后续迭代中原型选型的参照依据。
异常处理
| 异常场景 | 可能原因 | 处理方案 |
|---|---|---|
| 原型类型选择后频繁变更 | 验证目标未明确，四维评估不充分 | 暂停制作，重新组织四维评估会，锁定验证目标后再启动 |
| 团队对选型意见不一致 | 角色视角差异，缺乏统一决策框架 | 使用本章决策框架逐维打分，以验证目标为最高优先级裁决 |
| 资源无法支撑所选原型类型 | 资源评估过于乐观 | 降级至相邻低一档原型类型（如从高保真降为低保真+交互原型组合） |
| 受众对原型保真度反馈失真 | 受众群体判断错误（如给内部团队看了高保真原型导致过早关注细节） | 切换为合适保真度原型，并在展示前明确告知“本次验证焦点” |
异常规避红线：禁止在验证目标未锁定的情况下开工制作原型。每次选型变更必须重新记录决策理由，不得“先做再改”。
验收标准
原型类型选择是否正确、完整，通过以下五项检查进行验收：
- 匹配性检查：原型类型与验证目标、项目阶段、受众群体、资源约束四维全部匹配。
- 记录完整性检查：《原型类型选择决策记录表》已填写，包含决策理由与备选方案。
- 评审确认检查：产品经理、设计师、项目经理三方在记录表上签字或电子确认。
- 可追溯性检查：选型记录已归入产品档案，并关联对应的原型制作任务卡片。
- 异常预案检查：若存在资源约束或受众不确定性，已记录降级方案或备选原型计划。
以上五项全部通过，则本章节的原型类型选择流程验收合格，可进入下一阶段的原型制作环节。