当前位置:主页 > 产品展示 >

产品展示

太阳城亚洲_B端产品:“易用”与“有用”两者要

2019-05-21 12:05

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

  就是要重视业务模型的设计,模型关系要梳理准确,另外业务规则要定义严谨,避免由于用户的操作或者其它不可测的异常情况发生时,系统出现不合逻辑的脏数据。

  就是建立数据稽核功能,通过固化稽核规则,系统自动对数据的准确性进行稽核,定期生成稽核报表,当出现数据问题时及时发出告警,通知运维人员进行修复。

  就是要保留数据修改的详细记录,这个是为了保护自己。先小人,后君子,很多时候我们的企业用户因为自己工作上的失误,会把问题甩锅给系统,说系统的数据不是他改的,是系统出错了,这个时候把详细的数据修改日志拿出来,多少能起到保护的作用,用户也就不敢轻易用这招了。

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

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

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

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

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

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

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

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