现代高效协作场景下，产品原型扮演了哪些角色？

最近越来越多的身边朋友开始往产品&运营方向发展，当进入职场后，一个角色需要与其他角色协作，共同完成一件事，那么无论是产品还是运营，产品原型在其中作为一个协作桥梁，连接产品与研发之间的沟通，直到最后的成果落地。

一说到产品原型，对于有些人来说，产品原型是为了提前预知工作量以及复杂度，对于有些人来说，产品原型是为了提前与客户沟通明确可用性，那么我们今天这篇文章更多偏向运营&产品在日常协作过程中，产品原型可以充当哪些角色，解决哪些问题；

一、角色一：项目的探索者

无论你的产品是一个网站还是一个App，都会经历从0-1的过程，这个过程的绕不开原型，那么原型在项目从0-1过程中起了什么作用？答案是帮助团队去试错，尽可能低成本实验项目的可行性。

一个新项目的原型既然是探索者，就会面临探索者的难题，例如

项目包含多个组件多个模块，每个点都要兼顾十分耗费时间，每个模块之间缺少联动性；

全新的项目本身初期没有一个整体架构，而原型的设计本身要具备全局架构，需要对项目有深度理解，对产品MVP版有清晰的概念。

所以很多项目在初期都会有一个纵向的竞品对比，不仅仅是为了切入市场，更是为了降低初期设计难度，其实市面上很多产品都已经把该走的坑都走了一遍了，为什么我们还要再走一次呢？

所以试错的成本当然越低越好，在产品起步阶段，找到一个细分领域作为切入点，找到一个该领域的竞品对标比起，除此之外，有时候可以去互联网上找找类似的组件以及资源，减少投入成本。

比如​​摹客​​的组件模版，类似于一个原型市场，简单来说在你没有思路，没有头绪的时候，适当借鉴一下，既可以减少重复造轮子又可以开拓思路。

如果说方案在设计阶段，我们有一套模版组件可以使用，那么在前期阶段可以减少大量的工作量，

我们在前期投入就尽可能减少时间成本。

二、角色二：项目的协作者

在探索阶段，国内的产品团队往往不是一人挑起整个团队的大梁，往往是3-5人团队来协作完成一个项目从0-1，以前我们都会用Axure等桌面级工具，但是Axure的协作对国内用户的学习成本过高，那么协作是无法避开的一环。

在过去，按照过往的经验，以前我们做一个项目的时候，投入4个产品，小a负责商品模块，小b负责订单模块，小c负责用户模块，大A负责统筹，那么每个人都会用Axure画一份原型，然后大A整合一个版本，然后进行方案评审。

上面流程看似简单没什么问题，但是最重要的一环在于a、b、c三人整合后，当需要调整时，每次需要三方同步。当时我就很苦恼这种协作模式。但碍于团队使用习惯，只能执行。

但往往一个中小型的项目尚需要几十个不同页面以及扭转逻辑，不同模块的产品需要相互协作，然后汇总到一个文档，如果长此以往，很容易出现信息不同步，设计出现迭代遗漏问题。

其实更现代一点的协作方式就是多方线上协作，参考​​摹客rp​​的线上协作，按照原协作流程，大A创建一个项目，由于大A邀请a、b、c进入，每个人处理不同的模块，分布式处理一个项目，同时各方实时同步调整进度；

从实际使用来说，摹客的多人协作符合原型作为项目协作者这一角色的定位，同时提高了协作时候的容错率，在项目中后期也提供了项目及时调整的空间；

三、角色三：项目的验证者

正常情况下，需求的产生是来源于人，不管这个人是老板还是用户，所有的想法来源都是场景化的，根据场景产生需求，那么我们需要做的就是验证想法。

验证想法有很多种方式，而你用原型可能就是最快的一种方式，与其你思考半天，不如实践一下，用几分钟画一个简陋的原型，不需要有那么多交互，甚至截图一张。

如果一个需求，在完善原型时，我们可能会更偏向完善的交互，尽可能与原产品交互保持一致，但如果我们处于一个验证想法的阶段，这种想法会成为巨大的成本。

高效、直观、易调整是我们更应该注重的方向，而在这个节奏下，用户是产品的核心，也是检验我们产品有效性最重要的一环，很多时候我们并不知道时用户想要什么，或者说并不清楚用户的场景下是如何操作的，我们可以通过一个简单的原型与用户验证一下。

在实际可以操作的场景下，用户可以根据自己的使用场景进行快速响应，那么原型就成为了一个场景的验证者，本身降低了试错成本，同时在上线前对需求进行了提前体验，如果有任何想法，也可以通过标记来告知产品，反向快速调整需求的落地可行性；

结语

说实话，在任何一个团队，原型只是沟通的一种方式，往往我们要选择最高效的方式要解决问题，那么什么是最高效的方式呢，每个团队都有不同的方式。

在刚做产品的时候，笔者用过本地共享文件，后来用过Axure+蓝湖，现在用​​摹客在线协作​​，在不同的时间和场景下我们有不同的解决方案，原型是我们与不同角色沟通的渠道。

原型作为探索者、协作者、验证者帮助我们规范了团队之间的协作方式，提升了沟通效率。我们始终会围绕低成本验证模式不断完善产品。