无论是从市场上一些颇有见地的分析比较B端C端设计的文章来看， 还是从工作中实际遇到的问题来分析， 从B端体验设计的每个环节中， 都能强烈地感觉到B端体验设计遇到的挑战， 其中感受最深也最难跨越的， 当属同理心挑战。

挑战1，同理心挑战

C端产品中， 交互设计师的任务是发现用户需求，定义用户价值，解决用户在使用场景中的痛点，并推动项目达成这一目标。作为交互设计师， 同理心正是我们发现用户需求， 模仿用户行为， 揣摩用户意图， 锁定用户目标，解决用户痛点的法宝， 我们之所以可以这么做， 是因为在C端用户体验的设计中， 交互设计师大部分情况下都或多或少地就是用户本身，或者带有用户属性。

同理心挑战

B端产品， 是根据客户的战略或服务于线下已有的流程， 构建生态体系， 推动将流程系统化，管理数据资产，获取核心的生产经营数据， 提高生产经营效率，帮助企业决策。一般情况下， 交互设计师的B端产品的用户属性往往无限趋近于零。以市场上常见的B端产品为例：

1. 财税系统 FI（Financial Institution）：财务、费用、差旅等相关系统，相关企业有金蝶、用友等；
2. 办公自动化 OA（Office Automation）：协同工作， 提高效率， 相关企业有钉钉、Teambition等；
3. 客户关系管理 CRM（Customer Relationship Management）：相关企业有销售易、纷享销客；
4. 人力资源 HR（Human Resource）：HR管理系统，人员信息， 业绩评定， 薪酬考勤， 招聘升职的管理系统， 比如各大公司的HR管理系统；
5. 企业资源计划 ERP（Enterprise Resource Planning）：包括企业的生产资源计划、制造、财务、销售、采购等功能，如SAP中国；
6. 云计算（Cloud Computing）：云计算亦即以互联网为中心，在网站上提供快速且安全的云计算服务与数据存储的平台，国内的相关企业有阿里云、腾讯云、网易云等；
7. 大数据（Big Data） ：大数据是规模大到在获取、存储、管理、分析方面大大超出了传统数据库软件工具能力范围的数据集合，相关企业有网易大数据、Google Analytics等；
8. 医疗类产品（Healthcare）：面向医务工作者的工作平台，相关企业如Varian；
9. 物流平台（logistics）：解决现代企业物品流通的所有物流需求的平台, 比如京东物流、阿里菜鸟等；
10. 内容管理系统 CMS（Content manage system) : 企业或政府内部用于信息管理、信息发布和网站维护的内容管理和发布应用系统， 比如网易云的CMS系统。

市场上常见的B端业务

考察以上的业务类型， 可以说交互设计师平时除了在财税系统和OA系统有一部分报销或者工作协同使用需求外， 其他几乎什么都挨不着边，更不要说专业挑战巨大的医疗系统和技术挑战很大的云计算和大数据系统了。实际工作中，尤其是在刚刚开始从事B端交互设计的起初一段时期， 越是设计类出身的交互设计师， 越是会体会到一种无从下手的感觉， 很大一部分设计基本思路都是产品和开发告知的， 因此也难免会产生一种无法对项目产生影响的无力感。

因此， 如果将B端交互业务分为几个象限的话，越是处在右下方的产品， 对大部分交互设计师的门槛越高。



象限分析

要更好地理解B端业务，没有其他的应对办法， 必须认真做好以下两点：

1. 谦虚踏实地学习业务

以云计算大数据为例， 首先要吃透自己手里的设计工作的业务细节， 向产品和开发同事详细了解产品的需求，弄清每个步骤的业务逻辑，甚至开发的实现模型， 测试对细节的要求等等…… 在确认需求的环节， 当需求方希望你把一些较为难于理解的业务设计成某种他希望的样式时，一定要将业务逻辑理解透彻再考虑应该如何进行设计实现。要问问为什么业务流程是这样， 为什么用这几个菜单， 这个填代码的区域， 要用户填的是什么意义的代码，列表的每一列的含义是什么， 详情的每个指标说明了什么含义？自己要清楚知道整个页面里的每个控件， 控件的每个选项的业务含义是什么。要探讨流程的业务合理性， 越是复杂有争议就越要尽量多提供几套方案以供讨论；要斟酌用词是否清晰和正确， 陈述是否专业严谨又易于理解，尽量少带语气等等。

2. 做好用户调研工作

积极地与用户接触，参与或组织用户调研。用户可以请多名用户做访谈， 做好访谈脚本， 了解现有设计有哪些痛点。这些真实的痛点， 往往是产品、架构师无法预料的。

举例来说， 在云计算业务由面向小B用户到大B用户的转变过程中， 通过对目标用户的深入访谈， 了解到现有的云计算产品实现对大B用户来说，除了存在一些普通的有共性的体验问题之外， 还存在大量的批量操作问题，批量删除， 批量启动， 批量查找， 批量显示等， 是需求确认和设计过程中始料未及的。

挑战2，目标用户的挑战

C端产品的用户往往就是购买者， 而且用户往往数量众多， 有时可以达到数亿的规模， 这种情况下， 用来进行用户画像建模的数据量大， 所以用户画像比较精准，细分的用户画像都能比较方便地建立起来。

实际工作中发现， B端产品的用户数量却往往比较有限。更重要地， 用户往往不是客户， 而是一个组织， 包含三个维度， 包括决策者， 管理者和执行者，其中决策者是客户， 而管理者和执行者是不同角色的用户。决策者作为B端产品的客户， 并不一定需要经常使用产品， 但决定是否购买产品。因此， 在客户这个层面， 要从企业管理的层面去理解客户的需求， 考虑产品能否帮助客户理顺管理流程， 提高效率，节约成本， 获得稳定安全的资源， 提高客户的购买意愿。而针对管理者和执行者的用户层面， 由于需要满足不同角色间的生产协作需求， 满足不同层级和组织内外的协同沟通需求， 因此在具体设计操作层面， 要做好不同层级的用户画像， 为不同层级的用户提供必需的使用权限， 根据用户的分级去做好每一级用户的体验设计。

由于系统的复杂， 在执行者这个层面， 也往往存在很多不同的角色， 不同角色间同样有不同的需求， 在设计中要分辨清楚， 协调好解决方案。

举例来说， 在大数据产品中， 数据开发和数据分析师， 都是大数据系统的用户， 但是他们的需求有一定的差异。在搜索表的时候， 数据开发更关心自己常用的收藏表和项目内的公共表， 而数据分析师并不关心固定的表， 但是关心他浏览过的表的记录， 因此， 在提供表搜索的设计时， 要把这两个层面的需求同时考虑进去， 也就是说如何在同一个页面， 设计能同时满足两种不同的需求，以便数据开发工程师和数据分析师都能方便地使用产品。

角色分析

关于目标用户的确认， 在具体的实践中还往往出现以下一些问题，是在设计分析阶段要尽量避免的：

问题一：为自己设计。

一些软件相关专业出身的设计师相对比较理解一些底层的业务逻辑， 但实际上他们并非真正的用户。这部分设计师存在自己制定框架制定规矩， 让用户在此框架里玩的想法，但不去理解用户到底想要什么。当用户明确提出体验问题时，又从实现模型出发认为设计就应该是那样的， 不愿也不应该寻找替代的设计， 导致用户易用性受到非常严重的影响。这种设计不是以用户为中心的， 而是以设计师本人为中心的， 极不可取。

问题二：为程序员而设计

出现这种问题， 原因往往是设计师过分认同开发工程师的意见，同时认为B端产品一些交互需求的实现会影响开发工作量，特别是底层的开发工作量有可能会变得巨大， 因此对开发工程师强调的事情一概言听计从，但是遇到用户体验的问题也不愿意迭代， 认为二次返工会导致开发工作量变大，也不符合开发的想法。

问题三：单纯为用户而设计

从用户的口中往往可以收集到很多问题， 尤其是大客户的用户反馈， 往往有很多的要求甚至抱怨。此时要求产品经理和交互设计师通力合作， 制定出清晰的产品路线图， 为每一次升级迭代指引出方向。而不是用户怎么说就怎么改， 过几天听到其他用户反馈可能又迷惑是不是再改回去， 失去了对产品主线的清晰把握， 这样的交互往往会改成四不像。

挑战3，设计标准的挑战

B端交互的产品设计， 由于有着清晰的目的性， 比如财务系统类、协同操作类、云计算大数据类、工业互联网类等等B端业务的体系， 都有着清晰的操作目的，它们显然都不是带着用户漫无目的地遨游互联网，或者消磨时间， 或者满足虚荣心， 或者发泄情绪， 或者满足用户其他的欲望， 而是有清晰精准的业务目标，因此“效率第一”就成为B端交互设计的第一标准。追求花里胡哨的用户界面， 超出主线的附加用户功能， 过分情感化的体验设计， 都不应该是B端交互需要遵从的设计标准。

根据以往经验的总结，拆解到具体的B端交互设计上， 是要求设计师做到以下几点：

1. 功能清晰， 模块划分准确

功能模块分类清晰， 用户一目了然， 减少学习成本。

2. 交互流程精准切合业务实际场景

各步骤之间衔接自然流畅， 精准切合业务实际的流程。

3. 体验统一而有序

使用相同的控件， 保持体验的一致性。

4. 用户理解简约通俗

设计时所用的语言和一些使用习惯应该尽可能与目标用户熟悉的行为保持一致， 以提高用户的使用体验和工作效率。

5. 界面精简， 色调冷静

避免使用艳丽的颜色， 影响用户的心情，干扰用户的信息识别。尽量使用中性或偏冷的颜色。

类似书法一样，我们追求B端设计能够在法度中见细节见功夫。

挑战4，设计方法的挑战

解决了以上的问题， 就进入了具体设计的步骤。但是对B端产品来说， C端交互的设计流程不能简单地套用。

从用户的使用场景上看， C端产品用户使用产品随时随地， 用户关心的是用户自己， 解决的是自己的痛点， 而不是进行协作。

从设计师进行设计的角度， C端产品的设计有一个发散的过程， 交互设计师可以通过使用头脑风暴的方式寻找一些相对有突破的交互解决方案，增加一些有趣的功能点 ，以交互设计师的身份来驱动和丰富产品的设计。但是对交互设计师来说， 在B端交互的起始阶段就开始发散是比较危险的，因为对业务不十分熟悉， 用户反馈也相对缺乏，对产品的理解也不深入， 因此不建议过早地驱动产品的设计。

总结来说， B端产品设计， 不要着急进行设计发散， 首先要解决的是合理的功能划分，这类似于B端产品的横梁与立柱，在具备了比较好的功能模块划分和导航逻辑的情况下，根据产品的需求， 开发人员的建议，按照设计师整理的思路，在设计标准的约束下， 使用统一的控件， 以相对比较稳定的模式将交互系统搭建起来。这个过程， 比较类似于乐高积木的搭建， 或者是楼房的搭建。这些统一的控件就是我们建筑用的砖瓦或者乐高组件。更进一步， 我们把一些基本控件组合成更大一些的功能模块， 类似建筑中使用的吊装模块，当产品需要这些功能模块的时候， 可以快速地铺上去。

控件不是凭空编造的，而是通过对业务细节进行学习、思考和设计， 考量需要使用的控件和控件组合， 之后再反过来丰富控件库，并制订好控件库的套用规则，包括使用的场景， 交互的细节等。更进一步，在对业务体系越发熟悉了解的情况下，做到控件使用、定义、组合的融会贯通。

控件和业务的关系

以乐高的方式搭建B端用户体验的设计有着显而易见的好处：

1. 一致性得到良好保证
2. 易于协作
3. 易于快速搭建
4. 在需求理解尚不深入且时间有限的情况下能够快速提供较为合理的体验解决方案

挑战5，测试方法的挑战

在可用性测试环节， B端用户测试的挑战主要的问题在于用户人数上， C端业务的用户数量较大， 测试目标用户容易寻找，但是B端产品的有效测试对象并不多，有时非常有限。因此， 在B端产品的定性测试方面， 人员可以贵精不贵多， 要尽量深入挖掘服务对象的使用反馈。另外， 用建立用户交流群的方式以及时拿到用户的反馈， 快速响应。

定量研究方面， 根据过往的经验， 由于用户数量不够， 通常很难建立起理想的定量分析模型。举例来说， 表单设计如何用定量数据来分析的模型， 虽然可以通过埋点获得一些有效的数据， 但是如何用有限的数据量在较多干扰项的情况下理清用户在填写表单时的行为和操作问题，始终没能获得一个令人信服的结果。

由于有效测试用户和有效数据量的原因， B端交互的测试要尽量深入挖掘定性研究的结果， 为设计和迭代服务。

新的挑战

功能模块划分好了， 框架结构建立好了， 控件库做好了， 对业务流程的理解越来越深入， 此时设计师能够快速搭建产品的交互， 设计效率大幅度提升， 原来一周可以做完的工作，现在3、4天可以完成。但是这样快速搭建的功能，是否就是最优的解决方案呢？

挑战6，找寻更加优秀的设计方案

技术上来说， 新的挑战存在于交互设计方法本身，由于所有功能模块全部使用常用控件搭建， 限制了一些更有想象力的设计方法， 整体上没有交互方式的突破。积极寻找新的交互方式丰富原有的用户体验就摆在了B端交互设计师面前，而设计师也更应该从设计方案的突破上证明自己的价值。

突破乐高——寻找更优秀的设计方案

突破口在哪里？

用户反映存在问题的功能点往往会成为设计的突破口，实践证明， 在此处寻找新交互方式的成功率比较高， 且这种优化方式的成本比较低。

举例说明：在云服务器的监控设计中， 通过对用户工作场景、操作行为和用户需求进行分析，了解到用户在使用性能监控时遇到的问题及建议，由此指导性能监控概览优化方案的设计。

改版前的性能监控概览页面主要存在以下问题：

1. 没有达到概览的效果

概览需要快速了解云服务器的运行全貌，而列表的样式一页只能显示20~100个云服务器的监控数据，不能满足大批量用户（如某些产品需要上千台云服务器）概略地了解所有云服务器的监控状况。尽管列表支持每一列指标排序，但对于整体了解所有云服务器所有指标的情况不是一个最佳的方案。

2. 不能满足目标用户的工作场景

一般使用该页面的目标用户为运维工程师，他们主要负责产品自身核心业务系统运行情况的监控、问题定位和故障排除等方面的运维工作。所以对于运维工程师来说，快速了解整个产品业务系统的监控状况和排查相关问题就显得的特别重要，而现有的样式及交互无法做到快速了解和排查出现的相关问题，从而影响运维工程师的工作效率。

3. 不能体现问题的优先级

当产品出现多个问题时，运维工程师需要判断出现问题的优先级，及时处理那些问题严重、可能影响整个产品正常运行的问题，对于那些问题严重程度一般、不会影响整个产品正常运行的问题可以以后处理。而现有的样式及交互无法整体概览所有问题，也就更无法区分问题的优先级了。