篇首语

对于很多设计师来说，遇上B端产品都是一件让人感觉头痛的事情。我从16年开始进入现在的公司，到现在做了很多的后台产品(ERP，CRM，SAAS，OA等等)，有的产品是从无到有，有的产品是在原有的基础上更新，相对于C端产品，我在过程中深刻的体会到了视觉设计在后台产品中作用的有限性。

当然从一个设计参与者的角度来看，B端后台的产品并没有直接面向消费者的ToC产品那么的“火光四射”，但是B端产品对于设计师＆产品经理都有更高的能力要求，能够从容的在各种B端产品中来回穿梭的人必须要有更强的业务逻辑理解和规划能力，后台类产品设计过程中的大方向是可以借鉴并复制的，但是对于细节的拆分、功能的规划，却又截然不同。所以我把从16年到19年的感悟写下来，希望能对一些面向后台产品头痛的设计师和产品经理们有一些帮助。

什么是B端产品？

其实后台产品更严格的意义讲也是B端产品类型中的一种，当然细分的领域类型有很多，也分针对性。针对个人（小型团队）的后台产品比较容易在大众的视线里被看到，这一类中最常见的后台产品就是微信公众平台了。

（微信公众平台通过管理、分析、运营，让企业＆个人能够更好的提高服务意识）

而另一类B端的产品则是面向企业客户以及内部员工使用，一般除了被针对到的目标用户，其他的用户很难接触到。比如OA、ERP、CRM、SAAS等。跟微信公众平台不同，这些名词对于很多不处于行业中的人而言都显得比较陌生，所以我大概解释一下几种我做过的平台。

OA系统

办公自动化(OA: OFFICE AUTOMATION)是采用Internet/Intranet技术，基于工作流概念，使企业内部人员方便快捷地共享信息，高效协同工作；改变过去复杂、低效的手工办公方式，实现迅速、全方位的信息采集、处理，为企业管理和决策提供科学依据。企业实现办公自动化程度也是衡量其实现现代化管理的标准。办公自动化不仅兼顾个人办公效率提高，更重要的是可实现群体协同工作。凭借网络，这种交流与协调几乎可以在瞬间完成。这里所说的群体工作，可以包括在地理上分布很广，甚至在全球上各个地方，以至于工作时间都不一样的一群工作人员。

ERP系统

ERP是Enterprise Resource Planning（企业资源计划）的简称，是上个世纪90年代美国一家IT公司根据当时计算机信息、IT技术发展及企业对供应链管理的需求，预测在今后信息时代企业管理信息系统的发展趋势和即将发生变革，而提出了这个概念。 ERP是针对物资资源管理（物流）、人力资源管理（人流）、财务资源管理（财流）、信息资源管理（信息流）集成一体化的企业管理软件。它将包含客户/服务架构，使用图形用户接口，应用开放系统制作。除了已有的标准功能，它还包括其它特性，如品质、过程运作管理、以及调整报告等。

CRM系统

客户关系管理系统（CRM）是以客户数据的管理为核心，利用信息科学技术，实现市场营销、销售、服务等活动自动化，并建立一个客户信息的收集、管理、分析、利用的系统，帮助企业实现以客户为中心的管理模式。客户关系管理既是一种管理理念，又是一种软件技术。

SAAS系统

SAAS系统是一种通过Internet提供软件的模式，厂商将应用软件统一部署在自己的服务器上，客户可以根据自己实际需求，通过互联网向厂商定购所需的应用软件服务，按定购的服务多少和时间长短向厂商支付费用，并通过互联网获得厂商提供的服务。用户不用再购买软件，而改用向提供商租用基于Web的软件，来管理企业经营活动，且无需对软件进行维护。

B端产品和C端产品的差异？

近两年来，B端产品慢慢的成为了互联网市场上的热门。而且随着现在互联网市场的多样性，C端产品有着充足的竞品可以进行对比分析，前行的相对平顺；而B端的产品则因为对于特有业务场景的不同、业务逻辑的复杂、数据系统的串接等等，显得十分复杂。那二者之间都有哪些差异呢？

B端产品具有更强的衔接性

相对于C端产品用户群体的庞大和多种类，B端产品显得要相对专注。从16年到现在，至少我经历的B端产品有近十种之多，每一类后台产品都会有相对聚焦的用户群体以及产品目标。在做B端产品之前，我对B端产品的初步理解是大而广泛的功能集成类产品，有点类似于一个超级后台的概念。但是实际进入到行业中接触之后，才发现实际上对于B端产品而言，每个产品都是针对行业链内的某一个节点而做。

做一个比较简单的类比：如同产品设计开发的过程中，产品经理、交互设计师、UI设计师、前后端开发、测试等，大家所需要功能都非常的多，但是使用的工具都截然不同。但是每一个工具对于产品设计开发过程中的推动意义都是关键的。

功能核心点的不同

实际上在2018年我做了一个很难实现的事儿，我会在每个月坚持跟行业内的两名设计师一对一的沟通，聊一聊对于各自行业的认识。通过这个举措我大概了解了很多中高级UI设计师们的想法。其实大部分的UI设计师对于未来的规划都是比较有野心的，不管是未来想到专注视觉亦或者想要跨向交互的设计师，对于产品的业务逻辑都希望可以进一步的了解，参与到产品的前期规划讨论中。

但是，在谈论到B端产品的时候，大部分的人又会觉得如果是B端产品还是算了吧。有一个设计师跟我说B端产品的理解成本太高了，又没有办法做到像C端产品那样有具体功能的侧重取舍，想要玩转B端产品之前首先要讲整个行业链路里的内容都走一遍，对于很多设计师来讲太痛苦了。

举一个例子好了。

例如微信阅读，产品的核心侧重在于”阅读功能“，而”想法管理、阅读标注、社交分析、读书排名“这一些功能都属于Kano模型中的“兴奋型需求---即使在期望不满足时，用户也不会因而表现出明显的不满意”。

但是同样的情况出自于B端产品，可能就截然不同了，对于B端产品而言，功能是多而必要的。例如OA办公系统中的“申请提报功能”，这个功能针对的根本不是针对于单一类型的用户、单一类型的场景。而是针对很多不同岗位的用户以及不同的提报需求场景。所以很多初入B端产品的UI设计师而言，他们认为“申请提报功能”只是一个信息输入页面，但是实际工作的时候却要按照七十多种不同的提报方式去设计内容，并且根据提报需求的不同，后续还会有更多的差异化设计（附件上传、日报提交、订单流审批等等）

B端产品的客户也许不是你的用户

这也是B端产品和C端产品的一个不同。首先B端产品面向的是企业老板，满足企业老板的需求，让这一类用户满意才是关键；而C端产品面向的是个人用户，只要做到用户体验十分良好并且给予一些增进用户留存的机制就可以运营的很好。

两者之间的差异性在于B端产品在满足客户的需求后，间接服务于用户；而C端产品直面用户。这其实就造成了B端产品在设计的过程中需要平衡“客户”与“用户”之间的关系，个人认为一个健康的B端产品应该是既满足“客户”的需求，又提升“用户”的体验，不然很可能会出现“客户好评 and 用户差评”的情况。

但是对于很多老板而言，在同样的产品服务之间，他们往往会倾向于付款使用服务，这其实也是B端产品设计中一个比较有趣的点。

面对B端产品应该如何入手？

很多人在设计B端产品的时候总是觉得很难受，感觉可延伸的方向有很多，却又没有一个十分合适的切入点。这是因为"我们距离用户的真实场景偏离太远，导致我们在设计中很容易理所当然的赋予给用户大量无用的东西。偏离了用户所需要的主要轨道。"

在我看来B端产品的设计没有固定的功能模式，而一味的照抄竞品在这一行业中其实也是非常危险的行为。大部分B端产品设计的本质其实是解决客户在真实场景下遇到的问题，给予用户更便捷的管理方式和更多的利益价值。

但是所谓知易行难，从一个产品的设计者（产品经理＆设计师）在产品的规划过程中要做到以下几点：

了解基础业务流程

在这里讲的业务流程并非是单一产品的业务，而是从行业链路的角度上讲，要真实的理解行业过程中每一个环节的过程。例如最近几年专注的快销行业，最起码我们要知道从品牌商、供应商、经销商、二批商以及门店终端以及其他各个渠道的最基础的业务运作方式。这样其实会让我们在功能的思考过程中避免很多低级的错误。

写到这里其实可能有的朋友看不懂这一步的作用，例如可能会觉得，我做一个数据分析后台，为什么要懂全部环节的基础业务流程呢？那我继续做一个最简单的类比：就如同我们对于互联网有了初步了解之后，就会自然而然的明白腾讯系的产品基本不会对接支付宝，而支付宝的钱无法通过微信去支付。

功能流程归类

这个应该不需要再多解释了，完美的流程归类会让产品的需求方、设计和开发的对接方以及用户都非常满意。

价值体系搭建

价值体系的搭建是整个产品中最核心的点。何谓价值体系？对于B端的产品而言，客户最关心它能为实际的工作带来哪些便利而并非这个界面做的多么的好看以及用户体验多么棒。所以对于一个B端产品，解决问题的价值就是最好的推广。按照实话讲，从这个角度来看，B端产品的设计需要对用户更深层次的了解和判断，了解用户的核心价值，围绕核心价值搭建产品的功能以及任务优先级。

整合设计＆持续迭代＆调整方向

在设计的过程中我们是十分痛苦的。因为B端产品面向的客户大部分都是在行业中沉浸了很多年的老板或者相关业务部门。这种特殊的情况对我们有利有弊。好处是我们的客户对于业务相关的蓝图十分的清晰；坏处是每一个人对于自己的业务都有更美妙的“憧憬”。

例如我们在下访调研的过程中跟经销商聊了一下（快消行业），不同的经销商对于自己生意管理的方法不同，人员组成（业代、库管、内勤）也完全不同。所以有的老板会跟我聊一聊，有没有什么更新鲜或者更有挑战性的玩法儿，能让下面的业代收集到更多有价值的数据；有的老板会跟我聊产品的功能太多了，手下的业代使用起来不方便，意见很大。

（门店拜访是经销商业代的日常工作，有的业代热衷抄单，有的业代喜欢用APP录入，各有不同）

所以对于我们而言，面对这种在宏观角度上大方向一致而微观角度各有不同的用户群体，要学会整合和克制。如果有了一些比较亮眼的功能或者想法，尽可能要做到小幅度快节奏的持续迭代，在迭代的过程中逐渐收集用户的想法。

对于设计部门，在设计B端产品的过程中需要进行更严格的内外部评审。从功能规划＆交互设计这一步就应该开始评审，评审交互设计的功能点有没有遗漏？交互框架搭建的过程中是否考虑到了随着产品发展带来的更多功能的扩展性？修改某个功能是否会导致其他的功能出现问题？在修改交易（促销）规则的时候是否会对现在的产品造成风险？这些都是需要进行不断的评审、磨合、测试才能逐渐完成上线的。在这中间我们要不断的调整B端产品设计的方向（包括产品功能的优先级排序）。

B端产品的功能设计也许并不在于亮眼，而是在于均衡和稳定。C端产品的每一个用户都是单一的个体，通过C端产品带来某种生活中的便捷与享受，功能规划失败，很可能会失去某些群体的用户，但是可以通过迅速的功能迭代在下一轮赢回来；而B端产品上的每一个客户(用户)，每一个后面都有一张庞大的关系网，对于他们而言，这是生意(工作)的重要组成部分，是没有办法拿来冒险的。如果因为产品的问题导致客户(用户)出现了损失，这种客情关系是很难挽回的。

如何提升B端产品的品质？

学习成本＆感知成本

对B端产品来讲，设计师在设计的时候是不需要耗费太多的思考的，只是去按照交互设计师的规划堆砌图表和列表。但是对于使用者来讲，但是其中纵横交错的商业逻辑和业务逻辑却是给用户搭建了一个十分高的门槛。

赋予价值

赋予价值是常见的提升B端产品品质的一种方式，这里说的赋予价值跟上文所述的“价值体系搭建”并不相同。

其实作为B端产品的设计者，我们期望通过自己的努力让产品有更多的玩法儿、让视觉有更多的花样，我们期待以此来获得用户的认同。但是从B端产品用户的角度来说，这些并非是他们重点关注的点。例如我们将一个进销存软件所有的功能都考虑清楚、所有的使用场景下都可以得到满足，都不如通过优化流程、提升产品使用效率去将使用者给解放出来。

其实在这里可以大胆预测一下，在未来所有B端产品的设计者都会想办法降低用户的使用时长，“用完即走”可能会成为未来工具类B端产品设计的一个设计原则。

降低妨碍＆功能引导

B端产品因为集成了很多的功能和信息，所以在设计的过程中尽可能合理的安排信息的布局是非常的重要的。常见的方法是优化字段以及页面元素，让用户看起来更直接，并且加入一些功能引导部分，让用户对于一些功能有很快的认知（这个功能是什么＆我能用这个功能做什么）

用户体验要素上说过“不管用户访问的是什么类型的网站，它都是一个‘自助式’的产品。没有可以事先阅读的说明书、没有任何操作培训或讨论会、没有客户服务代表来帮助用户了解这个网站。用户所能依靠的只有自己的智慧和经验，来独自面对这个网站。”

页面清晰简洁＆场景下保持高效

B端产品的用户一般比C端产品的用户要更有专业性，同时也更有耐心。但是如果我们的页面设计的功能过于复杂或者为了丰富页面加入很多的冗杂字段，会对用户造成不必要的影响。

而高效则是另一个在交互设计中需要注意到的问题，高效从一个角度上讲，是减少用户不必要的操作＆页面的跳转，例如ERP系统中的客户管理，在客户列表页修改客户资料的时候，尽可能使用弹窗，这样会大大减少页面跳转的频率；

但是与此同时，减少页面跳转并不代表真正的高效，再次举例ERP系统，所有的订单需要按照指定的流程一步步进行操作而并非一步到位，这样虽然页面的跳转增加，但是可以避免操作出错给用户带来更大的困扰。

设计的一致性

当然看到这一点很多成熟的设计师可能会表面毫无波澜，内心甚至想笑。但是实际上对于B端产品而言，需求、开发、上线，这会是一条漫长的战线。除非是一些大公司，否则很少有设计师能只跟随一个产品走到最后。当你两个月之后再入手参与这个项目，你会发现你对这个产品开始陌生了。往往就会产生同一个设计师做出来的设计图像是两个设计师做的一样。

坚持设计的一致性是很重要的：例如产品的交互操作（弹窗的样式、列表页左右功能布局）、按钮的不同状态、字体大小的规范、系统导航条的样式及位置、切换页面的触发等等，都属于一致性中必不可少的因素，当产品的一致性程度较高，就可以降低用户的学习成本、提高用户的使用效率。

结尾

不管是面向大众的C端产品，还是面向后台商业链的B端产品，每个产品都在各自的位置上发挥着各自的价值，一款B端产品要做的不是功能的广而全，而是能通过具体的用户分析建立相对完整的场景搭建，在我们搭建好的场景之上给予用户最完整的功能使用以及用户体验，在后期我们可以考虑通过一些比较合理的方式将用户从漫长的产品使用中“解放”出来，给予用户高效和自由。

另外，希望做B端产品的设计者在和需求方沟通的时候能够想办法提升沟通的效率，不要被需求方牵着走，也不要一味的沉醉在自己的设计中，要通过设计去辅助技术与业务，这样才能在B端产品中最大化实现自己的价值。