产品经理选择原型保真度时，应先看当前阶段需要做出的决定，而不是按固定流程从低保真一路画到高保真。需求探索阶段要快速比较方向，方案验证阶段要确认主流程，视觉与交互确认阶段才需要补充真实内容和状态，研发交付阶段则要让规则、边界和异常条件可追溯。
如果还不清楚两类原型的基本边界，先查看低保真原型和高保真原型的区别；本页只解决“项目走到哪个阶段，原型应该做到什么程度”。
1. 阶段选择总表：先确定决策，再确定细节
| 项目阶段 | 要做的决定 | 建议保真度 | 最小交付物 |
|---|---|---|---|
| 需求探索 | 问题是否值得解决、方向是否成立 | 草图或低保真 | 任务场景、候选流程、关键页面 |
| 方案验证 | 主流程是否顺畅、功能范围是否合理 | 可点击低保真或中等保真 | 主路径、必要分支、核心文案 |
| 视觉与交互确认 | 内容层级、组件状态和反馈是否清楚 | 关键路径高保真 | 真实内容、组件状态、重点动效 |
| 用户测试 | 测试者能否独立完成指定任务 | 与测试目标匹配 | 测试脚本所需页面与状态 |
| 研发交付 | 实现范围、规则和边界是否明确 | 关键流程高保真并配说明 | 正常与异常状态、规则、验收条件 |
这张表不是强制瀑布流程。高风险功能可以提前做高保真验证，低风险后台页面即使进入开发阶段，也不一定需要完整动效。
2. 需求探索阶段：用低成本原型比较方向
需求尚不稳定时，原型的任务是让团队看到不同方案，而不是证明某个方案已经完成。建议同时保留两到三个候选流程，每个方案只覆盖同一核心任务，便于比较步骤、信息结构和功能范围。
- 写清目标用户、触发场景和成功条件；
- 只画完成任务所需的页面，不补无关设置；
- 评审时询问“哪一步不必要、缺了什么、顺序是否合理”；
- 记录被否定方案的原因，避免后续重复讨论。
需要先发散问题与方案时，可结合头脑风暴的四项原则，再把结果收敛为原型。
3. 方案验证阶段：让主流程可点击、可测试
当团队已选择一个方向，下一步不是立即精修视觉，而是让主任务可完整走通。原型至少要包含入口、关键决策点、成功结果和必要的返回路径；文案可以接近真实内容，但不需要覆盖所有边缘状态。
这一阶段的完成标准
- 评审者能够不依赖口头解释完成主任务；
- 页面和步骤与需求范围一致；
- 关键按钮、输入和反馈有明确去向；
- 已标记暂不处理的分支和假设。
4. 视觉与交互确认阶段：只提高关键路径保真度
流程稳定后，产品经理应与设计师共同列出需要进一步确认的内容：真实文案是否放得下、视觉层级是否清楚、组件状态是否齐全、复杂交互是否可理解。优先细化高频、高风险或争议最大的路径，不必一次把全部页面升级。
准备投入更多细节前，可以先核对从低保真升级到高保真的五项条件，避免在流程仍反复变化时提前精修。
5. 用户测试与研发交付：按使用者补足信息
用户测试需要“足够真实”，不是“全部完成”
测试原型只需支持测试脚本中的任务，但关键文案、数据和反馈应足以让参与者独立判断。若测试的是信息架构，可保持较低保真；若测试的是表单错误、转场或复杂操作，则需补充相应状态。
研发交付要同时说明界面之外的规则
高保真画面不能替代业务规则。交付时应同步记录字段校验、权限、空状态、错误处理、数据来源和验收条件，并明确哪些页面仅用于示意。
6. 建立团队可复用的保真度规则
团队可以把“阶段”改写成一组进入条件：只有当主流程已确认、内容结构较稳定、下一轮决策确实依赖视觉或交互细节时，才升级关键页面。评审模板则固定记录本轮问题、原型范围、已知假设和不在范围内的内容。
Pixso的在线原型设计与协作功能可用于搭建页面跳转、预览交互、收集评论和回溯版本。建议为每轮评审保留清晰版本名称，让反馈对应到具体方案，而不是在同一稿件上反复覆盖。
确定本轮决策目标后，可以进入Pixso搭建一条可验证的核心流程，先完成最小交付物，再决定是否继续提高保真度。
7. 产品经理选择原型保真度常见问题
项目后期还能使用低保真原型吗？
可以。新增功能或不确定分支仍可先低成本探索，不必因为项目整体进入后期就直接制作高保真。
评审方总要求看高保真怎么办？
先说明本轮需要回答的问题，并只细化代表性页面。让评审方看到真实内容和一个关键交互，通常比精修整套未稳定流程更有效。
原型做到什么程度可以交付研发？
当核心路径、状态、规则和验收条件足以让研发独立理解，并且未完成部分已明确标注时即可交付；画面精细并不是唯一标准。
