B端产品:“易用”与“有用”,两者要兼具

零基础学产品,BAT产品总监带,2天线下集训+1年在线课程,全面掌握优秀产品经理必备技能。了解详情

本文笔者从五个方面——产品规划、架构设计、功能设计、数据设计、上线运维,来分析:B端产品经理,如何更好地做用户体验设计。

谈到用户体验设计,传统的说法就是:人机交互设计、界面设计、视觉设计。

当然这些很重要,可是如果对用户体验设计的理解就到这一步,那显然视野太过狭窄了,这种体验设计可以理解为狭义的用户体验设计,更加关注产品易用。

作为一个全栈产品经理,从开始构思一个产品的时候就要关注用户体验设计。

我是一个B端产品经理,今天就谈谈一谈:B端产品在构想、设计、开发、上线运维整个生命周期中,如何做用户体验设计。

我把这种用户体验设计定义为广义的用户体验设计,不但关注产品易用,而且关注产品有用。

一、准确的定义产品对用户的价值,是用户体验的根基

如果一个产品被设计出来无法创造用户价值——也就是说我们设计了一个无用的产品,那这个产品即使易用性再好,我们都认为这是用户体验不好的产品。

对用户而言,这个产品就是废物,就好像一个车间工人,他更需要的是穿一件耐磨的工服,你却给他一件高大上的西装,显然是无用的。

所以,从产品构想开始,就要开始考虑用户体验的问题,我们要解决的问题是否能够给用户带来足够好的用户体验。

作为产品经理能够做好这一步的关键,就是要懂行业、懂业务。

这个行业能踩到的大大小小的坑基本都踩过了,也知道哪里坑会让用户更痛,所以才有可能更加敏锐、准确的抓住市场机会,创造出有用户价值的产品。

我们可以做一个市场上已有的产品,也可以根据发现的一个新坑点创造一个新产品,这两类产品在构想时,对用户体验的设计是不同的。

尤其是对B端的产品,这类产品最大的特点就是:采购决策周期长、替换成本高。

所以,一旦某个市场已经备某个产品占领,要想创造一个基本一致的产品来取代原来的产品难度非常之大。

这里就要用到俞军先生的产品价值公式,产品用户价值=新产品体验-旧产品体验,所以新产品的用户价值往往取决于旧产品的体验。

在B端市场里往往有翻盘的说法,一般这个时候并非新进来的产品做得体验多好,而是旧产品的体验已快降到了零点,基本到了不可用的程度,这个时候是翻盘的最佳时机。

如果要创造一个新产品,通过快速的市场验证后,往往用户体验有个及格分就可以开始干了。B端产品做法是做些Demo,然后写一个漂亮的PPT发给销售,在已有的市场去验证,这个时候往往还只是个PPT产品,根据真实企业级用户的反馈,确定这个产品是否做下去。

定义没有用户价值的产品,就是构想了一款没有好的用户体验的产品。这是根基,否则无论研发团队多么辛苦,市场团队多么强大,也是徒劳,根基不稳,犹如浮沙筑高台,产品长不大就夭折了。

二、基于角色和场景设计的功能,才会有好的用户体验

产品的业务价值想清楚了,下面就是要基于这些业务价值点,设计功能架构,通过系统功能来实现这些业务价值点。

有一次去找客户交流,客户对我说:“他刚刚交流了一家厂商,他们软件功能特别多,密密麻麻的有上百个吧。”

可感觉就是一堆功能的集合,他要不和我讲,根本不知道这些功能是干啥的,而且很多功能从名字上看去,我根本就用不上。

客户说的这个例子,是典型功能设计不清晰的例子,没有基于用户角色和场景去设计功能。

一个B端的产品往往会有多个角色,就拿一个采购系统的请购管理模块来说,就涉及需求岗、采购岗、管理审批岗等多种角色。

如何设计这个功能模块,能让这些角色高效的协同,又能让每个角色按照自己熟悉的方式完成系统操作?这就需要从角色和场景出发进行设计。

对于需求岗而言,他更加关注:如何创建请购单——如果是差不多内容的请购单,我能不能找个现成的单子直接改一下就可以提交了?自己到底提了多少请购单?这些请购单目前都处在什么状态?哪些些被驳回了?哪些在流程中?

对于采购岗而言,他更关注:哪些请购单分配给了自己?哪些请购单不满足采购要求需要被驳回修改?请购需求的技术要求有没有详细的描述?

管理岗更加关注:如何审批请购单?如何更快的填写审批意见,我如果正在出差途中没办法使用电脑如何审批请购单?

都是请购单,不同角色关注的内容和使用的场景不同,功能设计也会有差异。当然,我们也不鼓励不同的角色设计完全不同的功能,这样也会造成设计冗余,要去抽象一些公共功能服务大家。

还是刚才那个请购管理模块,为了让不同用户更好的完成流程协同,可以设计一个待办模块。待办模块产生所有角色的待办,只是不同角色登录到系统只能看到属于自己的待办。

但是,请购单审批就只会给管理岗使用,请购单创建就只会给需求岗用。创建和审批就要单独设计一个功能,不同角色都需要一个请购单的列表,追踪自己处理的请购单,这个请购单列表就可以设计成一个公用功能,只是不同角色数据权限不同而已。

只有这样设计出来的功能才会符合不同角色的工作场景,从线下到线上,不但没有违和感,反而效率更高,体验更好。

曾经遇到过一个难缠的用户领导,非常仔细,每个小的功能都要让我们把设计思路讲清楚。虽然听起来,这个用户很讨厌,可对用户这种寻根溯源的产品精神很钦佩,我们不能想当然的认为就该有这么一个功能,或者说我看类似的产品都有这么个功能,所以我的产品也应该有。

不能只知其然而不知其所以然,要探究这功能设计背后的原因,要能找到这个功能设计带来的用户体验,如果找不到,那这功能也许就是无用的。

三、角色动线设计是线,交互设计原则是点

基于不同角色设计了很多功能,如何才能让不同的用户进入系统后,能够获得更好体验?这就需要设计一下不同角色的动线。

就像去逛宜家,按照固定的线路走就好了,每走几步就会出现一个你比较关注的家具,功能的引导路线设计也是一样。

我举个例子,比如:采购系统,如何为采购项目经理这个角色设计系统动线?

采购项目经理进来首先看到的是消息中心,看看有没有待办任务或者提醒的消息,有的话点进去看看看。

继续往前走,会看到自己负责所有项目的整体进度情况,进度延迟比较厉害的项目,点进去看看详情,到底在哪一环节延迟了。

接着,往前看看不是由自己主管,但是需要自己配合的采购项目进展如何。

这些都看完了,最后导出采购项目月报,看看数据情况怎么样,准备给领导的汇报工作。

这些事情都做完了,就可以从系统退出了。

这就是一次完整的用户体验动线设计,需要处理的任务,延迟的项目、工作月报就是这条路线上最让你关注的内容。

除此之外,才是针对具体的功能的交互设计。

很多书或者文章里都讲得很细致了,我这不多讲,为了保证文章的完整性,我把关注的几条设计原则放到这里与大家分享。

  1. 精简原则:决定不要什么,比决定要做什么更重要。
  2. 就近原则:将同一类的功能都组织放在页面相同模块。
  3. 习惯原则:设计及功能尽量贴近用户的操作习惯,避免用户思考。
  4. 帮助原则:为用户提供适量的帮助,必须使用用户语言,不迷惑用户。
  5. 响应原则:每次用户进行操作后,都需要给用户一个响应反馈。
  6. 容错原则:必须允许用户犯错,给予用户后悔的机会。

除了这些原则,还要学会使用原型设计工具,比如:Axure或者墨刀,让这些原则在功能设计上落地。

当然你可以把交互设计的任务交给专职的用户体验设计师,但是你要有能力说明白如何进行用户体验设计。

四、数据是否准确是用户体验好坏的分界线

B端产品线上线时间长了,很多都会出现数据不一致、重复等数据不准的问题。

这种数据不准的问题如果出现了,而且长时间无法修复,对用户体验的打击是致命的,可能一下子用户就不信任你的系统,这个时候也就到了用户体验好坏的临界点。

所以,保证数据的准确,对B端产品而言就是最好的用户体验。哪怕功能操作繁琐一点,交互设计的也没有那么友好,只要数据是准的,系统就有价值,用户就愿意用,特别是管理层更能感受到这些数据的价值。

在产品设计的时候,需要考虑如何保证产品的数据准确:

  1. 就是要重视业务模型的设计,模型关系要梳理准确,另外业务规则要定义严谨,避免由于用户的操作或者其它不可测的异常情况发生时,系统出现不合逻辑的脏数据。
  2. 就是建立数据稽核功能,通过固化稽核规则,系统自动对数据的准确性进行稽核,定期生成稽核报表,当出现数据问题时及时发出告警,通知运维人员进行修复。
  3. 就是要保留数据修改的详细记录,这个是为了保护自己。先小人,后君子,很多时候我们的企业用户因为自己工作上的失误,会把问题甩锅给系统,说系统的数据不是他改的,是系统出错了,这个时候把详细的数据修改日志拿出来,多少能起到保护的作用,用户也就不敢轻易用这招了。

五、主动运维是提升用户体验的良药

最后说说上线后的运维,和C端产品不同,很多B端产品上线后,尤其是交付给中大型企业的项目,都需有运维团队支撑,负责后期的系统运维工作。

这些运维人员是要直接面对用户的,而且很可能就在用户现场,这种运维压力是显而易见的。

我们使用C端的产品,不管是微信还是头条,如果发现系统有问题,这个时候就只能通过问题反馈的方式,在线提交一个问题工单给到后台来解决。

B端产品就不一样了,用户一旦发现比较急的问题,一个电话就过来了,恨不得马上就让你解决掉。

所以,B端产品的运维,及时的运维响应速度非常重要。

好的运维人员都是从解决用户的问题开始的,如果用户的问题提出来,你放到那1天没搭理用户,用户可能就急了,很可能换来的就是被投诉。

所以,作为运维人员一定要要学会及时响应,哪怕这个问题暂时解决不了也要先响应,然后逐步汇报进度,让用户的愤怒情绪平息。

所有的运维人员都不想做救火队员,希望可以变被动为主动,提升运维能力。要做到这些除了运维人员自身的能力,还需要一些高效的运维工具,除了传统的IT监控之外,APM可以做到对应用性能各种指标的监控。

通过部署APM工具,不但可以让运维或技术人员更加快速的定位并解决问题,而且还有提前预警的能力。在用户报出故障之前,就已经提前把问题解决掉了,这样用户的满意度会大大提升,用户体验也就更好了。

最后总结一下:

  1. 产品规划:准确的定义产品对用户的价值,是用户体验的根基;
  2. 架构设计:基于角色和场景设计的功能,才会有好的用户体验;
  3. 功能设计:角色动线设计是线,交互设计原则是点;
  4. 数据设计:数据准确是否准确是用户体验好坏的分界线;
  5. 上线运维:主动运维是提升用户体验的良药。

#专栏作家#

奋斗De奶爸,微信公众号:奶爸的小客栈(ID:naiba2000),人人都是产品经理专栏作家。10年以上产品、项目管理实战经验,关注企业供应链、数据中心、IT监控等产品,喜欢琢磨,希望把有价值的产品理念和实战经验传递给需要的人。

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

题图来自 Unsplash,基于CC0协议。

给作者打赏,鼓励TA抓紧创作!
1人打赏
评论
欢迎留言讨论~!
  1. 不错说的很多都是我踩过的坑

    回复
  2. 确实,数据准确性是致命的,尤其是系统接口比较多的时候,更涉及和第三方系统的数据对接,非常麻烦

    回复
    1. 同感

      回复
  3. 我想问您一下:容错原则怎么定义?比如单据提交后需要有撤回修改吗?

    回复
    1. 我理解容错主要指允许用户犯错,犯错时系统给出提示或控制

      回复
    2. 比如,操作前无法撤回的需要用户再一次确认,比如删除、提交等;操作后允许用户撤回,比如微信消息几分钟内能撤回等。

      回复
  4. 产品经理很多时候都是运维 :roll:

    回复
  5. 做了三年多的B端产品规划,还有很多需要学习,继续努力

    回复
  6. 无论是对于B端产品还是C端产品,首先要解决的就是“有用”这个问题,其次才是“好用”。所谓的好的用户体验就是,第一,能够实际解决用户的需求,其次,是能够简单快速的帮助用户解决需求,最后就是用户在解决需求的过程中对产品有一个深刻且积极的印象。

    回复
圈子
关注微信公众号
大家都在问