以下哪个不是B端产品的特点(b端产品的特点)

本文作者从——产品规划、架构设计、功能设计、数据设计、在线运维五个方面分析：B端产品经理，如何更好的设计用户体验。
说到用户体验设计，传统的说法是：人机交互设计、界面设计、视觉设计。
当然，这些都很重要，但如果对用户体验设计的理解就此止步，显然太狭隘了。这种体验设计可以理解为狭义的用户体验设计，更注重产品的可用性。
作为一个全栈产品经理，从构思一个产品开始，就要注重用户体验设计。
我是B端产品经理。今天我就讲讲如何在构思、设计、开发、上线运维的全生命周期中，为B端产品设计用户体验。
我把这种用户体验设计定义为广义的用户体验设计，既注重产品的易用性，又注重产品的有用性。
1.准确定义一个产品对用户的价值，是用户体验的基础。如果一个产品的设计是为了创造——的用户价值，也就是说我们设计了一个没用的产品，那么即使这个产品很好用，我们都认为它是一个用户体验很差的产品。
对于用户来说，这个产品就是废物，就像一个车间工人。他更需要的是一套耐磨的工作服，但你给他一套高大上的西装显然没用。
所以从产品构思开始，就要开始考虑用户体验的问题，想解决的问题能否给用户带来足够好的用户体验。
作为产品经理，这一步的关键是了解行业和业务。
这个行业能踩的大大小小的坑基本都踩过了，我们知道哪里的坑会让用户更痛苦，所以才有可能更敏锐准确地抓住市场机会，创造出有用户价值的产品。
我们可以制造市场上现有的产品，或者根据发现的新漏洞创造新产品。这两种产品在构思的时候，用户体验的设计是不一样的。
尤其是B端产品，这类产品最大的特点是：采购决策周期长，更换成本高。
所以一旦某个市场被某个产品占领了，就很难创造出一个基本一致的产品来替代原来的产品。
这里将使用俞军的产品价值公式。产品用户价值=新产品体验-老产品体验，所以新产品的用户价值往往取决于老产品的体验。
在B端市场，经常有翻身的说法。一般这个时候并不是新产品体验有多好，而是老产品的体验已经迅速降到零，基本达到了无法使用的程度。这个时候是翻身的最好时机。
如果你想创造一个新产品，在快速的市场验证后，你往往可以从用户体验的及格分数开始。B端产品的做法是做一些Demo，然后写一个漂亮的PPT进行销售，在现有的市场上进行验证。这时候往往只是一个PPT产品。根据真实企业用户的反馈，确定这个产品做不做。
定义一个没有用户价值的产品，就是构思一个没有良好用户体验的产品。这是基础，否则，再努力的研发；d团队就是，营销团队再强，也是徒劳。根基不稳，就像流沙筑起高台，产品长大了就死了。
第二，基于角色和场景设计的功能，好的用户体验产品的商业价值可以清晰的想出来。下面是基于这些业务价值点设计功能架构，并通过系统功能实现这些业务价值点。
有一次我去跟一个客户谈，客户跟我说：“他刚跟一个厂商谈过，他们的软件功能多到几百个。”
但感觉是功能的集合。如果他不和我说话，他不知道这些功能是什么，而且很多功能从名字上看，我根本用不上。
客户提到的例子是典型功能设计不清晰的例子，没有根据用户角色和场景设计功能。
一个B端产品往往有多个角色。以采购系统的申请管理模块为例，它涉及需求岗、采购岗、管理审批岗等多个角色。
如何设计这个功能模块，让这些角色高效协作，每个角色都能以熟悉的方式完成系统操作？这个需要从角色和场景来设计。
对于需求岗，他更关注的是：如何创建需求单3354。如果是内容相似的征用，可以找一个现成的清单，修改一下就提交吗？你提出了多少要求？这些请购单目前处于什么状态？哪些被拒绝了？在哪些流程中？
对于采购岗，他更关心的是：哪些请购单是分配给他的？哪些请购单不符合采购要求，需要拒绝和修改？请购单的技术要求是否有详细描述？
管理层更关注：如何审批请购单？如何更快的填写审批意见？如果我出差，不会用电脑，我该如何审批请购单？
都是请购单。不同的角色关注的内容不同，使用的场景不同，功能设计也会不同。当然，我们也不鼓励不同角色设计完全不同的功能，这样也会导致设计冗余。我们必须抽象出一些公共函数来为每个人服务。
和刚才的申请管理模块是一样的。为了让不同的用户能够更好的完成流程协同，可以设计一个待办模块。待办事项模块生成所有角色的待办事项列表，但是不同角色登录系统只能看到自己的待办事项列表。
但是，请购单的审批只有管理岗使用，请购单的生成只有需求岗使用。创建和批准单个功能。不同的角色需要采购申请列表来跟踪他们处理的采购申请。这个请购单列表可以设计成一个公共功能，但是不同的角色有不同的数据权限。
只有这样设计出来的功能才能满足不同角色的工作场景。从线下到线上，没有违和感，反而效率更高，体验更好。
我曾经遇到过一个难缠的用户领导，他很细心。每个小功能都必须让我们的设计思路清晰。虽然这位用户听起来很烦，但他很推崇追根溯源的产品精神。我们不能想当然的认为应该有这样的功能，或者我觉得类似的产品都有这样的功能，所以我的产品也应该有。
我们不能只知道为什么，却不知道为什么。探究这种功能设计背后的原因，应该能找到这种功能设计带来的用户体验。如果我们找不到，那么这个功能可能就没用了。
三、角色动线设计是一条线，交互设计原则是基于不同的角色设计很多功能。不同用户进入系统后如何获得更好的体验？这就需要设计不同角色的动线。
就像逛宜家一样，走固定路线就行。每走几步，就会出现一件你比较关注的家具，功能指引路线的设计也是如此。
我举个例子吧，比如：采购系统，对于采购项目经理这个角色，如何设计系统线？
采购经理进来第一眼看到的就是消息中心，看看有没有什么待办任务或者提醒。如果有，点进去看看。
继续，你会看到你负责的所有项目的整体进度。对于那些进度严重滞后的项目，请点击查看详细信息。到底是哪个环节耽误了？
然后，期待那个不是自己分管，而是需要自己配合的采购项目的进展。
看完这些，最后，导出采购项目月报，看看数据怎么样，准备上报给领导。
这些都做好了，就可以注销系统了。
这是一个完整的用户体验线路设计，要处理的任务，延迟的项目，每月的工作汇报都是这条线路上你最关心的内容。
另外就是针对特定功能的交互设计。
很多书或文章都有详细介绍，这里就不多说了。为了保证文章的完整性，我把自己关心的一些设计原则放在这里和大家分享。
简化原则：决定你不想要什么比决定你想做什么更重要。邻近原则：将同一类别的所有功能组织在页面的同一模块中。原则：设计和功能要尽可能贴近用户的操作习惯，避免用户的思维。帮助原则：为用户提供适当的帮助，使用用户的语言，不要让用户感到困惑。响应原理：用户每执行一次操作，都需要给出一个响应反馈。容错原则：必须允许用户犯错，给用户后悔的机会。除了这些原则，我们还应该学会使用原型设计工具，如Axure或喷墨，以便将这些原则应用到功能设计中。
当然，你可以把交互设计的任务留给专职的用户体验设计师，但是你要能够解释如何设计用户体验。
第四，数据是否准确是用户体验好坏的分界线。B端产品线上线时间长了，很多都会出现数据不一致，重复等数据不准确的问题。
如果出现这种数据不准确的问题，并且长时间无法修复，对用户体验将是致命的。可能是用户一下子不信任你的系统，这个时候就到了用户体验的临界点。
所以保证数据的准确性是B端产品最好的用户体验。即使功能操作繁琐，交互设计也没那么友好。只要数据准确，系统就有价值，用户也愿意用，尤其是管理层更能感受到这些数据的价值。
在设计产品时，我们需要考虑如何保证产品数据的准确性：
即要重视业务模型的设计，准确梳理模型关系，严谨定义业务规则，避免因用户操作或其他不可预知的异常情况导致系统出现不合逻辑的脏数据。它是建立数据审核功能。通过固化审计规则，系统会自动审计数据的准确性，定期生成审计报告，并在数据出现问题时及时报警，通知运维人员进行修复。就是保留数据修改的详细记录，这是为了保护自己。先小人，后君子。很多时候，我们的企业用户会因为自己的工作失误，把问题抛给系统，说系统的数据不是他改的，而是系统出错了。这时候拿出详细的数据修改日志可以起到保护作用，用户就不敢轻易使用这一招了。
动词（verb的缩写）主动运维是提升用户体验的良药。最后说一下上线后的运维。与C端产品不同，很多B端产品，尤其是交付给中大型企业的产品，需要运维团队的支持，运维团队负责后期的系统运维。
这些运维人员要直接面对用户，他们很可能就在用户的现场。这个运维压力显而易见。
我们用的是C端产品，不管是微信还是头条。如果发现系统有问题，此时只能通过问题反馈的方式，在线提交问题工单到后台解决。
b端产品就不一样了。一旦用户发现一个更紧急的问题，一个电话就会打来，他恨不得你马上解决。
所以B端产品的运维以及及时的运维响应速度非常重要。
好的运维人员都是从解决用户的问题出发的。如果用户的问题提出来了，你一天不照顾用户，用户可能会着急，很可能会被投诉作为交换。
所以，作为运维人员，一定要学会及时应对。就算这个问题暂时解决不了，也要先回应，然后一步步汇报进展，这样用户的愤怒才会平息。
所有的运维人员都不想当消防员，希望变被动为主动，提高运维能力。要做到这一点，除了运维人员的能力之外，还需要一些高效的运维工具。除了传统的IT监控，APM还可以监控应用程序性能的各种指标。
通过部署APM工具，不仅操作员或技术人员可以更快地定位和解决问题，而且
最后，总结一下：
产品规划：准确定义产品对用户的价值，是用户体验的基础；架构设计：基于角色的功能和场景设计，会有很好的用户体验；功能：角色动线设计是线，交互设计原理是点；数据设计：数据准确与否是用户体验的分界线；线上运维：主动运维是提升用户体验的良药。
#专栏作家#奋斗De爸爸，微信微信官方账号：爸爸的客栈(ID: naiba2000)，人人都是产品经理专栏作家。10年以上产品和项目管理实践经验，关注企业供应链、数据中心、IT监控等产品。我喜欢琢磨，希望把有价值的产品创意和实践经验传递给有需要的人。
本文由人人作为产品经理原创发布。未经许可，禁止复制。
题目来自Unsplash，基于CC0协议。