产品原型是用草图、线框图或可点击交互稿，把产品方案中的页面结构、信息层级、关键操作流程和状态变化提前表达出来的中间产物，供团队在投入开发前讨论、验证并达成共识。本文围绕方案沟通与验证，解释它的定义、范围、组成和常见误解。
要点总览（TL;DR）
- 产品原型是用草图、线框图或可点击交互稿，把页面结构、信息层级、操作流程和状态变化提前表达出来的中间产物，服务于方案沟通与验证。
- 判断一个东西算不算原型，看它能否表达方案、被讨论、被验证；手绘草图、线框图、可点击原型和高保真交互稿都属于原型范畴。
- 原型包括结构、流程、状态与交互意图，不包括视觉设计制作、具体需求质量评审和开发实现细节。
- 原型与需求文档、视觉设计稿、MVP 回答的问题不同：原型验证方案形态，需求文档描述规则，设计稿确定视觉，MVP 是可交付的最小可用版本。
- 保真度应与讨论问题匹配，方向未定时追求精细会拖慢迭代；原型评审中暴露问题并修改，正是它的价值所在。
产品原型到底指什么
判断一个东西算不算产品原型，可以看它是否同时满足三个特征：能表达方案、能被讨论、能被验证。原型把停留在口头或文字里的产品想法，转成可以看见、可以操作的对象，让参与方针对同一份材料发表意见。它服务于方案沟通与验证，本身不是最终成品，也不承担上线交付的职责。
按这个标准，产品原型的常见载体包括以下几类：
- 手绘草图：用纸笔快速画出页面分区和主要元素，适合早期讨论方向，修改成本低。
- 线框图：用灰模方式呈现页面结构、信息区块和导航关系，重点在布局与层级，不涉及视觉风格。
- 可点击原型：把多个页面按操作路径连接起来，能模拟点击、跳转和部分状态变化，适合验证流程是否走得通。
- 高保真交互稿：在结构和流程基础上加入接近成品的视觉与动效，用于更贴近真实使用场景的讨论。
这几种载体没有优劣之分，区别在于回答的问题不同。草图回答“这个方向对不对”，线框图回答“页面放什么、怎么排”，可点击原型回答“用户能不能顺利走完这条路径”。同一个产品方案在不同阶段可能先后使用多种载体，它们都属于产品原型的范畴。
原型的边界：包括什么、不包括什么
原型的概念容易被泛化，把设计稿、需求文档甚至开发成品都称为原型。划清边界有助于在评审时明确当前材料要解决什么问题，避免用错讨论口径。
| 范围 | 内容 | 说明 |
|---|---|---|
| 包括 | 页面结构、信息层级、关键操作流程、状态与异常的表达 | 这些是原型要承载的核心信息，也是评审时主要讨论的对象 |
| 包括 | 交互意图，如点击后跳转、提交后的反馈、空状态与错误提示 | 用来说明方案在具体操作下如何响应 |
| 不包括 | 视觉设计制作，如配色、字体、图标规范与视觉风格定稿 | 属于视觉设计环节的工作，不在本文讨论范围 |
| 不包括 | 具体需求质量评审的方法与标准 | 需求是否完整、无歧义、可测试，归需求评审与确认主题 |
| 不包括 | 最终开发实现与代码层面的技术细节 | 原型不等于开发成品，不承担实现层面的约束 |
需要说明的是，边界清晰不等于环节割裂。原型评审中经常顺带讨论视觉方向或需求细节，这属于正常的协作交叉；本文强调的是，当讨论聚焦“方案是否说得清、走得通”时，原型是主要材料，视觉定稿和需求质量判定则各有其专门环节。
一个原型由哪些部分组成
拆开来看，一个完整的原型通常包含四类要素，它们共同决定方案能否被准确理解。
| 组成要素 | 回答的问题 | 缺失时的典型表现 |
|---|---|---|
| 页面结构 | 有哪些页面，页面之间如何组织 | 评审时说不清入口在哪、页面归属关系混乱 |
| 信息层级 | 每个页面放哪些信息，主次如何排列 | 关键信息被淹没，讨论停留在细节而看不到重点 |
| 操作流程 | 用户按什么顺序完成一件事 | 路径断裂，无法判断方案是否走得通 |
| 状态与异常 | 加载、空数据、失败、权限不足时页面如何呈现 | 只画了顺利路径，开发阶段才暴露未定义的情况 |
保真度层级则决定这些要素表达得多细。低保真原型侧重结构与流程，用简单方块和线条就能讨论方向性问题，适合方案早期；中保真原型补充较完整的信息层级和主要状态，适合跨角色对齐理解；高保真原型接近真实视觉与交互，适合验证具体操作体验和细节反馈。选择哪一层，取决于当前要讨论的问题：方向未定时追求精细会拖慢迭代，方案已定时停留在草图又难以暴露细节问题。
原型和相邻概念的区别
原型常与需求文档、视觉设计稿、MVP 等概念混用，它们回答的问题并不相同。
| 概念 | 主要回答的问题 | 与原型的关系 |
|---|---|---|
| 产品原型 | 方案长什么样、流程怎么走、状态如何变化 | 以可视、可操作的形式表达方案形态 |
| 需求文档 | 要做什么、规则是什么、边界条件如何定义 | 描述要求与规则，原型是其形态化表达，两者互为补充 |
| 视觉设计稿 | 最终呈现的配色、字体、间距与视觉风格 | 原型验证结构与流程，设计稿确定视觉呈现 |
| 交互稿 | 操作如何响应，动效与反馈如何设计 | 与可点击原型有重叠，交互稿更聚焦响应细节 |
| MVP | 最小可用版本交付什么、能解决什么问题 | 原型是验证手段，MVP 是可交付的最小可用版本 |
其中最容易混淆的是原型与 MVP。原型用于在投入开发前验证方案，通常不面向真实用户提供服务；MVP 则是实际交付给用户使用的最小版本，需要具备可运行、可衡量的能力。原型验证通过的方案，可能成为 MVP 的范围依据，但两者处于不同阶段，交付物性质也不同。
具体例子与常见误解
以下为一个演示情景，用来说明原型在方案沟通中的使用过程，不作为真实案例引用。
某团队要设计一个内部申请流程。第一轮讨论时，产品经理用纸笔画出三个页面：申请入口、填写表单、提交结果，标出主要按钮和跳转关系。团队当场发现“提交后是否需要审批人确认”没有说清，于是补充了审批环节的草图。第二轮把草图整理成线框图，明确每个页面放哪些字段、列表如何排序，并补上“申请被驳回”的状态页。第三轮做成可点击原型，按“填写—提交—审批—结果通知”的路径串联，评审时让参与者实际点一遍，发现驳回后重新提交的入口不明显，随即调整。整个过程中，原型从草图演进到可点击稿，每一轮都围绕具体问题展开讨论，而不是追求画面精细。
围绕这个过程，有几个常见误解值得纠正：
- 原型越精细越好：精细度应与讨论问题匹配。方向未定时，高保真稿会让参与者把注意力放在视觉细节上，反而忽略结构与流程问题。
- 原型等于设计稿：原型验证结构与流程是否成立，设计稿确定视觉呈现。把两者混为一谈，容易在方案尚未走通时就陷入配色讨论。
- 原型做完就不用改：原型本身就是用来暴露问题的，评审中发现的路径断裂、状态缺失正是它的价值所在，修改是正常环节。
- 原型只是给设计或开发看的：原型的主要用途是让产品、设计、开发、业务等角色针对同一份材料对齐理解，评审记录和结论也需要留痕，便于后续交接。
在评审与交接环节，原型往往需要与方案说明、评审意见和结论放在一起管理。ONES 的文档与工作项协作能力可以承载这类过程：把原型说明和评审记录沉淀在文档中，将待修改项转为工作项跟踪状态，评审结论明确后再进入下一轮方案确认。这样原型不只是一份演示材料，而是方案讨论、问题跟踪和结论流转的共同依据。
常见问题
产品原型做到什么精细程度比较合适？
精细程度取决于当前要讨论的问题。方案方向尚未确定时，用草图或线框图讨论页面结构和流程，参与者更容易聚焦在方案本身；方案基本确定、需要验证具体操作体验时，再做到可点击原型或高保真交互稿。一个实用的判断是：如果评审中大家开始讨论配色和间距，而结构与流程问题还没结论，说明当前原型的精细度超前了。
原型评审时，产品、设计、开发各自应该关注什么？
原型评审的目标是让不同角色针对同一份材料对齐理解。产品侧重点在方案是否说清业务目标、流程是否完整、状态与异常是否覆盖；设计侧关注信息层级是否合理、交互意图是否明确；开发侧关注流程中是否存在实现上的歧义或未定义分支。评审中顺带讨论视觉方向或需求细节属于正常协作，但结论应分别落到对应环节，避免在原型阶段就把视觉定稿和需求质量判定一并处理完。
原型和需求文档需要同时存在吗？
两者回答的问题不同，通常互为补充。需求文档描述要做什么、规则是什么、边界条件如何定义；原型把方案形态可视化，让团队看到页面怎么组织、流程怎么走。只写文档，讨论容易停留在文字理解差异上；只做原型，规则和边界条件可能缺少明确表述。实际项目中可以根据方案复杂度调整两者的详略，但关键规则和关键流程都应有明确载体。
原型评审中发现的修改项，怎样跟踪到关闭？
评审记录和修改项需要留痕，否则下一轮讨论容易重复同样的问题。常见做法是把原型说明和评审意见放在同一份文档中，将待修改项转为可跟踪的工作项，明确负责人和状态，评审结论确认后再进入下一轮方案。ONES 的文档与工作项协作能力可以承载这类过程，把评审记录沉淀在文档中，将待修改项转为工作项跟踪状态。这样原型不只是一份演示材料，也是方案讨论和结论流转的共同依据。
低保真原型会不会显得不够专业？
原型的价值在于帮助团队把方案说清、走通，画面精细度本身不构成专业与否的标准。低保真原型修改成本低，适合在方向探索阶段快速试错；当讨论进入具体操作细节时，再提高保真度。把精细度与讨论阶段匹配，比一味追求高保真更能推进方案收敛。
