翻译：April.H  审校：戴猫子 |   UXRen翻译组 #366译文
作者：Yichen He
原文标题：《Designing for enterprise vs. designing for consumers》

 

那些关注用户体验的人们经常问我一个问题：什么是B端的用户体验？它与C端的用户体验有何不同？作为一名过去5年多主要从事B端IT产品的设计师，在这里给大家讲述一些我的想法。

首先，B端产品通常有2种类型：企业内部产品（Internal Solutions）和企业对企业的服务产品（B2B）。

企业内部产品的用户体验设计有一些独特性：

 

你的工作（可能）永远与你的作品集无缘

很遗憾，几乎所有企业内部产品或项目都被严格的保密协议（NDA）保护着。

绝大多B端项目都是为特定用户提供的专门内部流程。这意味着除了那些每天盯着它用的用户，其他任何人都可能不会看到你的设计。即使你设法获得了将其放入自己作品集的权限，也需要抹掉所有敏感的数据才行。

不过幸运的是，大多数有足够能力来构建自己的定制IT解决方案的公司通常规模很大，而且它们的品牌可能带有足够的“影响力”，这样，项目身价得以抬高，也能让设计师进入面试的下一步流程。

 

测试对象虽然意愿很高，但总是很忙

设计企业内部所用产品的优点：你的未来用户将会是你的同事们。因此，在进行可用性研究时，你无需担忧任何层面的法律问题。另外，由于大多数内部项目都是为了优化和改进现有的工作流程，你的用户往往会非常愿意配合你的调研工作。因为设计不当的产品让他们的工作饱受折磨，因此尽早获得反馈对他们来说是最有利的。

但这其中的弊端是，由于你的同事们需要平衡全职工作，你很可能无法占用他们的宝贵时间。如果你能解决这个问题，他们通常会提供比您预期更多的反馈。

 

 

关于B2B的一些潜规则

您可能无法（完全）满足最终用户

对于C端产品，如果太丑或不好用，消费者可以拒绝使用。而B端产品即使学习成本比较高，但企业仍然可以“命令”所有员工学习这些用于开展业务的专用软件。

B2B产品最终将出售给业务决策者，然后再推给（最终）用户。他们更关心的是量化提升效率（efficiency）和安全性（security），同时预防错误（preventing errors）。大多数组织都在寻找一种解决方案来替代和/或优化现有流程。

这并不是说企业软件不应以用户友好为目标，但通常情况下，只要能够实现某些被企业视为至关重要的目标，其他能省则省。对底线（bottom line）的影响有时会成为最重要的因素。

全球各大企业的用户体验设计领导者仍在争夺一席之地，以证明优质设计的价值。不幸的是，许多企业的用户体验设计师只能在满足业务目标、技术要求和用户需求之间无奈徘徊。

像在大多数项目中一样，在企业领域里，如果可以证明更好的用户体验可以量化地提升生产率，比如可以节省金钱，这样你就有了一个绝佳的机会和挑战。

 

被“鲸鱼用户”左右

如果你在B2B领域工作，可能会很熟悉“鲸鱼用户（whales）”的概念。通常，他们是带给我们最多收入的客户，因此在某个特定产品的路线图中拥有极大的影响力。由于较少的鲸鱼用户简化了需求收集和确认过程，有时你的工作会非常顺畅，但不幸的是，这也可能导致你忽视掉很大一部分用户群体的意见。

我们见过诸多“被需要”的功能看起来并不适合大多数工作流程的案例（因为这是鲸鱼用户的特性）。通常，决策只是为了“去执行”，因为销售团队已经在下一个版本中承诺了这一点，而这个核心客户占产品收入的40％。这通常会使得产品对于其他用户而言就有些随机且不合逻辑了。

通常而言，在设计师进入管理层之前，他们很难影响到销售团队等强大的利益相关者的决策。潜在的利益冲突无疑是需要整个设计团队共同去面对的，大家需要平衡产品的长期愿景和立竿见影的“快速制胜”二者之间的冲突，以便为产品提供可拓展的设计和构建道路。

 

企业总是在旧版系统上运行

几乎所有财富500强的公司都是通过并购而成长为庞然大物的。

每一次的并购，都会将一个完全不同的系统和工作流程修补到现有的系统和工作流程中。很多开发于90年代的软件仍在诸多大型公司中运行。尽管从概念上看，“整合一切（consolidate everything）”似乎很容易，但是协调数据库和系统的过程着实很繁琐，且需要足够的时间。

B端用户体验的大部分工作是将用户从一套旧版（有时是手动）的工作流程中解放出来的艰巨工作。这涉及到对用户目标及多个系统的深入了解，需要我们列出规划，识别冗余和协同效应，然后将其与边缘案例相结合，以检验它产出的结果是否与当前操作模式的产出一致（如果不能优化的话）。

尽管过程并非总是如此艰难，B端软件依旧比C端复杂得多，因为即使其概念是“从0开始做新系统”，其数据还是全部来自于一堆与之配套的旧系统。在系统级别上思考流程、提出正确的问题并有效记录文档的能力是此类项目中最有用的技能。

我不是开发人员，所以我不知道我从Google里找的这张图片是否是能够准确展示典型的后端体系结构。

我所知道的是，对于每个项目来说，开发人员都会创建一个外观相似的图表，该图表展示了数据的来源和去向，它非常复杂，并且在提取，存储和推送数据时可能受到一系列限制。

 

条款和规则

大多数企业或组织需要遵循一套严格的政策法规，并且通常受到各种管理要求的约束。

常见的例子包括：法律/隐私要求（例如GDPR），国际化要求（例如日期格式，语言），无障碍（例如WCAG＆ARIA），安全性等等。

这些规则中的每一条都来自于某领域的专家、某类别的检查清单（checklist）抑或是一系列更为模糊情景下的最佳实践（这些实践基于特定的方案和用例）。C端APP监管日渐常规化，同时，由于诸多企业或组织掌握的敏感数据极具货币价值，其受到的监管和审查也在不断增加。

当然，这个问题的答案显而易见，你的确切问题是存在第三方解决方案的，但是由于某些规则或规定，你可能根本无法使用它。

由于必须满足很多这样或那样的标准，对于用户来说，最终的设计往往不太理想，虽然乍一看可能并不明显，但这也是历史上许多政府软件的设计看起来很蠢的原因之一。

 

慢慢改进

与上面的观点类似，B端产品用户的独特之处在于他们对变化的抗拒心理。这意味着你需要认真思考工作流程改变后的结果，诸如使用不同的颜色，或是调整页面内某个按钮的位置等简单变化。

我们甚至还没有谈及信息架构。当你开始做信息架构时，卡片分类研究可能会告诉我们现有的导航设计是完全错误的，或是导航里的某些分类实际上应该嵌套到其他地方。不过你很快就会发现，当实际执行这些变化时，你将面临巨大压力。

知道何时依赖自己的研究和专业知识，何时推进，何时放慢步伐是很关键的，这样你才可以避免疏远过多的用户。毕竟对于这些用户来说，过去几年的工作流程已经根深蒂固，他们需要时间、资源和指导来学习或重新学习这些系统的使用。

尽管他们可能会拒绝改变，但这绝对不代表我们作为UX专业人士就无法引领他们拥抱变化，我们要做的便是了解他们的痛点并在设计时时刻考虑到用户的最大利益。

 

信息密度

许多旧版的B端app产品都有一个共同点，那就是它们的信息密度非常高。

理想的解决方案也许是隐藏所有不必要的信息，仅显示刚需的信息，但是“隐藏掉错误内容”的风险可能非常巨大，以致于不得不将其保留在不断增加的的实体屏幕上。

这就容易导致打包的屏幕设计极大增加了用户的认知负担。而这些负担之所以被用户“接受”，就是因为他们必须且只能“学习”如何使用该软件来完成工作任务。

此外，对于许多管理或监控类的产品，用并别模式查看信息进行比较和参考是非常重要的。复杂的非线性（Complex non-linear）的工作流使得界面设计更具挑战性，因为许多选项都需要既可随时访问又不能妨碍其他操作。

有个很好的例子：为什么Bloomberg（上图）的UI看起来比Robinhood（下图）复杂1000倍？

结论便是，B端产品的界面里，需要牺牲留白空间以展示更多信息的情况并不少见，因为用户经常需要查看更多信息以便完成更复杂的任务。

 

你的机遇

随着公司或组织越来越依赖技术，B端产品的用户体验设计将成为许多公司的主要竞争优势。

如果你具有拥抱复杂性、平衡多个利益相关方观点，并在约束内进行创新的能力，你便能轻而易举的杀入B端软件设计领域。

随着机器学习等诸多振奋人心的新技术出现，各种业务会带着其庞大而杂乱的数据库排队等候。UX将站在如何产生有价值的见解的最前沿，以便弄清用户想要从这些数据中获取什么以及如何对其进行操作和访问。

虽然在很长一段时间里，dribbble（追波）上的精美视觉设计仍将占有一席之地，但更繁重的任务还会落在那些不起眼的B端设计师身上：比如设计电子表格、数据集、草图原型、投入调查以及数小时与用户和利益相关者的交谈和测试。

最终出现在用户面前的内容可能并不完全整洁和简单，但请你相信，在成为备受瞩目的明星B端产品前，其每一处基准点都经过了UX设计师的严格审查。我们的用户已经全力以赴地使用这些产品努力工作，我们的产品也通过清除一些障碍来减轻用户的负担，这已经很不错了。

如果您以前从未从事过B端产品的设计工作，那么希望这篇文章可以很好地介绍这个人数不足的领域所面临的挑战。在不久的将来，我计划发布另一篇专门介绍为什么我喜欢B端产品UX设计的文章，请继续关注！

 

原文来源：https://uxdesign.cc/designing-for-enterprise-vs-designing-for-consumers-36a16f2281c2(2020.12.11)
版权声明：该文章在UXRen公众号（cnUXRen）首发后方可转载，转载时请注明出处及译者、审校者信息，如有违背，UXRen社区保留侵权追责的权力。

14+