如何从0到1设计一款牛X的社区O2O平台.pdfVIP

如何从0到1设计一款牛X的社区O2O平台 随着14年社区O2O行业的爆发，我们发现市场上如雨后春笋般的涌现出了大 量的社区O2O平台 ，一个平台的存活运营很重要 ，但产品的价值依然不能小觑 ， 如何设计出一款让让用户尖叫的产品，也是平台能否成功的主要因素。 我认为一个牛X的产品 ，最重要的不是打开它多么炫 ，当然视觉效果也 很重要 ，但是更重要的是你产品内在体现出来的逻辑性有多深 ，交互性有多 强 ，也就是你产品真正的核心价值 ，这也正是牛X的产品经理所需要考虑的 ， 在产品设计之前一定要先考虑产品的逻辑性，还有关联性，尤其是像社区 O2O这样的平台，涉及到物业、商家、用户等多方的利益关系时，要分别 站在各方的需求点上去思考，他们之间的关系要屡清楚，尤其是利益关系 ， 所以做社区O2O这样的产品要比其他的产品我认为要复杂的多的，所以对 产品经理是具有很大的考验的 ，那么笔者就结合自身的从业经历和大家分享 一下我个人对于社区O2O这样的一个平台的设计感悟。 闲话少说先上图： 对于产品的设计过程我在这里就不在多说 ，因为是个产品经理都应该会 很清楚无非就是从采集需求、需求分析、原型设计、交互设计、视觉设计、 技术开发到产品测试上线的一个过程 ，那么我在这里和大家主要聊的是更多 的是设计的思路，如图所示主要分为三个阶段： 业务模式的理论探索阶段 这个阶段非常重要 ，是一个社区平台构思的阶段 ，我在这里只强调一点 ， 一定是要站在物业、商家、用户的三方去考虑平台的架构 ，而且三方的互动 性要强 ，只有这样才能保证未来在平台的运营当中处于一个良性的发展。举 个小例子，几乎所有的社区O2O平台都有物业管理这个模块，在前端能够 实现用户的在线投诉、报修、咨询等功能 ，但是我看到的大部分社区平台都 是很单一的交互 ，比如用户在线报修了 ，那用户在按下报修的那个功能点时 这个平台几乎就和用户没有关系了，就等着物业或者合作商家上门服务了 ， 到技工服务完成 ，就意味着这个报修的流程走完了 ，从理论上来讲这个过程 没有问题，用户的问题也解决了，但是整个的过程体验我认为的是极差的 ， 完全谈不上过程控制 ，那么理想的状态是什么呢 ，这个报修的过程是涉及到 物业、技工 （或合作方）、人三方的交互的 ，从用户下单 ，技工接单、维修 完成、评价再到订单关闭 ，物业的后台、客户的订单中心对于每个时间点都 是有准确的记录的 ，同时每个时间节点用户都会有相应的消息提示，比如技 工接单了 ，客户的消息中心必然会有提醒 ，这些都是细节问题 ，也是互动性 的体现 ，如果在实际的落地过程中应用了 ，就会起到意想不到的效果 ，一方 面保证了服务的可控性 ，另一方面增加了用户的体验 ，所以以上只是一个小 的案例 ，在其他地方功能上都可以站在三方的关系链上去多加思考 ，让整个 过程变得交互性更强 ，为什么笔者在一直强调多方的互动性 ，主要还是由于 社区O2O平台的属性导致的，其实社区O2O平台最需要与用户建立的就 是两点一个是粘性另一个就是信任 ，缜密的过程控制 ，恰恰体现了对用户负 责的态度，进而间接的加强了用户对平台的信任度。 业务模式的技术实施阶段 上一阶段其实是产品经理和一线的市场人员在打交道 ，收集需求和平台 的设计 ，那么下一阶段就是 “梦想照亮现实”的阶段了 ，开始将想法变成具 体的产品了 ，那么这一阶段就是产品经理要和技术人员打交道了 ，其实这一 阶段没有什么太特别的，无非就是与技术人员对接axure和 PRD文档，但 我这里强调的是 ，除了文件以外 ，最重要还是要和技术人员把要点反复的强 调清楚 ，尤其是咱们在上一阶段提到的那些互动的环节 ，不能含糊。在测试 这一环节狠狠把关 ，尽量避免流程错误 ，少出bug，在测试阶段除了有专门 的测试团队测试以外，作为产品经理也是有义务将产品从头到尾的操作一 遍，看是否与当时所提的需求相吻合。 业务模式的验证优化阶段 其实这一阶段才是真正验证产品的阶段 ，要拿到市场上推广看看用户的 实际反映是什么样的，这时候产品经理要和运营人员观察平台的相关数据 ， 比如活跃度、某些功能的使用情况 ，同时也要看物业或者商家的反映，他们 在操作上是否存在问题，其实这一阶段是收集问题和采集新的需求的阶段 ， 把用户用的爽的功能留下 ，用的不爽的优化甚至是砍掉 ，从此开始走向产品 的迭代生涯。 对于社区O2O这样的一款产品考验产品经理的不是画图能力而是业务 模式的理解能力 ，而且是深度理解 ，对于行业的理