做产品原型，我想是每个产品经理最普通也最重要的工作之一。为了做好产品原型，很多人会专门学习多个原型工具，努力让自己的产品原型变得更加的精细，我就曾经花了几百块买了一个产品原型制作教程。不过在工作了了几年后，会对产品原型有了新的体会，我觉得产品原型最为核心的不是呈现精细的页面和炫酷的交互，更为重要的是能否借助产品原型与他人互通，达成共识。今天我就来跟大家聊一聊我对产品原型的心得体会，希望对大家有所帮助。
在理解这句话之前，我们先来看一个案例：
汪晨（产品经理）的领导陈璐最近给他安排了一个新任务，让他负责一个全新产品的研发工作。而前期针对这个产品规划的会议（领导会议），汪晨并没有参加。因此这天陈璐把汪晨叫到办公室，跟他谈了一下相关情况。
陈璐：关于这个产品的情况大概就是这样，这里有些资料，你拿回去研究一下。你有一周的时间做产品原型，做完以后我们会和相关的领导沟通一下。
汪晨：好的。那我去准备了。
三天过去了，汪晨也没有找陈璐沟通产品相关的内容。这天陈璐走到汪晨的工位前，询问产品原型的情况。
汪晨：额，一半多了。这个产品真的还挺复杂的，需要想的细节也很多。不过领导放心，我周末会加班做，一定在准时完成。
汪晨说完，得意地笑了笑，但陈璐却变得严肃起来。
陈璐：你刚才说整理了一半多，你打开原型我看一看。
陈璐：汪晨，你的工作态度很不错，但你做的产品原型并不是现阶段我想要的。现在我们是要给公司领导汇报产品解决方案。领导关心的是产品框架、核心流程，至于Banner图如何切换、按钮交互是什么，不是领导关心的。你现在做的产品原型，更适合团队沟通执行的时候用。你来我办公室，我再跟你说一下，回头赶紧重新做一份。
看到这里，大家估计能想到汪晨此时的心情是怎样的，他又是怀着怎样的心情在陈璐办公室聆听“教诲”。有人可能会问，这个结果是谁造成的呢？我觉得主要问题出在汪晨身上。汪晨之所以会犯错的原因主要是三个方面：1.对产品各阶段的沟通重点理解不深刻；2.在与陈璐沟通过程中，没有详细了解相关的要求；3.认为产品整个开发过程只需要一份产品原型。
因为我们今天说的是产品原型，那我们就从产品原型入手，来分析一下。从案例中，可以折射出第一个问题：做产品原型的目的是什么？我想对于这个问题，大家是有共识的。进一步分析，又会发现第二个问题：产品原型是否只需要做一个？从汪晨的遭遇可以清晰地看出，肯定不是，是需要多个的。那问题又来了：到底需要做多少个产品原型，有没有标准的格式呢？关于这个问题，我的体会是做多少个产品原型，格式是怎样的，需要和公司沟通机制相匹配。
产品原型的制作是基于公司沟通机制的不断循环，其中的逻辑关系是，在日常工作中，产品人员做产品原型的驱动力应该是源于外部，然后再利用自己的专业知识对需求进行整理，最终产生产品原型，而新的产品原型又会成为下一次与外部沟通的载体，达成共识以后，再进一步的化完善，如此往复循环。可以说，这个循环的过程，将伴随产品整个生命周期中的沟通工作。
其实我们讨论产品原型的层级，就是在讨论沟通的阶段，毕竟沟通会直接决定产品原型所要表达的内容。至于沟通可以分成几个阶段，我想不同的公司也会有不同的分法，不过我觉得大致都可以分成三个阶段。
框架阶段
通俗的说，框架阶段就是产品初期刚刚立项，或者已有产品要开发全新的模块。这个时候沟通的重点，更多是围绕着产品规划展开的，最终的目标是确定产品的核心流程，换种说法就是确定用户的真实需求。这个阶段的沟通工作将直接决定产品的成败。我相信大家应该听说过或经历过由于前期需求沟通不到位，而导致开发出来的产品不是用户想要的情况，可以说这对产品人员来讲是最痛苦也是最伤士气的事情了。
为了避免这样的情况，就需要重视产品原型的辅助作用。在这个阶段，产品原型可以采用思维导图或者框架图。不过就像我们前面说的，产品原型没有固定的格式，可以采用多种形式，但这个阶段的产品原型必须确保两点：
能够清晰表达产品的核心流程；
与核心用户达成共识。
可行阶段
确定了核心流程之后，产品经理就需要根据核心流程，规划产品的任务流程，简单说就是用户为了解决某一个问题，需要完成那些任务。这些任务需要完整的表达出来，这就需要产品经理做较为细致的产品原型，但这个阶段的目标不是执行，而是一方面细化流程，另外一方面从技术层面评估是否可行。
这里所讲的技术，并非单指产品底层架构、功能实现，而是包括设计、页面等部门的技术评估。例如，领导希望产品能做得很炫酷，并指出可以参考竞品B（B产品是用H5技术实现的），但目前公司内部并没有能够做H5的技术人员。如果在可行阶段及时发现了这一点，我们可以很快地进行重新讨论，但如果到了执行阶段再发现，那项目风险就会很大了。
不过因为这个阶段的沟通不涉及执行，所以原型没有必要把所有的交互效果做出来，只需要页面和重点版块的交互制作出来即可。
执行阶段
到了执行阶段，就是针对具体怎么做的沟通了，因此这个阶段的产品原型一定是高保真产品原型，其中判断是否是高保真原型的重要标准就是：一个用户是否能通过产品原型看到每一个交互细节（涉及到数据的交互可简化处理）。
之所以这样要求，关键原因是开发产品所涉及到的各个部门，都需要依据产品原型制定自己的工作标准。产品原型做得越精细，相应的工作标准就越详细，后期沟通的成本就会越小，进而产品的风险也就越小。
常见的问题
这里我根据自己的工作体会，整理了几个有关产品原型的常见问题，供大家参考。
这个问题就是上面我们一直在讲的内容，就不再赘述，但绝对需要特别关注。
在不同阶段，产品人员需要借助产品原型与产品干系人达成共识。如果因为种种原因，产品干系人没有看到产品原型，没有确认，那产品失败的风险会变得很大，就比如前面提到的开发出来的产品与用户的真实需求相悖；另一方面可能是产品开发过程变得不可控，导致产品无法准时上线。因此，各个阶段的产品原型，一定想方设法与相关干系人进行沟通，达成共识。
前面我们也说，产品工作有规范的工作流程，但没有规范的工作格式，所以不同的公司之间会存在一定的差异。产品原型方面亦是如此。如果一个产品经理来到一个新的环境，没有“入乡随俗”，仍然沿用以前的工作格式，那就容易出现沟通不畅的问题，加大产品风险。关于这个问题，一个比较简单有效的方法，就是快速地和相关部门同事沟通，再参阅之前同事做的相关原型，形成基本的概念。然后随着工作的不断深入，再进一步优化。
这个问题更多会出现在具体执行过程中。项目进行过程中，我们难免会对产品原型进行修改。不过为了提高效率，我们往往只会修改一个页面，而其他页面就不做修改。这样一来，其他部门在根据原型工作时，就容易出现这个问题，不知道该按照哪个标准来进行了。这时候，我建议在整体原型之外可以添加一个规范说明，将相应的修改及规范描述清楚，这样其他部门的同事，就有了依据，问题可能就会少很多。
实用案例
项目背景
随着公司规模的不断扩张，客户数量也越来越大，但原有的纸质管理已经不能满足发展需求，因此公司决定由产品部门牵头，开发一套供业务部门使用的CRM系统。
沟通1：需求沟通
沟通形式：会议
干系人：业务部门领导、业务代表（不少于3人）、产品部门领导、技术部门领导
沟通内容：讨论CRM结构框架，梳理核心流程
原型体现：思维导图，辅助白板画流程草图
沟通目标：确定产品方向
沟通2：需求沟通
沟通形式：邮件或会议
干系人：业务部门领导、业务代表或全部（不少于10人）、产品部门领导、技术部门领导
沟通内容：确定核心流程
沟通目标：与产品用户达成需求共识
沟通3：可行性沟通
沟通形式：会议
干系人：产品部门领导、技术部门领导、技术骨干成员（项目相关，包含设计、制作、开发、测试等部门）
沟通内容：评估产品技术可行性
原型体现：可交互的线框图（只包含页面及板块交互，不含细节交互）
沟通目标：确定产品开发可行
沟通4：需求确认
沟通形式：邮件或会议
干系人：业务部门领导、业务代表或全部（不少于10人）、产品部门领导、技术部门领导、技术骨干成员
沟通内容：在可行的基础上查漏补缺
原型体现：可交互的线框图（只包含页面及板块交互，不含细节交互）
沟通目标：确定产品可开发
沟通5：项目启动沟通
沟通形式：会议
干系人：业务代表若干、产品部门领导、技术部门领导、技术骨干成员（项目相关，包含设计、制作、开发、测试等部门）
沟通内容：详细沟通产品细节（辅助需求文档）
沟通目标：确定产品执行标准
结语
正如开头所讲的，产品原型是产品经理与外界沟通的载体，其核心价值不在于原型外观做得多么精美，而在提升沟通的效率。在此认识下，我们可以进一步关注沟通的不同阶段及其阶段目标，采用与之相匹配的产品原型，进而实现我们的最终目标—有效沟通。
