做原型的这几年我最大的体会是大多数失败的原型不是做砸了而是做错了。做太细把原型当成缩小版产品来打磨做太糙糙到测试者根本不知道自己在看什么。这两种极端我都见过自己也都踩过。后来我才慢慢想明白一件事——原型不是产品也不是模型它本质上是一个工具是用来回答某个具体问题的工具。它唯一的目的是让你在投入大量资源之前用最小的成本验证这个想法到底靠不靠谱。这篇内容我想把我这些年做原型的方法、材料选择、测试节奏和踩坑经验完整梳理一遍。不管你是刚入行的产品设计师、准备做硬件的创客还是想用原型说服投资人和团队的创业者这篇应该都能给你一些可复用的思路。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 最后一件事原型做完别忘了庆祝它的死亡这个说法听起来有点奇怪但我觉得这是一件很有仪式感的事。当原型完成了它的使命不管是成功验证了核心假设还是证明了这个想法不可行都要给参与的人一个明确的信号这个原型已经完成了它的生命周期。值得庆祝的不只是产品获得了用户认可更包括我们通过原型的帮助在没有耗费巨额资源的前提下发现了一条路走不通。这本身就是原型最大的价值。养成了这套做原型的习惯之后我最大的变化是拿到任何一个新想法第一反应不再是这个东西怎么做出来而是我最需要先搞清楚哪个问题。搞清楚这一点原型怎么做、用什么材料、花多少时间一切都有了判断标准。希望这篇内容也能帮你建立属于你自己的原型判断标准。