原型设计
1. 导读
在很多项目里，客户说"能不能先做个原型看看"，其实想看的是一套漂亮、完整、接近上线效果的高保真界面。产品经理说"我们先拉个原型评审一下"，可能想要的是把流程串起来，看看有没有漏页面。设计师说"我做了一个原型"，可能是几张线框图，也可能是一个能点击、能跳转、带动效和真实数据的交互稿。研发看到"原型"两个字，有时会以为它已经代表最终需求。
同一个词，四类人听出了四种意思。于是原型还没开始验证，先制造了误会。
原型要重新放回它本来的位置：把还没说清的方案拿出来试一试。它的价值不在于提前交付一个假成品，而在于让团队用尽量小的代价看见一个关键风险。
比如一个政务预约团队想改办事流程。团队可以先画一整套精致页面，但如果真正的疑问是"用户到底先选事项、先选时间，还是先确认材料"，几张纸面卡片加一次任务走查就可能暴露问题。相反，如果团队要验证预约失败后的补救路径，静态线框图就不够，因为用户必须真的经历号源被占、材料不足、重新选择时段和保留已填信息的过程。
原型的关键，是判断"哪一部分需要真实到足以暴露风险"。保真度，Fidelity，指原型与最终产品在视觉、交互、内容、数据和系统行为上的接近程度。高保真不等于高质量，低保真也不等于粗糙。一个画在纸上的预约流程，如果能让团队发现用户会在材料清单前后顺序上走错，就比一套没人敢修改的精致演示稿更有价值。
2. 核心问题
原型到底是什么？它不是最终产品，也不一定是高保真界面，而是用于沟通、探索、验证和交付说明的方案表达。原型要回答什么问题？有时它只需要覆盖三步任务、两个异常和一个关键状态，因为真正要验证的不是页面数量。而是用户会不会在那几步里误解、停住或走错。低保真、中保真、高保真原型如何选择？判断依据不是团队习惯用哪种工具，而是当前最怕看不见什么：概念误解、流程断点、交互细节、数据判断，还是上线承诺。同时还要问：交互原型、服务原型和数据原型有什么不同？交互原型验证用户与界面的行为路径，服务原型验证跨触点和前后台交付，数据原型验证信息、算法输出、报表和决策支持是否可理解。原型如何与研发协作？原型不能替代需求说明、状态规则、异常逻辑和验收标准，但可以帮助团队提前看见复杂状态和边界流程。原型如何验证？验证时不要只听用户评价页面，而要看他能否完成一段接近真实的任务：是否理解规则，是否点错，是否知道失败后怎么回来。原型的商业价值如何表达？它通常不是直接创造收入，而是降低误解、减少返工、提前发现风险、提高方案决策质量。
3. 关键概念与定义
原型
原型，Prototype，是用于表达、沟通、测试和迭代设计方案的早期模型。IxDF 将原型理解为模拟产品设计和功能的早期模型，用于测试概念、收集反馈并在最终开发前迭代。
这个定义里最重要的词不是"模型"，而是"测试"和"迭代"。原型不是用来证明设计师已经想好了，而是让团队提前发现：哪条规则没人解释，哪个状态没人处理，哪个判断还只是猜测。
挂号机、短信、导诊台、医生叫号、缴费窗口都先走一遍。演练不等于正式服务，但它能让团队在真正的用户排队之前发现"短信没说带医保卡""导诊台不知道异常号源怎么处理"这类问题。
保真度
保真度指原型与最终产品在视觉、交互、内容、数据和系统行为上的接近程度。
低保真原型通常更快、更便宜、更容易修改，比如纸面草图、白板流程、线框图。它适合早期探索结构、流程和概念。
中保真原型通常已经有比较清楚的结构和基本交互，但不追求最终视觉效果。它适合测试关键流程、页面跳转和信息布局。
高保真原型在视觉、内容、动效和交互上更接近成品。它适合测试接近真实的操作体验、关键交互细节、利益相关者沟通和开发交付说明。
保真度不是一条"低到高"的进度条，而是一组可选择的表达维度。一个原型可以视觉很粗糙，但使用真实订单状态；也可以界面很精致，却只有顺利跳转。真正要问的是：这次最危险的假设藏在哪个维度，那里是否需要更接近真实？
交互原型
交互原型用于模拟用户与界面之间的行为。它可以让用户点击按钮、切换页面、打开弹窗、触发错误、看到反馈。
Figma 官方帮助文档说明，原型可以用于预览交互和用户流、分享和迭代想法、获得协作者反馈、与用户测试交互、向利益相关者展示设计。 这类工具文档不能证明某种方法必然有效，但能说明现代数字产品原型常见的实践方式。
服务原型
服务原型用于模拟跨触点服务如何被交付。
比如医院预约挂号不只是一个页面。用户在线上预约、收到短信、到院取号、现场等待、被叫号、医生接诊、缴费、取药，每一步都可能影响体验。服务原型可能包括页面、短信话术、现场指引、工作人员脚本、后台操作和异常处理。
服务原型的重点不是"界面能不能点"，而是"服务能不能被真实交付"。
数据原型
数据原型用于验证数据展示、指标解释、算法输出、报表逻辑或 AI 结果是否能支持用户判断。
比如一个销售仪表盘，设计师不能只放几个漂亮图表占位。用户真正要判断的是：本月业绩为什么下降？哪个区域异常？是客单价、成交率还是线索质量出了问题？如果原型里全是假数据，用户可能只能评价颜色和布局，无法判断它是否能支持决策。
数据原型不一定需要接入真实系统，但应尽量使用接近真实业务逻辑的数据样本，尤其在报表、风控、运营后台和 AI 产品中。
可测试性
可测试性指原型是否足以让用户或团队验证某个问题。
一个原型如果只能让人说"看起来不错"，可测试性就很弱。一个原型如果能让用户完成任务，让团队观察成败、错误、犹豫和反馈，它的可测试性就更强。
原型设计的第一原则不是"做完整"，而是"让关键问题能被测试"。
4. 概念边界与相近概念区别
线框图只是原型材料之一
线框图主要表达页面结构、信息层级和基本布局。它像建筑平面图，告诉大家房间在哪里、门怎么开、动线大概怎么走。
原型更强调体验模拟和验证。它可能包含线框图，也可能包含跳转、状态、动效、数据、脚本或服务触点。线框图可以是原型的一种材料，但只有能帮助团队测试关键问题时，它才进入原型工作的核心。
高保真只是一种表达选择
高保真设计稿强调视觉、组件、间距、字体、品牌和界面精修。高保真原型可以包含这些内容，但原型的核心仍然是回答问题。
如果团队还没弄清用户任务，却花大量时间做视觉精修，很容易出现"会议里看上去已经完成，测试时才发现方向不对"的假进展。画面越像成品，用户和客户越容易把注意力放到颜色、图片和措辞上，反而不再追问流程是不是走得通、概念是不是理解对。
原型和 MVP 处在不同风险阶段
MVP，Minimum Viable Product，通常译为最小可行产品，是可以进入真实市场或真实使用环境的最小产品版本。原型通常还处在学习和验证阶段，不承诺稳定性、完整逻辑、真实数据和上线运营能力。
一个可点击原型可以帮助团队决定是否做 MVP，但不能替代 MVP。原型验证"这个方案是否值得继续"，MVP 验证"这个产品是否能在真实市场或真实业务里产生价值"。
原型需要和需求说明配合
原型能让需求更直观，但不能替代需求说明。
一个按钮点下去跳到哪里，原型可以表达；但权限规则、字段校验、异常状态、接口失败、审计日志、数据口径、性能约束，通常需要在需求文档、验收标准或技术说明中明确。
很多研发返工并不是因为没有原型，而是因为大家把原型误当成完整需求，结果上线时才发现状态、边界和规则没有定义。
原型要说明承诺边界
高保真原型尤其容易被误解为承诺。客户看到一个精致动效，会以为上线一定如此；销售拿着原型给客户演示，客户会以为这些能力已经接近完成；研发看到组件和数据，可能以为规则已经确定。
所以，原型必须说明边界：哪些是真实逻辑，哪些只是示意；哪些会进入开发，哪些只是探索；哪些数据可用，哪些是占位；哪些交互已验证，哪些仍待确认。
5. 方法、流程或框架
原型设计可以用一个简单流程组织：明确问题、选择保真度、构建最小足够原型、验证、迭代、沉淀决策。
先明确问题。不要从"我要做多少页"开始，而要从"这次最需要提前看见哪种失败"开始。问题可能是：办事用户会不会漏带材料？新手能否完成首次配置？审批人能否识别异常？客服能否按脚本完成服务？研发是否理解复杂状态？
再选择保真度。如果问题是材料顺序和任务概念是否清楚，草图和纸面原型可能就够了。如果问题是用户会不会在流程中走丢，中保真点击原型更合适。如果问题是动效、微交互、移动端手势或真实数据判断，高保真或数据原型才有意义。
然后构建最小足够原型。最小足够不是偷工减料，而是只做足以回答问题的部分。比如验证支付失败恢复，不需要做完整商品详情页、推荐位和会员中心；但必须做支付失败提示、订单状态、重试、返回、联系客服和错误恢复路径。
接着验证。验证可以发生在用户测试中，也可以发生在跨职能评审中。用户测试看任务是否完成、哪里误解、哪里犹豫、哪里出错；跨职能评审看业务规则、开发复杂度、数据依赖、运营流程和风险边界。
原型不是评审通过就结束。团队要记录哪些假设被验证，哪些问题被否定，哪些决策进入开发，哪些结论还需要更多证据。
这个流程与双钻模型的"发展"和"交付"阶段相互呼应。双钻强调在问题空间和方案空间中发散与收敛，原型正是把方案变得可见、可试、可讨论的重要方式。 NN/g 关于研究方法选择的资料也提醒，方法应根据产品阶段、问题类型和研究目标选择，而不是固定套用。1
如何选择保真度
保真度选择可以用三句话判断。
如果团队还在争论"做什么"，先低保真。粗糙一点反而有好处：大家会把它当成待推翻的草稿，而不是已经投入太多的成果。
如果团队已经知道"做什么"，但不确定"怎么走"，用中保真。中保真适合验证流程、页面关系、信息布局和关键交互。
如果团队需要判断"真实使用时会不会出问题"，再高保真。高保真适合验证视觉层级、真实内容、动效、移动端触感、复杂状态和利益相关者展示。
举个例子。一个在线教育产品想增加"错题复习"功能。早期团队还不确定错题应按知识点、时间、考试类型还是错误原因组织，这时低保真卡片和纸面流程就足够。等组织方式基本确定，团队要验证学生能否从错题进入解析、重新练习、标记已掌握，就可以做中保真点击原型。到最后要测试移动端做题的手感、计时压力、答案反馈和视觉层级，再做高保真原型。
如果一开始就做高保真，团队很可能把时间花在颜色、插图和按钮状态上，而真正的问题"学生是按知识点复习，还是按考试错因复习"反而没被看见。
原型计划
一个清楚的原型计划至少包含六件事。
- 要验证的问题：这次原型回答什么，不回答什么。 - 目标用户或评审对象：给用户测试，还是给研发、业务、客服、管理层对齐。 - 原型范围：覆盖哪些任务、页面、触点、状态和异常。 - 保真度选择：哪些维度需要真实，哪些可以简化。 - 验证方式：访谈、可用性测试、评审、走查、服务演练或数据演示。 - 决策出口：验证后如何决定继续、修改、放弃或进入开发。
原型计划越清楚，原型越不容易变成"先多画几页，评审时再说"。
6. 实际工作场景
结账流程：原型验证信任，而不是只验证页面
结账原型经常被做成漂亮的页面串联：购物车、地址、优惠、支付、成功页。但真实风险往往藏在用户看到金额变化之后的那几秒。
用户在结账页看到总价变化，会问：为什么变贵了？服务费什么时候加的？优惠为什么失效？支付失败后我钱会不会被扣？这些问题不是视觉细节，而是信任问题。
这时原型要覆盖费用变化、优惠失效、支付失败、重新支付、订单保留和联系客服。指标可以看用户是否能解释费用、是否能完成支付、是否在失败后知道下一步、是否需要询问测试主持人。
如果团队只做一张最终成功页，原型就绕开了真正风险。
SaaS 新手引导：原型验证首次价值达成
一个项目管理工具的新手引导，不应只验证用户能否完成注册。注册只是入口，真正的价值是用户能否创建项目、添加任务、邀请同事、完成一次状态流转。
原型可以用中保真方式模拟整个首次价值路径。用户进来后是先选择模板，还是先创建空项目？邀请同事应该放在创建任务之前还是之后？如果用户暂时没有同事可邀请，是否还能继续体验？这些问题都可以在原型里提前验证。
这种原型的价值不是提前做出一套像样的界面，而是帮团队检查 Time to Value，也就是用户从开始使用到获得首次明确价值所需的时间。
企业后台：原型验证规则、状态和异常
企业后台的原型不能只画"正常路径"。正常路径往往最简单，真正麻烦的是权限、状态、审批、撤回、重复提交、异常数据和多人协作。
比如人事系统配置新员工权限。原型需要覆盖：不同角色看到的字段是否不同，权限组合是否互斥，提交前是否能预览，提交后是否可撤回，审批被拒后如何修改，配置错误是否会影响入职当天访问系统。
这类原型尤其重要——提前暴露培训成本、支持工单和操作风险。一个后台原型如果只展示首页和列表页，很难说明它已经处理了复杂业务。
服务流程：原型验证前后台能否接上
以家电维修为例：用户在线提交报修，收到预约确认，客服电话核实，师傅上门前通知，现场发现需要备件，用户确认报价，维修后付款和评价。任何一个触点断掉，体验都会出问题。
服务原型适合多触点场景，比如体检预约、维修上门、政务办理、银行开户、售后退换。原型可以把页面、短信、电话脚本、师傅工具、后台派单和异常处理串起来演练，目的是发现哪个环节还没准备好、哪个步骤衔接不上、谁不知道下一步该做什么。
AI 和数据产品：原型验证理解与信任
数据看板、风控系统、AI 助手和推荐系统的原型尤其不能只放占位文字。
假设一个 AI 客服助手会给出退款建议。原型需要让用户看到回答依据、置信程度、可撤销动作、转人工入口和错误恢复方式。如果只做一个"AI 正在输入"的动效，团队无法验证用户是否过度信任、是否理解限制、是否知道何时转人工。
这类原型常常需要"数据保真"。界面可以不精致，但示例数据、异常情况和输出逻辑要接近真实，否则测试只会得到表面反馈。
7. 案例
Figma 原型文档：原型作为协作和测试媒介
Figma 的原型帮助文档不是商业案例，但它是可核查的工具实践资料。团队把一段预约、结账或权限配置流程串成可点击原型后，利益相关者能沿着任务走一遍，用户测试也能观察参与者在哪里停顿、误解和返回。文档说明原型可用于预览交互和用户流、分享迭代、获得反馈、与用户测试交互和向利益相关者展示。
它说明现代数字产品原型已经不只是静态页面，而可以包含流程起点、页面连接、触发方式、转场、覆盖层、滚动、设备预览和分享链接。
Design Council 双钻：原型位于方案探索和交付之间
Design Council 的双钻框架强调从发现、定义，到发展、交付的发散与收敛。 原型通常发生在"发展"和"交付"之间：团队把抽象方案变成可见、可讨论、可测试的形式，再根据反馈收敛。
这个框架能帮助客户理解原型为什么不只是"画图"。它是方案学习机制的一部分。早期原型帮助团队探索可能性，后期原型帮助团队验证可行性和对齐交付。
8. 数据、指标或衡量方式
原型的成效不应该只用"评审通过"衡量。
评审通过只能说明会议里暂时没有人反对，不代表用户能完成任务，也不代表研发没有理解偏差。原型更适合用三类指标观察：任务指标、学习指标和协作指标。
任务指标关注用户能否完成。比如任务成功率、首次成功率、错误率、完成时间、任务后易用度评分。一个报销原型可以观察新员工是否第一次就能提交成功，是否选错费用类型，是否遗漏发票附件，是否需要询问财务。
学习指标关注团队从原型中学到了什么。比如哪些假设被保留，哪些判断被推翻，哪些误解反复出现，哪些流程点必须重做。低保真原型最大的价值往往不是"得分变高"，而是让错误方向在开发投入前露出来。
协作指标关注团队是否减少误解。比如评审问题数、研发返工项、需求澄清次数、状态遗漏数、异常流程补充数。需要注意，这些指标受团队记录习惯影响，不能简单跨团队比较。
原型还可以观察服务和商业间接指标。比如结账原型测试发现用户不理解服务费，未来上线后可以观察支付前流失、客服咨询、投诉和支付失败重试率。但上线后的转化变化仍会受到价格、促销、流量和供给影响，不能全部归因于原型。
一个实用做法是，在原型计划里先写出"本次原型不衡量什么"。比如本次只验证费用说明理解，不衡量视觉偏好；只验证权限配置流程，不衡量系统性能；只验证服务脚本，不衡量真实履约能力。这样可以避免团队拿原型测试结果回答它并没有能力回答的问题。
9. 常见误区
误区 1：原型越高保真越专业
高保真只能说明表达更接近成品，不自动说明问题被验证。过早高保真还可能让团队舍不得修改。
先判断风险在哪，再选择保真度。
误区 2：原型就是给客户看的演示稿
演示只是原型用途之一。原型还应该帮助团队发现用户理解、交互、状态、数据和服务交付问题。
每个原型都写清验证问题和决策出口。
误区 3：只做正常路径
真实产品最容易出问题的地方常常是失败、异常、权限、撤回和恢复。
原型至少覆盖关键失败路径和高风险状态。
误区 4：用原型替代需求说明
原型能表达体验，但不一定表达完整业务规则和技术约束。
进入开发前补齐需求、状态、规则、数据口径和验收标准。
误区 5：用户说喜欢就通过
喜欢不等于能完成任务。用户可能觉得页面好看，却仍然不知道下一步怎么做。
让用户完成任务，观察行为，而不是只收集态度。
误区 6：原型做完就结束
原型的价值在于反馈和迭代。只做不测，只评不改，原型就变成装饰。
记录发现、修改决策和未解决问题。
误区 7：所有项目都必须按低保真到高保真线性推进
有些团队有成熟组件库和清晰模式，可以快速进入中高保真；有些早期探索则应该停在纸面和白板。
按风险和问题选择路径，不把流程当教条。
10. 小结
原型设计的核心，是用足够小的代价，把方案里最不确定的部分变得可见、可试、可讨论。
原型可以是纸面草图、点击原型、服务演练、数据样本、AI 对话模拟，也可以是接近成品的高保真交互。它和线框图、高保真稿、MVP、需求文档都有交集，但目的不同。形式并不重要，重要的是它能否回答关键问题。
从业者的原型设计要从验证目标开始，而不是从工具开始。客户和管理者评审原型要看它是否降低了决策风险、沟通风险和交付风险，而不是只看页面是否精致。
好的原型让团队在用户真正到达之前发现短信、窗口、叫号、缴费和异常处理哪里接不上。
11. 延伸阅读
| 资料 | 推荐理由 | 适合读者 | |---|---|---| | Interaction Design Foundation: Prototypes | 理解原型定义、保真度、低/中/高保真原型和迭代价值 | 设计师、产品经理、学习者 | | Figma: Guide to prototyping in Figma | 理解现代交互原型工具中的流程、连接、起点、交互和分享机制 | 设计师、产品经理 | | Design Council: Framework for Innovation / Double Diamond | 理解原型在方案发散、收敛和验证中的位置 | 设计负责人、管理者 | | NN/g: When to Use Which UX Research Methods | 理解原型验证应按问题、阶段和研究目标选择方法 | 用户研究员、产品经理 | | Intuit Design for Delight | 理解快速实验与客户同理、发散收敛之间的关系 | 设计师、创新团队、管理者 |2
注释
1 Interaction Design Foundation, Prototypes。原型是用于测试概念、收集反馈和迭代的早期模型。 🔗 https://www.interaction-design.org/literature/topics/prototyping
2 NN/g, UX Prototypes。保真度应服务验证目标，低/中/高保真各有适用边界。不等于所有项目必须线性推进。 🔗 https://www.nngroup.com/articles/ux-prototypes/