第三章：原型的力量——低保真原型 vs 高保真原型，什么时候该用哪个？

说实话，原型这件事，我见过太多团队走极端了。

有的团队一上来就搞高保真，花了两周画了个跟真的一样的界面，结果需求一改，全废了。有的团队呢，永远拿几张纸片跟客户聊，客户看完一脸懵，最后说「你们做出来再说吧」。

这两种我都踩过坑。今天咱们就聊聊，低保真和高保真，到底该怎么选。

什么是低保真原型？

说白了，就是「能看就行」。

低保真原型通常是用手绘、白板、或者简单的线框图工具做的。它不关心颜色、字体、图标好不好看，只关心一件事：信息结构和交互流程。

我记得有一次，一个创业团队找我帮忙看他们的产品。他们花了两周做了个高保真原型，颜色、动效、甚至加载动画都做了。结果我一问核心流程，他们自己都说不清楚。这就是典型的「用高保真掩盖了逻辑缺陷」。

什么是高保真原型？

高保真原型，就是「看起来像真的」。

它包含了真实的颜色、字体、间距、图标，甚至还有交互动效。用户点一个按钮，真的会跳转到下一个页面。说白了，它跟最终产品就差一行代码了。

什么时候用低保真？

我个人习惯，在项目的前期阶段，一律用低保真。为什么？

1. 需求还在「流动」的时候

你想想看，需求都没定下来，你花三天画个高保真，客户说「这个按钮放左边吧」，你改起来多痛苦？低保真就不一样了，白板上画两笔，橡皮一擦，完事。

2. 需要验证核心逻辑的时候

我在项目中遇到过，团队花了两周做高保真，结果用户测试时发现核心流程走不通。为什么？因为高保真太「真」了，测试者都在关注好不好看，没人关注逻辑对不对。低保真反而能逼着大家关注「这个页面该有什么」「下一步该去哪」。

3. 团队内部沟通的时候

开发看高保真，第一反应是「这个圆角能不能小一点」「这个阴影实现不了」。但如果你拿低保真去聊，大家讨论的是「这个功能要不要」「这个流程对不对」。这才是早期该聊的事。

什么时候用高保真？

高保真不是不能用，而是要用对地方。

1. 做用户可用性测试的时候

低保真测试，用户会说「嗯，这个想法不错」。高保真测试，用户会说「这个按钮我点不到」「这个字太小了」。你想想看，哪个反馈更有价值？

2. 向客户或老板汇报的时候

这个我深有体会。有一次我拿低保真给客户看，客户说「你们这做的什么玩意儿？」后来我换了个高保真，同样的功能，客户说「嗯，这个不错」。说白了，高保真能降低沟通成本，让非专业人士更容易理解。

3. 开发前做最终确认的时候

开发要开始写代码了，你总不能拿张手绘图给他吧？这时候高保真就是「最终规格」，开发照着做，测试照着测，谁也别扯皮。

一个简单的决策表

场景	推荐原型类型	原因
需求探索阶段	低保真	快速试错，低成本验证
内部逻辑评审	低保真	聚焦功能，不被视觉干扰
用户可用性测试	高保真	获得真实操作反馈
客户/老板汇报	高保真	降低理解门槛，提升信任感
开发前最终确认	高保真	作为开发规格，减少歧义

我的实战经验：一个「先低后高」的案例

之前我带一个团队做电商App。一开始，我们用白板画了所有页面的线框图，跟产品经理、开发一起过了三遍流程。改了很多地方——比如结算流程从三步改成了两步，商品详情页的布局也调了。

这些改动，在白板上就是几分钟的事。

等流程确认了，我们才开始做高保真。这时候高保真就是「照着画」了，几乎没有返工。整个原型阶段，我们只花了一周时间，但效果比之前花三周做高保真的好得多。

嗯，这里要注意：先低后高，不是先做低保真再做高保真，而是先用低保真把逻辑跑通，再用高保真把细节定下来。

避坑指南

我曾经犯过一个错：给客户看低保真的时候，客户说「没问题」，结果开发到一半，客户说「这不是我要的」。后来我才明白，客户看低保真，根本想象不出最终效果。所以我现在有个习惯：给客户看的东西，至少要做到「看起来像个产品」。

反过来，我也见过团队给开发看高保真，开发说「这个做不了」。为什么？因为高保真里有些效果，比如复杂的动效、自定义控件，开发实现成本很高。所以，高保真做到什么程度，最好提前跟开发沟通一下。

好了，这一章就聊到这儿。下一章咱们聊聊「需求优先级：怎么从一堆需求里挑出最重要的那个」。到时候见。