欢迎光临
我们一直在努力

B端产品设计上的冲突与权衡

B端产品设计,如何权衡这些问题?本文作者将以一款企业移动办公软件为背景,讲述B端产品设计上的冲突与权衡。enjoy~

B端产品设计上的冲突与权衡

做一款B端产品,可能会面临很多挑战。B端产品本身就具有一定的复杂性,你可能要梳理庞杂的业务流程,要考虑不同角色的协作与冲突,协调不同企业的特异性需求……在习惯了2C的用户视角后,要如何理解B端的客户和用户?做一款B端产品,在设计过程中会遇到哪些挑战呢?

本文以一款企业移动办公软件为背景,讲述B端产品设计上的冲突与权衡。

冲突一:老板的需求和员工的需求

B端产品既然是给企业用的,自然会涉及到企业中的多种不同角色,满足不同角色的需求、促进他们的高效协作,是B端产品的基本要求。而在所有角色中,有两种身份最为典型:一是老板,二是员工。老板是企业的所有者、高层管理者,员工则是接受雇佣为企业创造价值的人。

作为企业的管理者,老板想要的是强管控。他希望知道员工在工作时间内的投入度,希望通过管控手段杜绝员工偷懒和损害公司利益。比如说,对于签到的功能,老板希望更精确地掌控员工实际办公的时间,他可能会提出这样的要求:

  • 要确保员工到办公室后才能打上卡,不希望未到公司就能打卡;
  • 避免代打卡现象,一个员工必须只用一台手机打卡;
  • 员工外勤时,希望知道员工外出的路线、在外访地点的实际时长。

而员工的诉求相反,他们希望公司在考勤方面的要求可以更弹性,即使是在工作时间也希望自己有一定的自由度。因此他们对签到功能的期待可能是:

  • 希望在距离公司一定范围内就可以打卡,希望有自动打卡避免忘记;
  • 不希望限制手机设备,有些员工本身就用两部手机,若有急事提前走也不希望老板知道;
  • 不想要老板知道自己的确切位置,感觉没有自由。

从签到这个例子就可看出,老板和员工往往有不同甚至相反的需求。对于一个B端产品来说,老板是购买者,是买单的人;而员工是使用者,老板买了软件后主要是给员工用。从商业价值考虑,老板的要求似乎应该是第一位的:毕竟只有老板愿意买单,我们的产品才会有市场,而员工几乎对产品购买没有决策权,满足他们的个体需求价值似乎并不大。

但是,我们并不能不考虑员工,而完全以老板为典型用户去设计产品。员工是实际使用者,如果产品设计对他们来说很难用、不能产生价值,甚至在某些方面使他们感到抵触(比如为了满足老板要求而侵犯他们的隐私),就会导致高层在内部推广产品时遇到较大阻碍,如果产品本身的价值体现不突出、老板也愿意考虑员工意见的话,就很可能会转而使用其他替代产品。

因此,对于老板与员工的冲突,我的看法是:以老板的需求为主、员工的需求为辅;除此之外,产品整体设计上应该保持易用性和情感化,这是为了让员工容易上手并且喜欢这个产品,降低高层对内推动的难度。情感化之所以重要,是因为员工们在使用B端产品时往往没有主动权,只是在上级的要求下使用,加之它是一个管理工具,员工会很容易对产品产生不良情绪,通过情感化设计,可以让员工意识到这不仅是一个满足高层的管理工具,它还很有“温度 ”,能让自己在某些时候产生共鸣,从而也会渐渐喜欢上这个产品。

冲突二:功能和体验

功能和体验的冲突不是B端产品的专属,C端产品也会面临这样的问题:增加功能可以使产品更“有用”,满足更多用户的需求;但是不断增加新功能会导致产品变得复杂难用,影响体验。而对于B端产品来说,这个冲突可能更加严重。这是因为:对于B端产品来说,功能实在是太重要了。

为企业做软件,需要考虑的业务场景和角色非常多,即使是满足一家或者一类企业的业务需求,工作量都非常大。更何况我们面向的企业来自不同行业、不同规模,很多都具有特异性的要求。于是尽管产品功能已经非常丰富,企业用起来还是感觉不够“合适”。

另一方面,企业使用管理软件是为了提升效率,提升效率也是为企业创造经济价值的方式之一。所以选择软件时,功能能不能满足需要就非常重要了。如果A软件有企业迫切需要的某功能,而B软件没有,那么即使B的体验更好,企业还是会选择A。功能覆盖的业务和场景、与企业的匹配程度,几乎成了企业选购产品的第一要素。

功能如此重要,那么体验呢?管理软件不像C端的产品,企业在选择产品时,即使有些难用,也会硬着头皮去探索功能,希望在综合对比几个不同产品后作出最优的决定。那么为了功能丰富而牺牲一些体验,是否可行呢?

体验并不是不重要,相反,B端产品的特殊性对体验设计提出了更多的要求。我认为B端产品体验设计有两大挑战。一是如何传达产品价值。由于产品是为多角色设计,当一个独立用户前来试用时,往往只能看到很简单的界面,而不知道不同角色在不同流程节点上会看到不同的功能和内容,因此也很难了解产品能为团队协作带来怎样的价值。第二个挑战是如何简化复杂的业务流程。功能越复杂,就越难学习,如果无法把复杂的系统设计得简单易用,用户也容易望而生畏,因为实在搞不懂而放弃该产品。

冲突三:短期利益和长期利益

如果只考虑短期利益,我们可能会做这些事:

  • 用C端常用的方法拉新促活,短期内提高活跃用户数和新增用户数;
  • 听从客户尤其是VIP客户的要求,添加一些特异性的小众的功能;
  • 以功能为王,不断叠加新功能,忽视体验和稳定性。

这些事情往往只能满足短期利益,长期来说却并不合适。

我们可能会做一些C端常用的运营活动,通过热点、让利或者有趣味的活动来吸引个体用户,提高活动期间的用户活跃度。从短期来说,确实能够提高日活,让我们的数据看上去更漂亮;但是长期下来却并无用处。这是因为用户是否使用云之家,一般来说是一个企业级的行为——如果我所在的公司不用,老板不用,我就不会去用,即使参加了这些促活活动也很难有所改变。所以B端的运营也许应该有更强的目的性,比如精准地面向决策层,传达出产品价值和品牌形象,找对了着力点或许就能吸引更多企业使用。

B端产品不免有很多付费客户,也会有一些重点维护的VIP客户,他们往往是一些比较大型的企业。客户不止经常向我们提bug、提体验问题,也常常要求加上某个功能——这些功能往往是出于企业内部的实际需求,因此客户也总是比较着急,希望我们尽快上线这些功能。如果可以做,要给用户承诺排期;如果不做,也需要向客户提出合理解释。满足客户的要求可以提高这家客户的满意度和稳定性,但是客户所提的功能有时满足的是很特异性的场景,如果所有重要客户的需求都要加上,产品很快就会变得非常臃肿。

快速迭代,小步试错。也许正是这样的理念,让我们敢于在功能还未完善时就上线——即使并未充分设计和测试过。原本这并没有问题,但如果迭代速度非常快,功能需求非常多,每个迭代都有做不完的新需求,那么那些本着“小步试错”的理念上线了的功能,就总是没有机会进行优化和验证。功能似乎是越多越好,但是因此牺牲了体验和产品的稳定性,产品的定位和品牌形象可能也会随着这样的快速迭代而走偏了方向。

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

题图来自 Pexels,基于 CC0 协议

分享到:更多 ()

评论 抢沙发

  • 昵称 (必填)
  • 邮箱 (必填)
  • 网址