腾讯方法论——互联网B端产品设计的3项基本原则及5个步骤

刘玉强 2018-02-08 08:19:38

根据我之前的工作经历,总结的B端产品设计经验,希望对一线从事B端产品工作的产品经理有一点参考价值。

image.png

什么是B端产品

B端产品,可以概括为:在供求关系中,给供给端使用的产品或系统。

B端产品区别于C端产品的特征是:

C端产品,侧重满足个人生活需求,给用户提供愉悦感(满足便利、新鲜感、虚荣心、欲望冲动),好玩。

B端产品,侧重满足组织生产需求,帮用户提升效率(发现并解决业务问题),有用。

有一个段子讲“手机那么好玩,还找什么女朋友呀”,这里的好玩,多数来自C端产品给用户的愉悦感。

而贯穿B端产品迭代发展的落脚点是:在业务流程中发现问题、解决问题,并提升效率。

我的B端产品设计经验

写这篇总结的基本思路是:如果要做一个独立且相对复杂的B端产品系统,该如何开展产品设计工作?

主要包括以下几个方面:

B端产品系统设计的基本原则(指导思想)

B端产品系统设计的五个步骤(具体怎么做)

B端产品系统设计中需要避免的误区(不要那么做,或不要做成那样)

基本原则

产品思维,业务导向

先说“业务导向”:产品系统是为业务服务的,所以要尊重业务的发展规律,最终让产品帮助到业务的发展。产品经理要到业务中去了解业务的宏观与细节,根据业务抽象系统逻辑,用互联网的方式系统性的解决问题或提升效率。

再说“产品思维”:产品经理有责任把原来自己可能不熟悉的业务,熟悉并抽象成产品需求且把事说清楚,并能够提供合理化的解决方案,不能只做需求的传声器——“他们给我提了一个需求,我们就做这么一个功能”,避免为了做而做。

由于业务快速发展,有些组织中没有“产品经理”的角色,又或者其他角色的成员主动承担了“产品经理”范畴内的工作,岗位名称无所谓,是否有经验无所谓,重要的是在承担这个事情的时候做到“产品思维,业务导向”,这是把事做好的基础。

用使用者角度去思考

所有的产品经理都知道“用户体验”,不过很多人理解的“用户体验”偏重在前端交互、视觉文案上。对于B端产品来说,只关注这些是不够的。所以我喜欢用更普通直白的说法——关注“使用者角度”。在设计产品的时候,想一想真正的使用者他们需要一个什么系统?他们会怎么用这个系统?现在的实现方式对他们来说好用吗?

很多B端产品,当产品经理离开办公室作为一个普通用户的时候,是想不到或者用不到的,所以极端的情况会出现,在需求开始之前产品经理没有用过相关产品,系统上线之后产品经理也不会用自己做的产品。B端产品经理,一定要走入具体工作场景,观察真正的产品使用者在具体的业务氛围中是怎么工作的。我一直相信一点:只有沉浸其中,才能更好的理解。

在小度掌柜(百度外卖商户端)电脑版上线第一周,我去一家商圈头部商户的后厨蹲点了俩小时,看餐厅的工作人员是怎么接单、处理订单的,在现场我发现我们的“接单”按钮有点小、不够明显。回来之后,我和视觉设计师沟通优化方案,给他们描述我们产品使用的具体场景:8平米的小屋(拥挤嘈杂),配置不高的组装电脑(显示屏分辨率不高),工作人员站着处理三四个平台的订单(紧张慌忙)。在这样的场景下,还需要工作人员俯下身去“寻找”操作按钮是不够效率,也不厚道。以此说服视觉设计师愿意接受“不符合设计规范”的大号按钮。

还有一个案例,是在优化客服系统之前,我去百度外卖的客服工作区,站在客服同学的背后,看他们怎么接电话、怎么记录信息、怎么解决投诉,只有这样才能了解客服人员在使用系统的时候需要什么功能,在哪些环节浪费了时间。

针对和内部使用者的沟通合作,个人觉得可以重点做好以下几点:

产品经理是来解决问题的,不要担心一锤子买卖(而提海量的需求),开发资源是有限的,我们可以一起来排需求优先级(不是所有的功能能一下子全上线);

建立好信息同步机制,固定时间固定方式同步关键进展(当然所有信息同步方式里,面对面沟通效果是最好的);

不要依赖业务方提需求,要帮业务方想方案,由于角色的不同、思维方式的不同,业务同学不一定能提出自己真的需要的功能,产品经理要主动去思考业务中的问题,并形成需求;

通过一两个项目,建立互信,形成互相支持的关系。过项目,建立互信,形成互相支持的关系。

考虑系统的延展性与弹性

业务肯定是发展的,而当前的资源和时间是有限的,一个产品版本,不会解决所有问题,迭代是必然的。怎么增加系统的延展性与弹性,减少后续研发的开发难度、减少使用者的后续学习成本就很重要。尤其是在设计1.0系统的时候,更考验产品经理的这项能力。

一方面,需要增加对业务发展的预见性,当前业务是怎么样的,以后一到两年会怎么发展,甚至未来五年的形态是什么样?没有人能保证自己的预测一定是对的,但是尊重业务规律,去思考业务可能的发展方向,提前想到的越多,在设计系统的时候能考虑到的延展性与弹性就越多。用“谋全局”的高度去思考一个系统,才会生成更合理的当前“谋一隅”的一版需求。

另一方面,在具体的产品方案里,针对这个系统的核心业务落脚点、基本单位尽量做到“模块化”——方便组装、方便基于这个标准模块叠加逻辑。下文的“定义最小颗粒度”会详细阐述这块的思考。

总之,一个好的产品系统要做到适合延展、有容纳新功能的“弹性”,B端产品经理要有这个自我期许。

五个步骤

确定产品系统的目标

接到一个需求,首先要想:这个系统给谁用?要做哪些事(解决什么问题)?系统的边界是什么(需要覆盖到什么范围)?

在这个大目标下,开展后续的工作。

梳理业务流程(用逻辑把系统串起来)

业务流程中包含哪些角色、包含哪些关键节点,从头到尾的顺向流程是怎么样的,从尾到头的逆向流程是什么样的,中间的分支流程是什么样的,从上到下、从下到上各类角色怎么配合……

梳理业务流程要做到以下几点:要闭环(不能有半逻辑,不能有停留在某个环节走不下去的流程);要看到底(不只是宏观上合理,最底层的细节逻辑也要覆盖到),要有边界(一个全的系统是什么,不是没边没延)。

争取用一个大的业务流程图,把整个系统要解决的问题包含进去。这样做的好处是,可以把功能想全了,防止有重大逻辑缺陷,或遗漏功能。

定义最小颗粒度(基本单位)

基于上述业务流程,会发现有一个“基本单位”可以从头到尾、从尾到头、从上到下、从下到上顺畅的在这个系统里流转。

这个基本单位就是需要我们定义的“一件事”,拆解到合理大小颗粒度的“一件事”——这个系统主要解决的问题的基础组成部分,靠这些最小颗粒度的“一件事”组成整个系统。这个“一件事”在系统存在、流转有哪些“节点”,这个“节点”对应的是系统里的关键状态;不同的人,在这个系统里存在,就是系统里的“角色”;有哪些“角色”可以针对“一件事”的“节点”产生影响,针对哪些内容产生哪些影响就是“权限”和“数据范围”。

根据业务流程,抽象出:基本单位“一件事”、关键状态的“节点”、使用者的“角色”、“权限”、“数据范围”。这个系统就基本成型了。

以客服工单系统为例:

最小颗粒度的基本单位“一件事”是指“一个投诉”,不是一个电话(太小了),也不是一个人的所有投诉记录(太大了)。“节点”:就是工单的状态,从投诉开始、到流转到相关部门或负责人、到最后投诉解决,工单的每一次停留都可以作为一个“节点”。“角色”:除了一线客服、小组长、客服负责人,还有其他配合部门的角色等,凡是参与到这个系统的人都可以概括到某类角色里;不可概括的参与者或需要细化分工的参与者,需要增加角“角色”以适应需要。“权限”和“数据范围”:各个角色能做哪些操作、操作哪些内容、造成哪些影响就构成了“权限”和“数据范围”。

一个好的基本单位就像集装箱一样,具有普适性(可以灵活被处理)、具有弹性(方便添加功能)。定义好一个系统的最小颗粒度,系统就成功一半了。

我见到的B端产品设计里,做的不好的多数就是由于最小颗粒度的定义不合理,造成系统逻辑不全或延展性很差。

建立框架与归类(用页面把系统串起来)

根据不同的角色、不同的功能,进行归类,进而组合成一个整体框架,用页面的形式呈现出来,就可以形成交互稿。

从第二步到第三步,从第三步到第四步,是一个拆解再组装的过程,先拆解了、揉碎了再用产品思路组装起来以形成最终的产品形态。

撰写需求文档

将上述梳理的过程和内容,用文字的形式将产品逻辑、图表、页面、功能点串起来,并进行丰富细化,就形成了需求文档。

好的需求文档应该:逻辑严谨,条理清楚,文字简练,能把事说清楚。

每个角色(交互、视觉、开发)都能准确理解需求的背景、目标、实现方式,大到流程逻辑,小到功能细节。可以针对不同角色,提供侧重点不同的需求形式。

尽量用平实的语言(而不是形容词)描述需求,挤压任何歧义空间。

需要避免的误区

一个新用户,第一次使用系统但通过自己的琢磨看不懂这个系统(不会用、不知道都有哪些功能),我觉得这个系统不算好系统。好的系统,可以通过页面功能或者不多的介绍,就能把底层逻辑和边界看明白。

看不到底的伴生现象是特殊逻辑多,造成的问题往往是枝蔓太多。产品逻辑用打补丁的方式,解决某个问题可能很快捷,但长期来看,这种方式影响产品系统的简洁性和条理性。

看不到底的坏影响是,一方面使用者(尤其是新人)学习成本高;另一方面新增功能时容易挖到“电线”,增加了维护与迭代成本。

上面的文字已经提到,由于初期考虑的不周全(业务理解的前瞻性不够,或者最小颗粒度定义不清楚等)造成系统延展性差,增加一个功能就像给系统做一次大手术。所以尽量在产品设计初期,考虑的多一些,每一次迭代都想着为后续迭代提供便利。

所有问题都想着用产品系统来解决

一个系统不能解决所有的问题,也不是所有的问题都适合用产品系统来解决。有些事(需求)从投入产出比、灵活性上来说,通过管理规范、SOP、Excel去解决可能比做一个系统更适合。

B端产品经理的自我修炼

在和那些令人佩服、事业有成的前辈/领导一起共事过程中,还有我这几年的工作感受,我觉得B端产品经理需要持续沉淀的能力有:

无论是O2O也好,互联网+也好,B端产品要解决好业务的问题,必须要去理解业务,要了解这个行业的历史与现状、关注行业的发展。

除了垂直的业务逻辑,多数的互联网+都会涉及到商业问题,经济管理、市场营销这些知识会帮助产品经理开阔思路、提升商业思维。

B端产品多数业务链条比较长,涉及角色较多,一个B端产品的成功,离不开相关角色共同努力与相互支持。

通过一两件事,建立与合作部门的互信,是后续合作的基础;建立固定的信息同步机制(与研发团队的每日站会,与业务部门的每周周会等),是合作顺畅开展的保障。

在工作中,能够发现资源、利用资源都是一种能力。

让我佩服的那些前辈,平时办公桌上都会有一本书。一个人能力很强不可怕,可怕的是他还一直在学习。

无论是这个时代,还是互联网行业,都发展太快了,我们需要持续学习。

image.png

长按二维码关注我们