本文笔者从五个方面——产品规划、架构设计、功能设计、数据设计、上线运维，来分析：B端产品经理，如何更好地做用户体验设计。
谈到用户体验设计，传统的说法就是：人机交互设计、界面设计、视觉设计。
当然这些很重要，可是如果对用户体验设计的理解就到这一步，那显然视野太过狭窄了，这种体验设计可以理解为狭义的用户体验设计，更加关注产品易用。
作为一个全栈产品经理，从开始构思一个产品的时候就要关注用户体验设计。
我是一个B端产品经理，今天就谈谈一谈：B端产品在构想、设计、开发、上线运维整个生命周期中，如何做用户体验设计。
我把这种用户体验设计定义为广义的用户体验设计，不但关注产品易用，而且关注产品有用。
如果一个产品被设计出来无法创造用户价值——也就是说我们设计了一个无用的产品，那这个产品即使易用性再好，我们都认为这是用户体验不好的产品。
对用户而言，这个产品就是废物，就好像一个车间工人，他更需要的是穿一件耐磨的工服，你却给他一件高大上的西装，显然是无用的。
所以，从产品构想开始，就要开始考虑用户体验的问题，我们要解决的问题是否能够给用户带来足够好的用户体验。
作为产品经理能够做好这一步的关键，就是要懂行业、懂业务。
这个行业能踩到的大大小小的坑基本都踩过了，也知道哪里坑会让用户更痛，所以才有可能更加敏锐、准确的抓住市场机会，创造出有用户价值的产品。
我们可以做一个市场上已有的产品，也可以根据发现的一个新坑点创造一个新产品，这两类产品在构想时，对用户体验的设计是不同的。
尤其是对B端的产品，这类产品最大的特点就是：采购决策周期长、替换成本高。
所以，一旦某个市场已经备某个产品占领，要想创造一个基本一致的产品来取代原来的产品难度非常之大。
这里就要用到俞军先生的产品价值公式，产品用户价值=新产品体验-旧产品体验，所以新产品的用户价值往往取决于旧产品的体验。
在B端市场里往往有翻盘的说法，一般这个时候并非新进来的产品做得体验多好，而是旧产品的体验已快降到了零点，基本到了不可用的程度，这个时候是翻盘的最佳时机。
如果要创造一个新产品，通过快速的市场验证后，往往用户体验有个及格分就可以开始干了。B端产品做法是做些Demo，然后写一个漂亮的PPT发给销售，在已有的市场去验证，这个时候往往还只是个PPT产品，根据真实企业级用户的反馈，确定这个产品是否做下去。
定义没有用户价值的产品，就是构想了一款没有好的用户体验的产品。这是根基，否则无论研发团队多么辛苦，市场团队多么强大，也是徒劳，根基不稳，犹如浮沙筑高台，产品长不大就夭折了。
产品的业务价值想清楚了，下面就是要基于这些业务价值点，设计功能架构，通过系统功能来实现这些业务价值点。
有一次去找客户交流，客户对我说：“他刚刚交流了一家厂商，他们软件功能特别多，密密麻麻的有上百个吧。”
可感觉就是一堆功能的集合，他要不和我讲，根本不知道这些功能是干啥的，而且很多功能从名字上看去，我根本就用不上。
客户说的这个例子，是典型功能设计不清晰的例子，没有基于用户角色和场景去设计功能。
一个B端的产品往往会有多个角色，就拿一个采购系统的请购管理模块来说，就涉及需求岗、采购岗、管理审批岗等多种角色。
如何设计这个功能模块，能让这些角色高效的协同，又能让每个角色按照自己熟悉的方式完成系统操作？这就需要从角色和场景出发进行设计。
对于需求岗而言，他更加关注：如何创建请购单——如果是差不多内容的请购单，我能不能找个现成的单子直接改一下就可以提交了？自己到底提了多少请购单？这些请购单目前都处在什么状态？哪些些被驳回了？哪些在流程中？
对于采购岗而言，他更关注：哪些请购单分配给了自己？哪些请购单不满足采购要求需要被驳回修改？请购需求的技术要求有没有详细的描述？
管理岗更加关注：如何审批请购单？如何更快的填写审批意见，我如果正在出差途中没办法使用电脑如何审批请购单？
都是请购单，不同角色关注的内容和使用的场景不同，功能设计也会有差异。当然，我们也不鼓励不同的角色设计完全不同的功能，这样也会造成设计冗余，要去抽象一些公共功能服务大家。
还是刚才那个请购管理模块，为了让不同用户更好的完成流程协同，可以设计一个待办模块。待办模块产生所有角色的待办，只是不同角色登录到系统只能看到属于自己的待办。
但是，请购单审批就只会给管理岗使用，请购单创建就只会给需求岗用。创建和审批就要单独设计一个功能，不同角色都需要一个请购单的列表，追踪自己处理的请购单，这个请购单列表就可以设计成一个公用功能，只是不同角色数据权限不同而已。
只有这样设计出来的功能才会符合不同角色的工作场景，从线下到线上，不但没有违和感，反而效率更高，体验更好。
曾经遇到过一个难缠的用户领导，非常仔细，每个小的功能都要让我们把设计思路讲清楚。虽然听起来，这个用户很讨厌，可对用户这种寻根溯源的产品精神很钦佩，我们不能想当然的认为就该有这么一个功能，或者说我看类似的产品都有这么个功能，所以我的产品也应该有。
不能只知其然而不知其所以然，要探究这功能设计背后的原因，要能找到这个功能设计带来的用户体验，如果找不到，那这功能也许就是无用的。
基于不同角色设计了很多功能，如何才能让不同的用户进入系统后，能够获得更好体验？这就需要设计一下不同角色的动线。
就像去逛宜家，按照固定的线路走就好了，每走几步就会出现一个你比较关注的家具，功能的引导路线设计也是一样。
我举个例子，比如：采购系统，如何为采购项目经理这个角色设计系统动线？
采购项目经理进来首先看到的是消息中心，看看有没有待办任务或者提醒的消息，有的话点进去看看看。
继续往前走，会看到自己负责所有项目的整体进度情况，进度延迟比较厉害的项目，点进去看看详情，到底在哪一环节延迟了。
接着，往前看看不是由自己主管，但是需要自己配合的采购项目进展如何。
这些都看完了，最后导出采购项目月报，看看数据情况怎么样，准备给领导的汇报工作。
这些事情都做完了，就可以从系统退出了。
这就是一次完整的用户体验动线设计，需要处理的任务，延迟的项目、工作月报就是这条路线上最让你关注的内容。
除此之外，才是针对具体的功能的交互设计。
很多书或者文章里都讲得很细致了，我这不多讲，为了保证文章的完整性，我把关注的几条设计原则放到这里与大家分享。
精简原则：决定不要什么，比决定要做什么更重要。
就近原则：将同一类的功能都组织放在页面相同模块。
帮助原则：为用户提供适量的帮助，必须使用用户语言，不迷惑用户。
除了这些原则，还要学会使用原型设计工具，比如：Axure或者墨刀，让这些原则在功能设计上落地。
当然你可以把交互设计的任务交给专职的用户体验设计师，但是你要有能力说明白如何进行用户体验设计。
四、数据是否准确是用户体验好坏的分界线
B端产品线上线时间长了，很多都会出现数据不一致、重复等数据不准的问题。
这种数据不准的问题如果出现了，而且长时间无法修复，对用户体验的打击是致命的，可能一下子用户就不信任你的系统，这个时候也就到了用户体验好坏的临界点。
所以，保证数据的准确，对B端产品而言就是最好的用户体验。哪怕功能操作繁琐一点，交互设计的也没有那么友好，只要数据是准的，系统就有价值，用户就愿意用，特别是管理层更能感受到这些数据的价值。
在产品设计的时候，需要考虑如何保证产品的数据准确：
就是要重视业务模型的设计，模型关系要梳理准确，另外业务规则要定义严谨，避免由于用户的操作或者其它不可测的异常情况发生时，系统出现不合逻辑的脏数据。
就是建立数据稽核功能，通过固化稽核规则，系统自动对数据的准确性进行稽核，定期生成稽核报表，当出现数据问题时及时发出告警，通知运维人员进行修复。
就是要保留数据修改的详细记录，这个是为了保护自己。先小人，后君子，很多时候我们的企业用户因为自己工作上的失误，会把问题甩锅给系统，说系统的数据不是他改的，是系统出错了，这个时候把详细的数据修改日志拿出来，多少能起到保护的作用，用户也就不敢轻易用这招了。
五、主动运维是提升用户体验的良药
最后说说上线后的运维，和C端产品不同，很多B端产品上线后，尤其是交付给中大型企业的项目，都需有运维团队支撑，负责后期的系统运维工作。
这些运维人员是要直接面对用户的，而且很可能就在用户现场，这种运维压力是显而易见的。
我们使用C端的产品，不管是微信还是头条，如果发现系统有问题，这个时候就只能通过问题反馈的方式，在线提交一个问题工单给到后台来解决。
B端产品就不一样了，用户一旦发现比较急的问题，一个电话就过来了，恨不得马上就让你解决掉。
所以，B端产品的运维，及时的运维响应速度非常重要。
好的运维人员都是从解决用户的问题开始的，如果用户的问题提出来，你放到那1天没搭理用户，用户可能就急了，很可能换来的就是被投诉。
所以，作为运维人员一定要要学会及时响应，哪怕这个问题暂时解决不了也要先响应，然后逐步汇报进度，让用户的愤怒情绪平息。
所有的运维人员都不想做救火队员，希望可以变被动为主动，提升运维能力。要做到这些除了运维人员自身的能力，还需要一些高效的运维工具，除了传统的IT监控之外，APM可以做到对应用性能各种指标的监控。
通过部署APM工具，不但可以让运维或技术人员更加快速的定位并解决问题，而且还有提前预警的能力。在用户报出故障之前，就已经提前把问题解决掉了，这样用户的满意度会大大提升，用户体验也就更好了。
最后总结一下：
上线运维：主动运维是提升用户体验的良药。
