交互原型是用可操作或可演示的界面草案，表达用户在产品中如何操作、系统如何响应、页面之间如何流转的中间产物。它聚焦操作路径、状态变化与反馈，用来支撑产品方案沟通和可用性验证。本文围绕定义、组成、范围边界与相邻概念展开，视觉风格细化和具体需求质量评审不在讨论重点内。
要点总览（TL;DR）
- 交互原型是用可操作或可演示的界面草案，表达用户如何操作、系统如何响应、页面如何流转的中间产物，核心在于操作路径、状态变化与反馈。
- 它覆盖页面结构、交互流程、状态反馈和跳转分支；视觉制作细节、需求质量评审和技术实现方案属于相邻环节。
- 一份完整的交互原型通常从用户任务出发，依次拆出页面序列、界面元素、状态规则和跳转分支，再按真实操作顺序走查。
- 线框图关注结构，视觉稿关注呈现，需求文档关注规则，交互原型关注操作过程；可点击Demo与它重叠较多，差别在目的和保真程度。
- 常见误解是把交互原型当成视觉稿、最终产品或需求评审，导致异常状态无人确认、边界条件遗漏、需求问题迟迟不闭环。
交互原型是什么：一句话定义与核心特征
交互原型（Interactive Prototype）指在产品开发前期，用可点击、可跳转或可演示的界面草案，模拟用户完成任务的过程。它回答的核心问题是：用户从哪里进入、做哪些操作、系统给出什么反馈、下一步去往哪里。与只呈现页面布局的静态图不同，交互原型把“操作—响应—流转”这条链路表达出来，让参与方案讨论的人能够按真实使用顺序走一遍。
理解这个概念，可以抓住三个核心特征：
- 可操作或可演示。交互原型允许点击按钮、切换标签、填写字段、触发弹窗，或者通过演示脚本按预设路径播放流程。操作结果可以是真实跳转，也可以是用示意页面模拟的响应。
- 聚焦操作路径与状态变化。原型重点表达用户完成一个任务要经过哪些步骤，每个步骤界面处于什么状态，例如未提交、提交中、成功、失败、空数据、权限不足等。
- 承载方案沟通与可用性验证。交互原型是讨论材料：产品、设计、研发和业务方可以围绕同一条操作路径确认理解是否一致；也可以让真实用户试走流程，观察哪里犹豫、哪里出错。
需要区分的是，静态线框图主要表达页面信息结构，视觉稿主要表达颜色、字体、间距等呈现效果，交互原型则把重点放在“怎么用起来”。三者可以互相衔接，但回答的问题不同。
交互原型包括什么、不包括什么
交互原型的范围可以用一句话概括：凡是用来表达用户操作、系统响应和页面流转的内容，都属于它的覆盖范围；凡是偏向视觉制作、需求质量判断或技术实现的内容，通常不在其定义范围内。下面用对照表说明。
| 范围类型 | 具体内容 | 说明 |
|---|---|---|
| 覆盖 | 页面结构与界面元素 | 页面有哪些区域、按钮、输入项、列表和提示，元素之间如何组织 |
| 覆盖 | 交互流程与操作路径 | 用户从入口到完成任务的步骤顺序，包括主路径和常见分支 |
| 覆盖 | 状态与反馈规则 | 加载、成功、失败、空状态、禁用、校验提示等界面状态及触发条件 |
| 覆盖 | 页面跳转与分支关系 | 点击某个操作后去往哪个页面，不同条件下走哪条路径 |
| 不覆盖 | 视觉设计制作细节 | 配色方案、字体规范、图标风格、动效参数等属于视觉设计环节 |
| 不覆盖 | 需求质量评审 | 需求是否完整、是否存在冲突、优先级是否合理，属于需求评审范畴 |
| 不覆盖 | 技术实现方案 | 接口设计、数据结构、性能方案由技术设计文档承载 |
低保真与高保真交互原型都属于交互原型。低保真原型用灰框、占位文字快速搭建流程，适合早期讨论操作路径是否合理；高保真原型在界面细节上更接近最终产品，适合验证具体交互反馈和向利益相关方演示。两者保真程度不同，但表达操作与响应的目的相同。
实际判断时可以用一个简单口径：如果一份材料的主要用途是让人“走一遍流程、看操作结果”，它就在交互原型范围内；如果主要用途是“看视觉风格”或“判断需求写得对不对”，则应归入相邻环节。
交互原型怎么运转：从任务到可演示流程的组成
交互原型由若干要素组合而成，形成过程通常从用户任务出发，逐步拆解为可演示的流程。理解这套组成关系，有助于判断一份原型是否表达完整。
组成要素清单
- 用户任务与操作路径。先明确用户要完成什么任务，例如提交一笔报销、修改收货地址、发起一次审批。再把任务拆成若干操作步骤，形成主路径。
- 页面与界面元素。每个步骤对应一个页面或界面状态，页面中包含完成该步骤所需的按钮、输入框、列表、提示等元素。
- 状态与反馈规则。为关键操作定义系统响应：点击提交后显示加载，校验失败时在字段旁提示，提交成功后展示结果页，网络异常时给出重试入口。
- 页面之间的跳转与分支。明确每个操作触发后去往哪里，以及在不同条件下走不同路径，例如审批通过进入下一节点，驳回则回到发起人修改。
组合顺序
形成可演示流程一般按以下顺序推进：先确定任务目标和成功标准，再画出主路径的页面序列，然后为每个页面补充关键元素和状态，接着连接跳转关系并标注分支条件，最后按真实操作顺序走查一遍，检查是否存在断点、死路或缺失反馈。走查通过后，这份原型就可以用于方案沟通或用户测试。
在团队协作中，原型往往需要与方案说明、评审记录放在一起管理。以ONES为例，产品方案文档可以在ONES文档中编写并与工作项关联，评审中发现的交互问题可以转为工作项跟踪处理，使原型讨论的结论有明确的承接位置。这一衔接适用于需要把方案沟通与后续跟进放在同一协作环境中的团队。
交互原型与线框图、视觉稿、可点击Demo的区别
交互原型常与几个相邻概念一起出现，混淆会导致沟通时各说各话。下表按关注点和用途做同口径对比。
| 产物 | 主要表达什么 | 典型用途 | 与交互原型的关系 |
|---|---|---|---|
| 线框图 | 页面信息结构与元素布局，通常不含操作反馈 | 讨论页面应放哪些内容、如何分区 | 交互原型常以线框图为基础，再补充操作与状态 |
| 视觉稿 | 颜色、字体、间距、图标等视觉呈现 | 确认视觉风格与品牌一致性 | 视觉稿解决“看起来怎样”，交互原型解决“用起来怎样” |
| 可点击Demo | 接近最终产品的可点击演示，保真度通常较高 | 对外演示、汇报、用户测试 | 可点击Demo可以是交互原型的一种呈现形式，目的偏向展示与验证 |
| 需求文档 | 用文字和规则描述需求背景、范围与验收条件 | 记录需求内容，作为开发和测试依据 | 需求文档说明“要做什么”，交互原型演示“怎么用”，两者互相补充 |
区别的关键在于关注对象不同：线框图关注结构，视觉稿关注呈现，需求文档关注规则描述，交互原型关注操作过程与系统响应。可点击Demo与交互原型重叠较多，差别主要在目的和保真程度——前者偏演示展示，后者偏方案推演与验证。实际项目中这些产物经常交替使用，明确当前讨论的是哪一层，能减少无效争论。
一个具体例子与常见误解
以一个审批流程为例。假设员工要在内部系统中发起一笔费用申请。交互原型会这样表达：员工从首页进入“费用申请”入口，填写金额、事由并上传凭证；点击提交后按钮进入加载状态，校验不通过时在对应字段下方提示原因；提交成功后展示申请单号和当前审批节点；审批人收到待办，进入详情页可以选择通过或驳回，驳回时必须填写意见；申请人再次进入时看到“已驳回”状态和修改入口，修改后重新提交。整个原型覆盖了发起、校验、提交、审批、驳回、重提这条主路径及关键分支，评审时可以按顺序走一遍，确认每个状态是否有明确反馈。
围绕这个例子，常见的误解有三类：
- 把交互原型等同于视觉稿。讨论时纠结配色和间距，导致操作路径和异常状态没人确认。结果是流程走到开发阶段才发现缺少失败提示或返回入口。
- 把交互原型等同于最终产品。认为原型上能点通就等于功能已经确定，忽略原型中的示意数据和简化逻辑。开发按原型字面实现，容易遗漏边界条件。
- 把交互原型评审等同于需求评审。原型评审适合确认操作路径、状态反馈和页面流转；需求是否完整、优先级是否合理、验收标准是否清晰，属于需求评审的内容。两者混在一起，容易出现原型改了很多轮、需求问题仍未闭环的情况。
把这三类边界说清楚，交互原型才能真正发挥方案沟通和可用性验证的作用：讨论时聚焦操作与反馈，评审结论有明确记录，后续修改有对应的工作项承接。
常见问题
低保真和高保真交互原型，团队应该先做哪一种？
两者表达操作与响应的目的相同，差别在界面细节的完成度。早期讨论操作路径是否合理时，低保真原型用灰框和占位文字就能快速搭出流程，修改成本低，适合先跑通主路径和关键分支。当操作路径基本稳定、需要验证具体交互反馈或向利益相关方演示时，再提升到高保真。实际项目中也可以只对核心流程做高保真，其余页面保持低保真，把精力放在最需要确认的环节。
交互原型评审和需求评审能不能合并成一次会议？
可以安排在同一次会议中，但讨论对象要分开。交互原型评审确认的是操作路径、状态反馈和页面流转是否合理；需求评审判断的是需求是否完整、优先级是否合理、验收标准是否清晰。合并时建议先走一遍原型流程，再逐条核对需求内容，并分别记录结论。两类问题混在一起讨论，容易出现原型改了很多轮、需求问题仍未闭环的情况。
原型上能点通，是否意味着功能已经确定可以进入开发？
原型能点通说明操作路径和页面流转已经表达出来，功能是否确定还要看需求规则、边界条件和验收标准是否明确。原型中常使用示意数据和简化逻辑，例如固定金额、跳过异常分支、省略权限判断。进入开发前，需要把原型未覆盖的异常状态、数据校验规则和权限条件补充到需求文档中，避免开发按原型字面实现而遗漏边界情况。
交互原型做完后，评审中发现的交互问题应该怎么跟进？
建议在评审时就把问题记录成可跟踪的条目，注明所在页面、触发条件和期望的反馈，而不是只写在会议纪要里。问题转为工作项后，可以指定负责人、设定处理状态，并在原型更新后回看是否闭环。以ONES为例，产品方案文档可以在ONES文档中编写并与工作项关联，评审中发现的交互问题可以转为工作项跟踪处理，适合需要把方案沟通与后续跟进放在同一协作环境中的团队。
面向外部用户做可用性测试时，用交互原型还是可点击Demo更合适？
取决于测试目的和所处阶段。想验证操作路径是否顺畅、用户在哪里犹豫或出错时，中等保真的交互原型就够用，界面细节少一些反而能让用户把注意力放在流程上。需要接近真实产品的观感、测试视觉引导或对外演示时，可点击Demo更合适。无论选哪种，测试前都要明确任务脚本和观察指标，并说明哪些响应是示意模拟，避免参与者把原型当成已上线功能。
