产品经理忽视的产品逻辑：前端>后端？

我们都是善于望文生义的，再加上市场上大多数产品书籍和网络上泛滥的产品文章的诱导，他们不是偏于宏观的方法论就是偏于前端的UI和UE，导致入门者对产品经理这个职位是有误解的，我也是从误解走过来的。

前端好比衣服，而后端就如身体构造，衣服是有装饰作用的，很容易因光鲜外表遮掩了更为重要的后端。

如果非要用一个数据去量化前端和后端相在产品设计中的比重，我倾向于用自己钟情的二八定律去衡量。后端设计占80%，前端只有20%，接下来我将从前端和后端两个维度来总结：

前端

原型

相信大多数产品童鞋入坑都是从原型设计开始的，记得在一个产品群中看到一位童鞋说：当年花了5个小时研究了下Axure，然后就踏上了产品的不归路。在我看来，原型是产品设计的载体而已，初学者往往会纠结于应该学哪种原型设计工具，如何通过原型工具设计包含更多交互效果的高保真原型。就算包含了90%的交互效果，原型终究只是个原型而已，或许你只是博取了自己的开心而已。

看过不少产品大牛的PRD文档，发现他们更多的都是采用线框图+注释的形式。需要花十多分钟才能做出来的交互效果分明一句话就说清楚了，而有些逻辑是原型表达不出来的。有一句话是这样说的，任何***的设计它在形式上一定是*简单的，我想需求文档也应该是这样的。

*初写需求文档的时候花了大量的精力在优化原型图，结果每次都被UI吐槽。后来才意识到，原型是给别人看的，原型只是一种传递需求的载体，我们不必拘泥于工具的使用。如果手绘就可以表达你的需求，何不去繁就简呢。

产品规范

虽然产品规范更多是UI和UE所关心的事，但是往往小公司是不没有UE的，这就需要产品经理肩负交互设计的任务。

一个产品大牛曾给我讲过，国内的产品大多是不讲求产品规范的，只有大厂才会分别做IOS和Android端的产品区分。国内往往大多数产品兼具IOS和Android的设计规范，看过IOS和Android规范文档的产品童鞋都会发现IOS和Android还是有很大差别的，今天暂不做详细的总结。

页面流程

页面流程是在用户视角。是让用户更快的抵达自己的目的地，比如产品的核心功能。还是延长用户的操作路径，比如银行卡的解绑，产品设计时会故意延长此功能的操作路径，从而降低用户的解绑率。

我想重点说说反馈页面，因为这个页面往往很容易被忽视，在产品交互中任何重要的事件都应该有相应的反馈，比如支付成功这个事件，通过一个页面展示给用户心理预期的反馈。需要注意一点就是，有成功的反馈就应该有失败的反馈。

后端

业务流程

业务流程是在技术视角。产品经理这个词多少有点蛊惑人，据说互联网类书籍中卖的**的就是产品经理相关书了。我觉得叫业务经理更合适，产品应该是业务来驱动的，需求是通过业务流程的设计来解决的。而流程的设计绝对不是毫无根据的画出来的，不仅要考虑到实际的应用场景还要考据技术实现的可行性。

1. 自助点餐的流程设计

2. 电商的退货流程设计

3. 医院自主挂号流程设计

4. 共享单车的使用流程的设计

规则

相对于业务流程，如果业务流程是线的话，那么规则就是连接流程的节点。从某种程度上讲，产品设计的如何，得看规则设计的怎么样。从技术上层面上来看，规则就要用算法来实现了，算法是技术的一道分水岭，不懂算法的程序猿不是一条好产品狗。

1. 各种编码的设计：身份证、银行卡号、订单编号

2. 蚂蚁信用等相关征信体系规则的设计

3. 滴滴打车的的派单规则

4. 订单自动确认收货的时间

异常逻辑

异常流程远多于正常流程，核心的业务往往只有一个，而错误的操作往往是多种多样的。在设计产品的时候就应该站在测试的角度，一步到位，也是为了避免到时候被测试屌。所以，在一开始的时候就要考虑到各种异常情况，做一个逻辑严谨的产品经理。

1. 正在生效的规则被删除了怎么处理

2. 微信扫自己的二维码怎么处理

3. 支付宝给自己转账怎么处理

4. 上级用户添加下级为邀请人怎么破

一个好的产品经理，要有同理心，不仅要在用户的角度，还要在设计的角度，开发的角度，运营的角度，还有老板的角度去思考。