做原型的这几年，我最大的体会是：大多数失败的原型，不是做砸了，而是做错了。做太细，把原型当成缩小版产品来打磨；做太糙，糙到测试者根本不知道自己在看什么。这两种极端我都见过，自己也都踩过。后来我才慢慢想明白一件事——
原型不是产品，也不是模型，它本质上是一个工具，是用来回答某个具体问题的工具。它唯一的目的，是让你在投入大量资源之前，用最小的成本验证"这个想法到底靠不靠谱"。这篇内容，我想把我这些年做原型的方法、材料选择、测试节奏和踩坑经验完整梳理一遍。不管你是刚入行的产品设计师、准备做硬件的创客，还是想用原型说服投资人和团队的创业者，这篇应该都能给你一些可复用的思路。
1. 做原型前，先想清楚它到底要替你回答什么问题
很多人拿到一个想法就急着打开Figma开始画界面，或者冲到3D打印机前开始建模，这是完全把顺序搞反了。原型的价值不在于"做出来"，而在于"做出来后能知道什么"。在你动手之前，最该做的一件事是：把"我想验证的东西"翻译成一个具体的、可以被观测的问题。
1.1 原型的本质是验证工具，不是产品的缩小版
我比较喜欢用"实验装置"这个词来形容原型。就像做化学实验之前，你得清楚自己要验证什么反应，再决定烧杯里放什么试剂，做原型也是一个道理。原型是用来回答问题的装置，问题不同，装置的选择就完全不同。
举个例子，你想做一个智能花盆，核心卖点是可以自动检测土壤湿度然后提醒用户浇水。这里至少有三种完全不同的问题可以验证：
- 技术可行性：那个湿度传感器装进花盆里，读数到底准不准？
- 用户体验：用户拿起手机看到"该浇水了"的推送，能不能立刻理解并完成操作？
- 市场价值：一个会因为缺水而"喊"你浇水的花盆，用户觉得自己需要吗？
这三个问题的验证方式完全不同。第一个问题，你可能只需要一块树莓派、一个湿度传感器和一堆土，连外壳都不用做。第二个问题，你需要一个能点按的App界面，花盆本体用一个纸杯替代都没问题。第三个问题，某种程度上连原型都不需要做，做个短视频或者一张渲染图，拿给目标用户看他们的反应就行。
1.2 把"想法"拆解成"可验证的假设"
我自己习惯用一个简单的句式来拆解："如果（我做了某个功能），那么（目标用户）会（产生某个行为或反馈），因为（某个理由）"。
把这个句式填完整，你再去想原型怎么做，思路会清晰很多。比如"如果我在花盆上加一个红色提醒灯，那么忙碌的制作工会立刻注意到植物缺水，因为红色在他们扫视整个桌面的瞬间最容易跳出来"。验证这个假设，你需要的是把灯装的足够显眼，而不需要把整个产品做出来。
这里有一个关键技巧：一个原型最好只验证一个核心假设。如果你把三四个假设都塞进一个原型里，最后测试出来有任何问题，你根本分不清是哪个假设错了。我曾经见过一个团队做智能音箱原型，验证了音质、语音识别、内容源合作和外观设计四个东西，最后项目失败，连复盘都不知道从哪一步开始复盘。做原型一定是一次实验只动一个变量，这样结果才可解读。
1.3 谁在什么场景下使用，决定了原型的形态
同样是验证"浇水提醒"这个功能，给经常出差的商务人士看，和给全职在家的园艺爱好者看，要做的原型完全不一样。前者可能根本不会注意到手机通知，你需要验证的是"设备本身能不能在物理层面引起他的注意"，比如灯光闪烁或者声音提醒。后者则可能是会主动打开App查看植物状态的人，你要验证的是App里数据展示得够不够直观。
所以做原型前，我强烈建议你把"目标用户是谁"和"使用场景是什么"写在便利贴上贴在电脑屏幕边上，时刻提醒自己。原型是拿给特定的人、在特定的场景下用的，脱离使用场景去设计原型，做出来的东西往往是自我感动。
2. 原型分层：从纸面草图到高保真可点按，每一层都有明确的出场时机
很多教学帖把原型分成低保真、中高保真、高保真，然后告诉你哪个阶段用哪种。道理没错，但执行的时候，我见到的真实情况是：有人从头到尾只做低保真，导致给老板汇报时被质疑"你们就做了个这？"；也有人一上来就直奔高保真，结果改一个按钮改到半夜。
原型的"保真度"本质上是一个光谱，没有非黑即白的标准。但有一个原则是确定的：保真度要和你要验证的问题匹配，也要和你沟通的对象匹配。
2.1 四层原型地图，以及每层适合验证什么
我把做原型的实践分成四层，前端后缀，后面附上每层的核心用途：
| 层级 | 表现形态 | 核心验证对象 | 制作耗时 | 典型使用对象 |
|---|---|---|---|---|
| 纸面原型 | 手绘卡片、便利贴、线框草图 | 信息架构、核心流程是否通顺 | 几十分钟 | 项目组成员、早期用户 |
| 低保真数字原型 | 灰度线框图、不完美布局 | 流程逻辑、功能优先级 | 半天到一天 | 项目组、种子用户 |
| 中高保真原型 | 带视觉稿、基础交互、可点按 | 可用性、操作流程、视觉方向 | 两三天 | 内部评审、可用性测试用户 |
| 高保真原型 | 接近成品的视觉和交互，真实数据 | 用户真实反馈、开发可行性、投资人沟通 | 一周以上 | 投资人、管理层、开发团队 |
这里我要专门说一下中间两层的区别。纯灰度的低保真原型，最大的价值在于"让讨论聚焦在逻辑而不是样式上"。你画一个灰色的方块，大家讨论的是"这个按钮放在这里合不合理"，而一旦你把按钮涂成了渐变色还加了阴影，大家的注意力立刻就跑到"这个颜色真好看/真难看"上面去了。这不见得是坏事，但如果你还没确定信息架构就急着上视觉，等于跳过了逻辑讨论直接进入装修环节。
2.2 低保真是用来"思考"的，高保真是用来"说服"的
我经常说一句话：低保真原型首先是给自己用的，其次才是给别人看的。做低保真的过程中，你其实是在逼自己把脑子里模糊的想法具象化。一个流程你觉得自己想明白了，画出来才发现这中间缺了一步；一个信息层级你觉得已经清晰了，写出来才发现主次完全颠倒。这种"画着画着发现问题"的体验，是低保真原型真正不可替代的价值。
而高保真原型，核心价值在于"跨越想象力的鸿沟"。绝大多数普通人看到灰不溜秋的线框，脑子里是没法自动补完最终效果的。但如果是设计师自己团队内部，看线框图就能理解，为什么还要花三天去做高保真？反过来，你要向投资人或公司管理层汇报，他们一个小时内要看完十来个不熟悉的项目，你让他们盯着线框图想象产品形态，基本等于自杀。高保真原型能让他们在最短时间内建立起对产品的认知，甚至产生"拥有它"的感觉。
2.3 保真度提升的顺序：先横向铺满，再纵向加深
新手最容易犯的错误，是在一个功能上死抠细节，把第一个页面做到极致，然后其他全是空的。测试的时候一点别的按钮就弹出一个"功能开发中"的提示，整个测试过程瞬间垮掉。
我的做法是先横向铺满，再纵向加深。先把涉及核心流程的所有关键页面都做成最简单的线框版本，保证用户可以从入口一路点到底，中间不断链。然后回头对核心流程中的关键节点做保真度提升，把视觉、动效、文案逐一补全。这样做的好处是，原型始终是"完整"的，它给你的测试对象一个完整的体验心智，即使细节不完美，用户至少能理解整体的产品逻辑。
3. 动手做第一版原型：75分钟做出可以测试的交互雏形
经常有人问我，"我完全没做过原型，第一版该怎么做？"我的回答永远是：别学完一堆方法论再做，直接动手，做完一版再学。这里我分享一个我常用的"75分钟快速原型"流程，适用于软件产品、App或者Web工具的交互原型。以Figma为例，但方法论完全通用。
3.1 拆功能清单和用户任务：前15分钟
打开空白画布之前，先拿一张纸，写下这个产品要帮用户完成的一个核心任务，注意是一个，不是所有。比如"让新用户在三分钟内完成注册并成功创建第一个项目"。
然后围绕这个核心任务列出功能清单。清单要克制，只列服务于这个任务的最小功能集合。想加更多功能的冲动先忍一忍，第一版原型越瘦，测试结果越干净。这个环节就是逼你做出取舍：什么功能是必不可少的，什么功能只是锦上添花，什么功能是你自己脑补出来的。
3.2 画关键页面线框：接下来20分钟
打开Figma（或者其他你顺手的工具），按照功能清单画出核心页面的低保真线框。这里有三条我总结的规则：
- 用系统自带的矩形、文字和基本组件，不要花时间做间距对齐和视觉美化，这个阶段"丑"是正常的，丑证明你在快速迭代而不是在抠细节。
- 一个页面只保留一个核心动作，比如首页的重点是"新建项目"，那么页面上就该只有这一个显眼的主按钮，其他全是配角。
- 把页面命名规范写好，比如"01-home"、"02-create-project"、"03-success"，方便后面做交互连线时识别。
3.3 连接交互流程：再花25分钟
线框画完之后，进入Figma的Prototype模式，把每个页面的跳转关系用连线连起来。这是整个原型从"图"变成"产品"的关键一步。
我的建议是只连接主流程，也就是核心任务对应的那一整条路径。分支流程、错误提示页、空状态页，第一版都不用做。测试的时候带一句"这里我们省略了"，完全不影响测试效果。给交互加上最简单的转场效果，Figma里用"Smart Animate"或者默认的"Instant"都可以，但不要花时间调缓动曲线和动画参数。目标只是让跳转看起来不那么生硬，让测试者能理解"我点击了按钮，所以来到了新页面"。
3.4 模拟真实数据填充内容：最后15分钟
这一步很多人会忽略，但我觉得它对测试效果的影响巨大。把原型里的占位文本（Lorem ipsum）替换成接近真实场景的文字内容。假如你做的是一个外卖App原型，不要写"商品名称"三个字，而是写"黄焖鸡米饭"，价格写"¥28"，配送时间写"35分钟"。用户测试时，只有看到这些具体的、符合预期的文字，才能把自己代入真实的使用场景，给你有价值的反馈。
如果你做的是数据类产品，这一步就更加关键。一个空的图表组件根本没法让用户感知"这个统计报表好不好用"，你得填上几组看起来像真的数据。Figma里有现成的图表插件，选一个简单的样式放进去就好，同样不需要在细节上花太多时间。
3.5 75分钟原型的边界：该砍就砍
75分钟到点之后停手，哪怕感觉还有很多可以优化的地方。第一版原型的目标不是惊艳任何人，是让你有机会尽快把它拿去给别人看。你可以优化，但一定是基于别人的反馈去优化，而不是基于你脑内的想法去优化。
注意：这个75分钟不是死板的倒计时，更多是对"快速起步"的四步划分。真正熟练之后，你会形成自己的节奏，有些人15分钟就能出草图，有些人则需要一整天。重要的是掌握"拆功能—画线框—连流程—填数据"这个顺序，不要因为细节而停下来。
4. 硬件类原型的材料与工艺选择：3D打印、手板、以及临时搭建的判断逻辑
前面讲的都是软件交互原型，但"Prototyping"这个词在硬件圈同样高频出现。如果你要做的是智能硬件、消费电子或其他实体产品，上面那套方法逻辑依然适用，但材料工艺的选择变得格外有存在感。这一章总结一下我这些年做硬件原型的选择思路。
4.1 按验证目标选材料：功能验证和外观验证是两条路线
硬件原型最常见的错误，是上来就花几千块钱去找手板厂做CNC加工，做出来一个精致的模型，结果一开机发现内部结构根本装不下电池。
这个问题背后是混淆了两个完全不同的验证目标：
- 功能验证原型：重点在于证明电路、传感器、机械结构能工作。外壳的精致程度完全不重要，甚至经常不设计外壳，直接用开发板加杜邦线和热熔胶搭在一起。丑到惨不忍睹都没关系，只要功能能跑通就行。
- 外观验证原型：重点在于验证产品的外形、握持感、视觉观感是否符合预期。内部的电路用一块配重代替，只要能模拟出真实的重量和手感，内核是什么样根本没人关心。
第一次做硬件原型的人，我给你的建议是：先做功能验证，再做外观验证，不要试图一步到位。功能都没跑通，你花大价钱做出来的漂亮外壳，最后大概率要因为一个接口位置不对而整个推翻重做。
4.2 3D打印、手板加工和"临时材料"的选择逻辑
确定了验证目标之后，再来看用什么工艺和材料。这里放一张我常用的选择参考表：
| 材料工艺 | 成本 | 制作周期 | 适合验证的内容 | 不适合的情况 |
|---|---|---|---|---|
| 纸板、泡沫、黏土 | 极低 | 按小时计 | 整体尺寸、基本形态、人机交互手感 | 功能验证、精细细节 |
| FDM桌面3D打印 | 低 | 几小时 | 装配结构、结构尺寸、初步手感 | 外观精细度、强度要求高的部件 |
| 光固化3D打印 | 中 | 一天内 | 外观造型、表面细节、小尺寸精密件 | 大尺寸模型、长时间光照环境 |
| CNC手板 | 高 | 3-7天 | 接近量产的外观质感、结构强度测试 | 快速迭代、多次修改的情况下 |
| 硅胶翻模小批量 | 中高 | 一周左右 | 小批量用户测试、色彩和材质验证 | 结构复杂的内部件 |
FDM打印是硬件原型里的主力，因为成本低速度快，适合快速迭代。但要注意FDM的层纹和表面粗糙度问题，这会影响装配精度——因为层纹导致两个零件卡不住的情况我碰到过太多次。如果你需要验证的是"两个零件能不能拼在一起"，我建议把打印速度调慢一点，并且预留0.2-0.3毫米的配合间隙。
光固化3D打印的表面质量好很多，适合做外观原型，但树脂件比较脆，不适合做强度测试。我见过有人拿光固化打印的外壳做跌落测试，结果外壳碎成渣，这完全是选错了工艺。而CNC手板精度和强度都非常好，外观接近量产，就是贵、慢，适合在方案基本定型、准备做小批量用户测试那一轮用。
4.3 快速原型中的"临时工程师思维"
做硬件原型的时候，我发现一个有意思的现象：很多背景是软件工程师或设计师的人，会不自觉地用做软件的思维来做硬件，试图把每个零件都做得很规范很精致。但在硬件原型阶段，越"规范"反而越浪费。
这里我想分享一种我称为"临时工程师"的思维方式。所谓临时，就是一切都以能快速验证为首要目标，所有东西都是临时的。固定线路板用热熔胶，比设计一个完美的支架快得多；传感器用双面胶贴在设备表面，比开模做一个固定座快得多；连接线用杜邦线加排插，比焊死在主板上快得多。这些东西看起来很土，但它们的目的是让你在一个下午之内就开始测试，而不是用一个星期先做一个"完美的固定结构"，再开始测试。
当然，这种临时方案到了后面一定要还给"正式方案"，但那是后面的事。原型阶段的土法焊枪，属于你花出去最值钱的成本。
5. 原型测试的节奏与反馈收集：从"顺不顺"到"要不要"的追问梯度
原型做出来，最怕的就是放进抽屉里自己欣赏。它必须拿出去被人用、被人评、被人质疑，不然你前面所有努力白费。但拿给谁看、看的时候问什么、反馈回来怎么处理，这里面有一个值得认真设计的节奏。
5.1 测试前：选对人、说对话
给谁测试，取决于你当前处于哪个阶段。早期验证，找同组的设计师和工程师就够了，他们的价值在于指出逻辑漏洞和工程风险——"这个功能用现有的技术栈实现起来成本极高""这里缺一个状态"。中期的可用性测试，要尽量找目标用户，让他们上手操作，观察他们哪里犹豫、哪里卡住、哪里点了半天找不到下一步。后期给决策者看，目标就变成推动决策——"这个方向可以继续投入"。
测试前有一个话术细节值得注意：不要问"你觉得这个设计怎么样"，太开放式的问题得到的回答往往是泛泛的客套。也不要问"你会不会用这个功能"，用户在有测试者在旁边的时候，几乎一定会给出肯定的答案。我常用的是："如果这是一个真实的产品，当你看到这个页面的时候，你的下一步自然操作会是什么？"这个问题让用户把自己代入真实场景，而不是作为评委点评你的设计。
5.2 测试中的关键词：观察行为而不是收集意见
用户说了什么，往往不可靠，但他怎么做，非常可靠。测试时，我的注意力主要放在三个观察维度上：
- 犹豫点：鼠标悬停超过两秒才点击，说明用户对"这个能不能点"不确定。
- 偏离路径：用户没有按照你预期的流程走，跑到了分支或直接卡住，这是信息架构问题的信号。
- 自主探索：用户主动点击了非主流程的元素，说明那个元素的吸引力超出了你的预期，它的优先级可能需要调整。
每次测试完成后，我会把观察到的现象记录下来。这里我要特意强调一下 — 记录"事实"和记录"猜测"的区别。一个合格的测试记录应该写成这样："用户点击了搜索框，输入了'数据分析'，看到结果后停顿了5秒钟，然后点击了筛选按钮"。而不是："用户似乎对搜索结果不满意，怀疑是搜索算法的问题"。前者是客观事实，后者是你的主观推测。你很可能推测错了。
5.3 测试后：把反馈归类到"继续做、改方向、砍需求"三个桶里
收回来一堆反馈之后，不要一股脑全盘接收去改。我习惯把所有反馈分成三类：
| 分类 | 判断依据 | 处理方式 |
|---|---|---|
| 继续做 | 用户的反应与最初假设一致，行为路径顺畅 | 维持不变，继续深化 |
| 改方向 | 用户能理解产品意图，但操作行为与预期不符 | 调整交互细节或信息架构，重新验证 |
| 砍需求 | 多个用户都表现出完全不理解、无兴趣、甚至反感 | 考虑在本次迭代中剔除该功能 |
这里有个容易踩的坑：被单个用户的一句强烈意见带走。一定记住，原型的测试样本很小，个别人的偏激意见不应该成为你推翻核心设计的理由。我会综合至少三到五名用户的反馈，如果只有一个人说不喜欢，其他人没有提到，那多半是个人偏好问题，优先级放低；如果三个人以上都提到了同一个问题，这个问题才是真正值得重视的。
6. 迭代两三轮之后，你手上的是什么：MVC、概念验证，还是演示道具？
做完第一版原型，测试完，拿到反馈，修改，再测试。这个过程重复两三轮之后，你手上的东西已经和最初的草稿完全不同了。但这时候有一个问题需要认真思考：你手上的这个东西，到底是什么性质的东西？
6.1 三种最终形态，以及它们各自的去处
原型迭代到最后，通常会走向三个不同的方向：
- 概念验证（PoC）：如果原型测试验证的核心假设是"这个技术在工程上能不能实现"，那么当技术问题得到验证后，这个原型的使命就完成了。你不需要再在原型上增加任何UI层面的细节，因为下一站是技术人员根据验证结果去做真正的技术研发。继续打磨这个原型，是在纯浪费钱。
- 可用性测试原型：如果原型是用来验证"用户能不能顺畅完成核心任务"，那么在经过一两轮迭代、核心任务路径已经被证明顺畅后，原型的使命也结束了。下一步是把视觉和开发并行推进，而不是在原型上继续堆功能。
- 演示道具/销售道具：如果你拿这个原型去说服了投资人或客户，并且取得了预期的支持，那么它就是一个成功的演示道具。很多人会犯的错是把这个演示道具当成产品开发的基础，结果发现开发团队照着这个"看起来快要完成了"的原型估工，估出来一个完全离谱的量级。因为高保真原型的外壳底下，没有任何真实的代码或硬件逻辑。
6.2 原型和MVC（最小可行产品）之间的灰色地带
原型和最小可行产品之间的边界，现实中经常是模糊的。很多敏捷开发团队会把高保真原型直接当成MVC的需求文档和开发指导。这里我想说清楚我的理解。
原型的核心特征是"看起来能用，但实际上没有足够的工程实现"，测试对象是用户的心智和行为的反应。而MVC的核心特征是"真实可用的最小功能集合"，要投入真实的开发资源，交付给真实的用户进行真实场景下的使用。从原型到MVC，中间有一道"从模拟到真实"的鸿沟，这道鸿沟跨越得越早、越干净，后面的开发风险越低。
所以我的建议是：当核心假设已经被验证得足够充分，就不要在原型上做"美容式迭代"了。该把问题的焦点转移到"用什么技术栈实现"、"数据模型怎么设计"、"后端API怎么定义"这类工程问题上来了。这时候再做原型，做的应该是开发蓝图的辅助工具，帮助产品经理和开发负责人对齐需求范围，而不是拿来继续做用户测试。
6.3 设定原型的"退出条件"
这是很多团队都忽略的一步。做原型之前，给自己设定一个明确的退出条件，能有效防止原型陷入无限的迭代黑洞。这个条件可以写成："当我们观察到连续五名目标用户在无帮助的情况下，都能在2分钟内完成创建项目的核心流程，这个原型就可以冻结了。"或者以硬件举例："当三台测试设备在连续48小时运行中没有发生任何电路故障，并且装配时间缩短到5分钟以内，原型阶段结束，进入开模阶段。"
有了这个退出条件，你可以大大方方地宣布"原型阶段圆满结束"，然后心无挂碍地进入下一阶段。如果一直没有设定退出条件，你会发现原型的迭代永远没有尽头，因为每次测试你都会发现"还可以更好"的地方，而每一次"更好"都会带来新的期望值，恶性循环。
7. 我在原型制作上踩过的坑和养成的习惯
前面讲了那么多方法论和操作步骤，最后这一章我想说一些更贴近实际操作层面的东西。这些不是课本里的知识点，是我自己真金白银踩出来的教训，以及后来养成的工作习惯。
7.1 最贵的坑：用高保真原型去做早期的逻辑验证
有一年我做一个移动端工具产品，一开始就奔着高保真去做，花了一周做了一版视觉、动效、文案都接近成品的原型。结果给用户一测，发现核心流程的信息架构完全搞错了，我们想让用户先选模式再输入内容，但真实用户的行为习惯是先输入内容再选模式。一周的高保真工作全部推翻重来。
这告诉我一个道理：高保真渲染的只是视觉，不是逻辑。早期验证逻辑和信息架构，用低保真线框图效率是十倍以上。高保真应该在核心逻辑确认之后再进行，它赋予的是视觉表现力，而不是让你发现逻辑漏洞。
7.2 容易被忽视的坑：测试对象的"礼貌偏差"
测试用户是真实的潜在用户，但他们对你这个陌生原型往往会过分礼貌。他们不好意思直接说"这个很烂"，可能会说"还不错，就是这里有一点不太懂"。如果你把这句"有一点不太懂"当成小问题忽略掉，那就大错特错了。我会追问："如果完全没有人教你，你在这个页面上会怎么做？"或者换个说法："如果是你自己花钱下载了这款App，第二天你还会打开它吗？"这种比较尖锐的问题，往往能得到接近真实的回答。
7.3 值得推荐的坑后习惯：给每个原型建一个"决策日志"
这几年我养成一个习惯，对每个原型项目，建一份很简单的文档，记录三列内容：原型里做了哪些设计决策、决策的理由是什么、后来测试发现的结果是什么。时间久了，这份日志就成了我自己的"决策复盘数据库"，每个决策的是非成败都有迹可循。
有一次和同事争一个按钮的位置，我把去年一份类似项目的日志调出来，上面写着"用户测试显示，这个位置的打开率只有23%。"争论立刻结束。数据和记录是最好的说服工具，原型让你在测试中看到问题，决策日志让你在以后每次做类似设计时，不用再从零开始踩一遍坑。
7.4 最后一件事：原型做完，别忘了庆祝它的"死亡"
这个说法听起来有点奇怪，但我觉得这是一件很有仪式感的事。当原型完成了它的使命，不管是成功验证了核心假设，还是证明了这个想法不可行，都要给参与的人一个明确的信号：这个原型已经完成了它的生命周期。值得庆祝的不只是"产品获得了用户认可"，更包括"我们通过原型的帮助，在没有耗费巨额资源的前提下，发现了一条路走不通"。
这本身就是原型最大的价值。
养成了这套做原型的习惯之后，我最大的变化是：拿到任何一个新想法，第一反应不再是"这个东西怎么做出来"，而是"我最需要先搞清楚哪个问题"。搞清楚这一点，原型怎么做、用什么材料、花多少时间，一切都有了判断标准。希望这篇内容也能帮你建立属于你自己的原型判断标准。
