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

12 评论 18309 浏览 176 收藏 17 分钟

本文笔者从五个方面——产品规划、架构设计、功能设计、数据设计、上线运维,来分析: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协议。

更多精彩内容,请关注人人都是产品经理微信公众号或下载App
海报
评论
评论请登录
  1. 我刚刚的评论怎么没有了? 角色动线应该是线下零售用的很多的,用在这里也很好。数据准确性是生命线,数据稽核功能是新学到的。

    来自四川 回复
  2. 角色的动线设计,线下零售用的营销手段,用在这里也很好。数据准确是生死线。

    来自四川 回复
  3. 为什么你这些文章都不错,但是没干货呢

    来自山东 回复
  4. 不错说的很多都是我踩过的坑

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

    来自河北 回复
    1. 同感

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

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

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

      回复
  7. 产品经理很多时候都是运维 🙄

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

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

    来自广东 回复