产品核算:一个初创团队应该了解的概念

起点学院产品经理365成长计划,2天线下闭门集训+1年在线学习,全面掌握BAT产品经理体系。了解详情

产品核算:一个初创团队应该了解的概念

今天说说最近已经与团队中不少人都谈到的“产品核算”。

一提到核算,很多人都会不自觉的以为,那是总结色彩浓厚的概念,不适于快速反应的初创团队。其实,如果准备充分,完全可以在产品开发之前展开。又或者说,从我们准备做一款产品之前,就有意识地为产品制定一些标准。虽然大多数产品在后期运营中,都会经历过重大调整,但也有不少产品,从首个版本起,核心架构与功能,一直没有发生太多变化,而是不断稳定与优化。所以我还是建议大家,心态上拥抱变化,但在准备上制定充分的计划,尤其对于我们这些杂牌军游击队、没有什么成功经验的初创团队。

切入正题,我理解中的产品核算,包括四部分:UE核算、UI核算、功能核算、体验核算。(后期还会有运营核算)

一、UE核算能让标配功能最快定稿,为后续开发降低不确定性

所谓UE核算,就是专门针对产品原型设计的核算。普遍理解中,产品原型设计往往是发挥空间很大的,甚至可以是很粗糙的,拿我们的项目来讲,有很长一段时间,在原型设计中,对于不同类型的功能、交互、界面、icon以及对针对的文案,都没有系统的标准与核算。表面看上去,它最大限度的提高了UE的生产速度,但弊端与隐患很多,尤其会影响后续开发。

阶段性回头看,任何一类产品,无论是阅读类、游戏类、电商类、社交类……在原型设计上,都有很多相同之处,我认为,一款好的产品原型,并非是完全新创的,而是要在已有的品类中,找到自己的定位,进行针对性的功能差异化与体验优化。

拿我们产品来说,个人资料页面的上传头像、完善资料、进行隐私设置等功能,几乎是社交类产品的必备功能,就好比韩国餐厅的餐前小菜,它是标配的概念。可以进行创新,但对于一个初始版本的产品来说,一定不是重点,创新空间也有限。因此,对于类似标配的功能、标配的交互,就完全可以先进行标配设计,尽早定稿,不轻易修改。

它的好处是什么?避免在后续环节中,比如UI设计、功能优化等过程中,造成不必要的改动与人力成本的浪费。毛主席早就说过,集中精力办大事儿,抓主要矛盾。对于做产品来讲,原型设计过程中,尤其要抓好主要矛盾,把精力用在最重要的事情上。

UE核算要做到什么程度?以我们项目来说,要保证产品结构的确定、核心交互界面的确定,原型设计中,能够复用的界面,一定要学会复用。一来,这是实现极简的有效方式;二来,这会大大降低用户的学习成本;三来,它会让你的产品,有着系统性与整体性,不会让用户在交互的切换中,仿佛完成产品之间的转换一样;最后,也是非常重要的,就是节省UI设计师与开发工程师的工作量,最大程度的加快项目的进度,提升项目的可控性。

别小看原型设计,原型设计不仅是一个产品投入生产过程中的起点,原型设计的确定与清晰程度,还直接决定后续工作的稳定与流畅程度。

所以,UE核算,对于一个产品团队来说,是一种理念,一种对后续工作深度负责的理念。不要它看成是一种包袱,好的UE核算是有主次、有标准、有梯度的,它能够让团队尤其是产品经理,对产品结构、对产品今后的开发工作如指掌。(别笑,现实是产品开发过程中,大多数产品经理,都有被技术或者UI同事问住的时候,最终还得重新翻UE来回答,在我身上就发生过不少,惭愧)。甚至,如果UE核算做得充分,还能为产品的后续拓展与升级,降低开发成本。

二、产品经理要帮助UI设计师提前完成UI核算

所谓UI核算,就是针对产品界面设计的核算。对于有经验的设计师来说,这都是小儿科的事儿。但现实情况是,产品团队非常多,而有经验又懂产品的UI设计师,非常稀缺。怎么办?我们在第一版产品开发中,就没能事先制定UI核算,包括我们的UI设计师也没有真正的客户端产品的设计经验,所以我们走了一些非常不必要的弯路,甚至还发生过一些争吵。

因此,如果你是团队负责人,你最好能够帮助让你的UI设计师,从一开始就制定一张UI核算单。而不是仅仅依靠设计师的喜好与直觉来设计产品。否则,即便每个界面分别看起来不错,也掩盖不了整个产品界面的不系统与不规范。而且,对于移动互联网产品来说,前端开发的工作量在很大程度上都与UI有关。如果你是一个对UI标准很高的产品经理,那你就要学会利用UI核算,帮助设计师实现最完美的界面,找到最佳的工作节奏,同时控制好工程师的开发量。

UI核算之于UE相对简单,我认为首要任务是确定产品的设计风格。(不是直觉上的设计风格,一旦以核算作为标准,将没有“我觉得,我认为”这些模棱两可的概念)

再拿我们项目来说,我首先和设计师提出的要求是扁平风格,尽情拥抱iOS7,然后就是主色系、视觉氛围等方面的要求。这几点也是很多产品同仁最通用的常识。不过UI核算真的不只是这些,有了上文UE核算的基础,UI核算要在间隔线、头像、字体字号颜色(高亮)、按钮、消息类型等分类通用设计上做足功夫,有特色又不过度设计。这就能在最大程度上,确保高保真的质量与切图的规范,避免开发过程中,因为UI的不规范与调整,对进度造成影响。同样,对于设计师本身的成长也有非常大的帮助。除此以来,还包括UI设计与开发同事,在配上流程上的核算,什么时间提供什么,提供到何种程度,这都是可以通过核算来规范的。

实际上,如果你用心看看现有的app产品,在UI设计上不规范,有明显“BUG”的不在少数。虽然不会影响功能体验,但好的产品体验,既包括功能也包括视觉。所谓极致,二者缺一不可。何况,我一直以为,好的UI设计,一定是为产品加分且不影响项目进度的。在这一点上,我们真应该多向国外的同行学习。他们在细节的把握上,比我们到位,比我们用心,比我们有方法。

三、功能核算能够促进工程师更多关注体验

接下来是功能核算,包括前端功能,也包括后台功能。对于功能核算,我没有太多发言权,因为我不是技术出身,但我一直有一个理念:仅仅把功能做完是远远不够的。功能和体验一定是连在一起的。最近几个月,我花了很多时间和技术团队沟通,就是希望技术团队在进行功能开发的评估之前,就把体验考虑到。

比如同样的feed发布功能,目前市场上,就有多种现成的体验可供选择,有微博的发布体验,有微信朋友圈的发布体验,还有很多其他产品的发布体验。工程师最容易陷入的思维是:最快并且稳定的(没有BUG)的实现,而产品经理想要的却是:实现的同时,能有着最好的体验。但在工程师的标准中,体验上的差别往往不那么明显,这种反差完全是由于分工不同造成的,并不是工程师不在乎体验,毕竟谁都想做好产品,而且工程师往往是更加好胜的。

因此我建议那些经验不太丰富的团队,在功能评估时,最好能向工程师多问一句实现方式,顺便把体验兼顾了,多提醒这些技术天才们。否则,一旦开发结束,你跟工程师说,我想要的不是微博的体验,而是朋友圈的体验,这对于工程师的伤害是非常大的,改动的工作量往往也超出初创团队的接受程度,毕竟,我们活下去的关键是快速迭代。如果不快,等你体验好了,对手已经二次迭代了。

所以,我最近一直在和工程师沟通,在今后的工作中,确保每个功能在开发之前,都能把实现后的体验兼顾到。评估的过程中,要对市场上同类产品中口碑好的功能点,做出调研。激励工程师关注目前市场上同类功能中最佳的实现方式。否则,你做出来的,只是功能,远远不是市场上能够生存的产品。

功能核算的另外一种好处,就是能够促进工程师在功能点上的合理分工,让每个工程师,在每个阶段,都负责相同模块的开发,持续深入下去,换来的结果自然是体验上的不断提升。

四、体验核算应该融化到团队每个人的心中

最后是体验核算。其实在我心中,体验核算是贯穿着产品工作的始终,我从来不觉得体验是产品经理一个人的工作。它更应该融化到团队每个人的心中,好的体验应该是一种工作方式,一种生活方式,一种思维方式。当然,这非常难,对于初创团队也很少奢望,但我想告诉大家,一旦你把对更好体验的追求,讲给团队的每个人,总有一天,你会得到超乎想象的结果。体验的升级,就好比龟兔赛跑中的乌龟,持之以恒,潜移默化,假以时日,天翻地覆。

在这里,我举一个与后台工程师的沟通的例子。之前的文章中,我提到过体验很重要的一方面就是产品的性能。而这一点,后台工程师起到决定性的作用。比如加载速度上的0.1秒之差,都应该是后台工程师应该极力追求的。作为产品经理,团队负责人,要想尽办法,调动资源,鼓励后台工程师,为类似的点滴细节,拼尽全力。

以我为例,对后台工程师提出了一个要求:把影响产品性能体验的关键节点、关键指标数据化,然后做出不同阶段的优化目标,我们不需要激进,不需要一步到位,但什么时候能够到什么程度,要心里有数,单单嘴上说说是无法达成的。

好了,作为一个新转型的产品人,以上是我在最近半年工作中的一切感受,产品核算不是什么新鲜概念,也不是什么救命的奇药,它更多是团队工作的一种方法,一种思维,一种习惯。希望对正准备或刚刚转型的产品人,有所帮助。写得不对的地方,欢迎资深从业者指正。

文章来源:虎嗅(作者公众账号:hechuan1101)

您的赞赏,是对我创作的最大鼓励。

评论( 0

登录后参与评论
加载中