从“用户体验五要素”推导为“B端产品设计五要素”

结合「用户体验五要素」,我也来聊下我对B端产品设计五要素的一些看法。

一、角色目标

用户是谁,他/她的岗位职责是什么,在履行职责时遇到了什么问题,为什么会有这些问题,没系统赋能之前,他/她是怎么解决这些问题的。

系统是为人服务的,为谁服务,需要充分识别出涉及的相关方,搭建整个系统服务的用户群体画像。

梳理相关方时,需要逐一深入了解各相关方的岗位职责(目标)、痛点(背景+问题点+当前解决方案),最终形成完整的用户画像体系,方便管理各相关方预期的同时,也更高效地解决用户的痛点、痒点及各流程事项的卡点。

在进行用户调研时,需要根据对方的岗位职责及工作内容代入到对方的视角中,比如跟财务聊,财务的工作是确保款项正确入账,你就不用纠结合同是否可以签的业务领域问题了。

在了解用户的痛点时,需要进一步了解目前没有系统支撑时,他是怎么解决这些问题的,是忽略这些问题,还是用效率较低的方式支撑着解决这些问题。

一般来说,优先处理后者,因为前者目前处于被忽略的状态,而业务还能正常运转,要么是发生的概率极低,要么是即使发生了,对业务的运转也没啥影响,属于重要(或不重要)/不紧急的事情。

完善好用户画像之后,需要让用户自行确定优先级,以确保能管理好用户的预期。

调研完所有相关方,完善好整个用户画像体系之后,需要综合对比考虑,从公司战略、相关方话语权、ROI等角度对所有相关方的诉求进行优先级的排序及沟通确定。

资源总是有限的,需求总是做不完的,而B端产品涉及的相关方又太多,有人的地方就有江湖,常见的如下:

  1. 相关方之间的诉求是冲突的,如销售管理型的CRM,销售总是希望“自由点”,而管理者总是希望了解销售的一举一动,以便做好人员的管理。
  2. 相关方的诉求是一致的,但优先级可能会有冲突,如:技术部分不甘于沦为成本部门,就希望做的CRM系统可以通过一系列营销工具带来更多的营收,而业务部门却认为只需要管好销售及内部流程即可,营销的事情不需要操心。其实站在公司的角度,两者的诉求都是合理的诉求,而且也肯定会朝着这些目标前进,只是需要分阶段实现,而先实现哪个,则需要进行充分的沟通讨论及协调。

产品经理不便于卷入这种“江湖斗争”,不然做事就会比较被动,所以需要拉齐所有相关方,就需求优先级及阶段目标达成共识,这样就可以与各相关方做好工作上的协同,保证整个开发节奏的稳定性。

二、产品目标

产品的长远目标及阶段性目标各是什么?

其实在第一阶段识别角色目标进行用户画像体系构建之前,对产品目标应该已经有初步的了解了,但还不是定稿状态。

如:CRM(Customer Relationship Management,客户关系管理)分好几种类型:

营销型CRM:重在通过更多的营销活动来带更多的客户;

分析型CRM:重在通过数据分析洞察客户,提升客户的转化率;

销售管理型CRM:重在对销售的管理,提升人效,降低成本;

可能长远目标,CRM系统会把这些范围都覆盖,但有一定的时间周期,需要拆分成多阶段目标逐步实现。而各阶段目标,则是相关方们battle的结论。

Battle完之后,确保大家对产品的长远目标及各阶段性目标达成共识,就可以确定产品调性,明确产品的边界,更好地达成各相关方诉求及产品目标。

每个人提的诉求都是一个个碎片化,我们需要根据达成共识的阶段性目标,兼顾长远目标将这些碎片串起来,从点到线再到面,这样产品的蓝图就出来了。

蓝图的绘制是很有必要的,代表了对产品的想象力,平时做需求也会考虑到后续的拓展性,方案更加系统化,也可以跟大家同步产品的迭代方向及迭代节奏,管理好各方预期。

蓝图没有定稿一说,产品是迭代出来的,不是规划出来的,所以不用因为迭代方向跟蓝图的差异有点大而感到沮丧,及时根据各方因素更新蓝图即可。

三、ER建模

确定了产品边界之后,就可以进行ER建模。

什么是ER建模呢?

其实我们B端产品,更多地是需要遵循物理世界的运行规律,将物理世界抽象为计算机可以识别的模型,来支撑物理世界中所发生业务的运转,抽象的这个过程就叫ER建模,ER建模的产物就是ER图。

ER图的组成部分有实体、实体属性、实体间的关系:

  • 实体:我们要管理的对象,如:客户、联系人、跟进记录等等,抽象实体时有个小技巧:数据有唯一的ID,后续可能会通过ID查找该数据的,就可以定义为实体。
  • 实体属性:该实体所具备的一些重要特性,丰富一下实体的画像,对实体有更清晰的定义。如客户,有客户名称、纳税人识别号等等属性,这样就可以明确该客户是一个公司,而不是C端个体。
    不同实体可能会有相同的属性,如:线索跟客户都有联系人姓名,都是记录该实体的联系方式,不必太过于避讳,只要确保实体的画像足够丰满、清晰即可。
  • 实体关系:为了表示实体之间的关联关系,如跟进记录,是要跟客户关联还是跟联系人关联,完全是两种不同的业务模式。怎样的关联,1对1,还是1对N,即1个客户关联1条跟进记录还是N条,也是两种不同的业务模式。

示例如下:

1个客户下面可以创建N个联系人,一个联系人可以有多条跟进记录,即客户的跟进记录挂在联系人下面,而不是客户下面。建完模之后,整个业务场景就比较清晰了。

准确的ER图,可以提升自己对业务的认识,提高与用户及研发的沟通效率,也可以指导研发的数据建模:研发的数据库就是一张张excel表,通过“ID”将多个表关联起来做各种逻辑计算,从而满足系统中的各种数据运算,满足用户的需求。

四、事项流程及节点目标

B端产品很大一部分内容就是对各个实体进行各种逻辑判断、算术运算及增删改查等操作,对1个或N个实体进行流程审批、知会,从而支持发生在物理世界的业务运转。

几乎所有的B端产品都有一个特点:审批事项多、审批流程冗长。

审批流程本意是为了规范管理,但基本都会被层层加码:

  1. 审批者的安全感:不履行自己审批的职责,迫于公司规定的管理职责,又不能把审批节点去掉,故在自己审批节点前面加上自己的下属,让下属做事项的审批工作,有了下属的认真审批,自己就可以“盲审”。
  2. 因为某些低概率事件的发生而开设的审批流,比如外勤打卡审批,就因为出现部分人躺在家里打卡,而设立的外勤打卡审批流程,让其上级进行管理监督。其实大可不必为了部分人的作恶而一棒子打死所有人,可以让系统判断,一段时间内在同个地点打卡多次就给相关人员预警提醒,人为判别是否为正常的商务活动即可。
  3. 领导变动或者管理重点变动:随着业务的发展,领导的人事调动或者管理重点也会随着变动,以支撑业务的运转。两者的共同点基本都是只会增加流程,不会删减原有的流程。因为在他们看来,目前的流程制度支撑了业务的正常运转,删减现有流程还得去排查是否会带来其他影响,删减了之后不出事还好,出事了就是自己的问题了,反正又不需要自己干活,权衡之下,就会在现在的流程上,叠加自己想要的流程,导致流程越来越多。

基于以上背景,我们需要对每个流程及流程上的每个节点都了解清楚,能用系统判断的,则无需人为核验,“如非必要,勿上流程,勿增节点”。

顺便提一下B端产品的价值,C端产品可以有用户量、活跃度等明确地指标体现产品及各迭代的价值,但B端产品是支撑业务发展及运转的,价值往往难以估量,导致B端产品经理的价值无法得到认可,比较枯燥。

冗长的内部流程往往是企业内部常见且头疼的现象,如果我们可以统计各流程所花时间及驳回率,通过技术手段及逻辑方案降低流程时长及驳回率,就可以大大提升企业内部的流程效率,这就是B端产品最好的价值体现。

五、故事地图及方案设计

经过了前面四个步骤的摸索之后,我们对用户体系及业务基本盘也基本摸清了,原则上可以开始设计方案了。

但因为之前梳理的都是枝干,很多细节会有所遗漏。而细节,往往是最影响用户体验及使用效率的,所以在设计方案之前,需要梳理一下故事地图,进一步挖掘用户痛点、痒点及卡点。梳理故事地图时,踩过几个坑:

  • 把它放在第一个环节,那时候对用户、对业务都不熟悉,导致沟通效率比较低下,用户也会质疑你的专业能力。
  • 把故事地图跟业务流程图混在一起,导致整个故事地图比较混乱,达不到了解用户痛点、痒点、卡点的目的。
  • 将多个用户的故事杂糅在一起,整个故事线比较割裂。

截取部分反例:多用户的故事杂糅在一起及太偏向于业务流程。

脱敏之后,截取部分正确的例子:一个用户角色、一个故事梳理出一张故事地图。

用户故事地图主要是为了更直观地了解用户目标、为了达成目标做出的一系列动作,做动作时接触到的点及整个过程的情绪波动,以便与用户达成共识,更好地站在用户的角度解决问题。

故事地图重在梳理整个事项闭环中用户的情绪变动,所以应该从用户兼顾事项闭环的角度绘制故事地图。

如果用户有多个故事,可以用多个故事地图表示,如:销售的售前->售中->售后是一个完整的故事闭环,写周报是一个完整故事闭环。这样就可以用两个故事地图来记录,甚至售中可能涉及多个流程,也可以将一些复杂的流程单独作为一个故事地图。

总而言之,B端产品是一个多事项流程、多用户参与的“混乱性”系统,不需要强硬地杂糅到一张故事地图里面,能直观记录及表达用户情绪即可。

梳理完故事地图,对用户的细节更加清楚之后,就可以来设计原型方案了。

设计原型时,可以按照“用户体验五要素”的思路逐步完成:

  1. 战略层:讲清楚需求的背景及目标,让研发团队更加了解业务,提升沟通效率。
  2. 在讲目标时,如果是一个稍微复杂的方案,最好是用流程图表达整个方案的逻辑判断点,“千言万语不如一张图”,先让研发小伙伴脑海里有个大致印象:要做什么、怎么做。

范围及结构层:用思维导图梳理需求涉及的改动点,思维导图的层级就可以表现出结构层。

框架层:设计原型方案及PRD文档。

B端产品的特点是页面也比较多,实体与实体之间的逻辑检验比较复杂,与其他系统交互也比较多,且复杂度是个增量的事情,经常需要回顾历史逻辑,维护起来工程量不小。

之前我是一个版本一个.rp文件,且该.rp文件中的原型及PRD只会保留本次版本要做的内容,把整个.rp文件托管到Axure Cloud或蓝湖等原型托管工具,再分享链接给研发即可,研发也就很清楚地知道本次版本的工作内容。

这样做有个弊端就是我要找到某个页面的原型,在原有基础上修改,就会非常难找,需要查找历史版本记录,判断最近哪个版本有改到这个页面的原型,比较费精力。

有时候找到的并不是最新的原型,如:1.10就有改到这个页面的原型,但我没留意,找到了1.5版本的原型,改动起来就比较麻烦,效率比较低。

后面找到了比较高效管理原型的方法,将多个版本的原型集中在一个.rp文件里面:

一级目录:版本号,二级目录:需求,三级才是每个需求的战略层、范围及结构层、框架层,这样如果要找到对应页面的原型,直接查询即可:

每个需求作为一个目录维护,颗粒度也比较清晰。开发时,为了避免非当前版本的内容干扰到研发,可以通过项目配置,只托管当前版本的原型到托管平台中。

以上,就是高效管理Axure原型文件的方式。

产品经理的核心能力不是原型画的好不好,但原型质量就跟人的外貌一样,是一个产品经理的门面,太潦草也不好~

总结

综上所述,我把B端产品设计的思路划分成了5层:角色目标、产品目标、ER建模、事项流程及节点目标 、故事地图及方案设计。

每一层的搭建都会影响后续上层的质量,而在搭建上层时,可能也会发现底层的遗漏,可以进行查漏补缺,从而确保整个B端产品的方向正确。

本文作者 @铭创优品

版权声明

本文来自互联网用户投稿,文章观点仅代表作者本人,不代表本站立场。本站仅提供信息存储空间服务,不拥有所有权,不承担相关法律责任。如若转载,请注明出处。如若内容有涉嫌抄袭侵权/违法违规/事实不符,请点击 举报 进行投诉反馈!

相关文章

立即
投稿

微信公众账号

微信扫一扫加关注

返回
顶部