产品经理忽视的产品逻辑:前端>后端?

从零开始学运营,10年运营老司机带路,2天线下集训+1年在线学习,做个优秀的运营人。了解详情

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

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

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

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

前端

原型 

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

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

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

产品规范 

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

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

页面流程 

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

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

后端

业务流程 

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

  • 自助点餐的流程设计
  • 电商的退货流程设计
  • 医院自主挂号流程设计
  • 共享单车的使用流程的设计

规则 

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

  • 各种编码的设计:身份证、银行卡号、订单编号
  • 蚂蚁信用等相关征信体系规则的设计
  • 滴滴打车的的派单规则
  • 订单自动确认收货的时间

异常逻辑 

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

  • 正在生效的规则被删除了怎么处理
  • 微信扫自己的二维码怎么处理
  • 支付宝给自己转账怎么处理
  • 上级用户添加下级为邀请人怎么破

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

 

本文由 @ 产品范 原创发布于人人都是产品经理。未经许可,禁止转载。

题图来自unsplash,基于CC0协议

赞赏是对原创者的最大认可
4人打赏
评论
欢迎评论,与我交流
  1. 有点偏题啊

    回复
  2. 产品经理首先站在产品的角度设计产品,再把自己当做用户去使用自己设计的产品,站在用户的角度去体验逻辑的合理性,操作的体验性,然后可以的话再考虑技术的可行性。每个环节其实都很重要。

    回复
    1. 小厂先考虑技术,比如我们做考勤,就不可能像别家做人脸识别的。不考虑本身研发实力的产品,是不合格的,产品不考虑技术是一句骗人的鬼话。

      回复
  3. 原型不够各种情况,开发就get不到点,有的开发可以讲一遍需求就做出来,有的开发原型图做到细的不行还要一点点的追着看哪个做错了。还有UI也是,原型没有画出来的东西,是很少自己理解流程然后去补充完善甚至纠错的。

    回复
    1. 每个公司都有难念的经,最难的得的是各个岗位之间的默契配合

      回复
  4. 异常逻辑,可以有多异常啊? :lol:

    回复
    1. 在测试的角度,正常逻辑只有一种异常逻辑千千万万。支付宝给自己转账,微信扫自己的二维码,淘宝买家号在自己的卖家号下单……都是异常逻辑

      回复
  5. 原型其实是通过形象的图形文字表达出需求,毕竟相对于文字来说,图形理解会更加直观。

    回复
    1. 各种各的优势,适当的时侯选择适当的方法

      回复
  6. 实话,看公司,我在一个外包公司,高保真的才行,单纯草图给技术看能行,给客户看,单子黄了。

    回复
    1. 确实,每个公司都有自己的情况

      回复
  7. PM新手2大错觉:1.前端比后端重要 2.高保真原型不重要
    我觉得这个地方应该是有取舍的,要看项目时间。如果时间允许,尽量高保真。但是高保真并不代表很多说明不到位。说明到位加上高保真原型才是最重要的。而不能直接否认高保真原型。但凡国内的大厂基本都要求高保真原型的

    回复
    1. 原型归根结底是为了表达需求,高保真也好,标注也好,只要能把需求描述清晰才是目的。

      回复
    2. 同意,看了很多站内文章,很多人留言第一件事是要作者的原型,问作者使用的工具、字体。作者也挺心酸~~ :mrgreen:

      回复
    3. 还有,作者是程序转的? 后端80%?程序小伙伴经常的逻辑就是功能有了,能点就行。但至少C端还是很看脸的。

      回复
    4. 技术出身,直接做的产品

      回复
    5. 政府项目里头,效果图在拿单子时发挥的用处有时大于功能本身

      回复
    6. 同意

      回复
    7. 因为政府领导都是一群关系户,没得真本事,只能看表面功夫。

      回复