08 信息架构：为什么你的客户总觉得产品太复杂？
你好，我是汤圆。
大部分B端产品在发展的过程中，通常都会演化出非常多的功能。比如CRM产品，除了客户信息管理，也有销售过程管理、市场分析等功能。
那么如何组合这些功能，让用户能清晰地找到想要的内容，就成为了一个难题。因为功能太多，又没有清晰的结构，一定会给客户带来“产品太过复杂”的感觉。这就导致了客户使用想要的功能都觉得很麻烦，最终放弃继续使用，去选择其他更优体验的产品。
还是以CRM产品为例，除了客户信息管理，也会销售过程管理、市场分析等等功能，但是客户可能只会经常使用其中关键的1-3个功能。如果展示过多的功能，往往就会出现我们刚才提到的“放弃使用”的情况。
大部分体验设计师遇到这个问题时，都会非常头疼，感觉是一个无法解决的难题，然后开始放弃解决，让自己陷入一个既想要做出好体验的产品，但又束手无措的情况中。但是不用着急，我在项目里探索了一些有效的解决方法，今天在这里分享给你，帮你解决这个难题。
复杂守恒定律
首先我们要了解的是，产品随着功能增加变得很复杂的问题，并不是近几年才出现的。早在1980年，拉里·特斯勒（Larry Tesler）就提到了一个概念，叫做“复杂性守恒定律”。这个概念是每一个B端设计师都应该了解的，因为你一定会遇到这个问题。
复杂守恒定律指的是每个软件应用都有内在的复杂性，并且这些复杂的特性是不能被移除或隐藏的，但是，你必须在产品开发或客户交互中处理它。这就提出了一个问题：谁应该接触到这些复杂性。基于这个理论，又有很多学者进行了深入研究，发现产生“复杂”是一种感觉，并不是由产品本身带来的，而是因为设计产品的人没有关注用户而带来的。
再往下深究，所谓“复杂感”，是由于设计者不了解客户的专业语言体系、以往的业务流程而带来的。也就是说，一旦你把这些业务逻辑与客户认知匹配上了，那么在客户的感知层面上，就不会觉得这个产品很复杂。
先举个C端的例子。电脑是大家每天都在用的产品，早期的电脑被称为计算机，实际上计算机在早期是非常复杂的产品，需要很专业的工程师才能进行操作，并且过程很复杂。随着技术的发展，计算机还应用了更多复杂的芯片技术、编码技术。实际上，它本身是变得更加复杂了，但用户却感觉现代的笔记本电脑越来越好用了，变得更“简单”了。
电脑本身的复杂性减少了吗？没有，甚至还有所增加。这实际上就是一个典型的复杂产品通过改变用户认知，从而在认知层面变得更简单的案例。
再来看一个项目管理的B端案例。早期项目管理也是一件非常复杂的事情，需要投入大量的人力，只要是超过10人的项目，项目记录表就会显得非常繁杂，让使用者看得头晕眼花。
项目管理本身涉及到对人、时间、进度、交付内容、交付质量多方面的管理。从产品本身的视角来看，这件事情的复杂度是恒定不变的。但转换一个视角，对于使用者来说，他只需要知道自己相关的信息，并且只需要知道最近几天与自己相关的信息就可以了。
那么在这个视角下，你就需要对产品的内容进行重新编排，实现让产品本身感知更简单的目标。
比如在国内爆火的项目管理工具Teambition以及在国外比较热门的Monday，都是在使用者视角改良产品复杂度这方面做得不错的产品。
通过这两个案例，我们能了解的是，复杂性是产品本身带来的，而简单的感受，是设计者以用户视角改良产品获得的成果。这也就是我们需要发力的方向。
B端产品通常会具备很多功能，本身的复杂性远远要高于一些单一功能的工具型产品，只具备从使用者出发改良产品这个视角还不够，只是一句空话。我们再深入一些，看看能不能使用一些具体的方法来解决B端复杂性的问题。
如何解决B端复杂性问题？
想要快速解决B端的复杂性问题，第一，是要让客户轻松地在多个功能中找到自己想要的功能，做到“找得到”。第二，是这些功能的名称一定要与它们本身的专业语言匹配，让客户“看得懂”并且“搜得到”，而不是让我们的产品设计与研发人员看得懂。
1. MECE法则：找得到
先来说如何让用户“找得到”这个问题。这里涉及到一个产品设计非常重要的步骤，叫做“信息构架”。信息架构是这个概念是从数据库设计的领域中诞生的，它是以信息作为主体对象，由信息建筑师来设计结构、决定组织方式以及归类，好让使用者与用户容易寻找与管理的一项艺术与科学。
在B端领域中，我们每个人就是一位“信息建筑师”，需要将所有的功能架构归好类，让使用者“找得到”。更具体来说，每个产品的导航栏内容结构设计，也是大家经常看到的产品脑图，就是功能构架了。
通过看阿里云与明厨亮灶的信息架构就会发现，B端产品的功能非常多，并且每个功能的名称都是非常专业化的。这就是带来客户感觉“复杂”的根本原因。那么，如何处理好这么多复杂的功能，才让客户能轻松找到自己想要的内容呢？这就需要用到MECE法则。
MECE法则的全称是 mutually exclusive and collectively exhaustive（互相独立，完全穷尽）。最早是由大哲学家亚里士多德提出的，后来由麦肯锡的咨询专家芭芭拉发扬光大。我们主要应用到的是互相独立这个理念，大部分人也经常在这里犯错，导致产品变得很复杂。
以明厨亮灶的项目举例。在明厨亮灶的项目中，有5大功能，以及接近20多项小功能，那么这些功能的组合以及命名，就成为影响客户能否找到自己想要内容的关键因素了。
明厨亮灶中，早期版本出现过最典型的问题就是分类不清晰，导致很多功能没有互相独立。比如我们的异常信息告警这个功能，在事件视频监控与违规行为记录汇总中都会出现。那么客户想要找异常告警的时候，到底要去事件视频监控里看，还是到违规行为记录中找呢？这就导致了认知上的迷惑，客户逐渐就开始觉得这个产品很复杂了。
之后，我们进行了深入研究，重新对产品的功能进行归类，这次完全从客户视角来区分内容。我们采用了前几节课里提到的3C分析法进行研究，在很多业务的案例中发现，客户本身的业务归类并不是这样的，而是按照巡查、评分、追溯、数据监控这样的业务逻辑来划分的。
这里要强调一点，客户本身的功能归类，通常也是基于业务与组织自身的结构来分配的。比如高层决策者，通常最关注的是明厨亮灶平台上线后的核心数据采集与相关趋势分析。而中层管理者，关心的是相关的信息风险管理，所以对于权限等模块会更关注。最后是执行人员，在卫生监管的业务中，执行人员最经常做的就是去巡查各厨房的卫生情况，并且处理相关异常与违规情况。
所以，新改良的明厨亮灶平台的结构，不再是按照事件视频监控与违规行为记录这样的维度来划分，而是以用户为中心，匹配组织结构与业务情况做出的优化。
这样的划分逻辑下， 大部分功能非常清晰地独立开来，满足了MECE法则，基本不再出现耦合的情况。
并且在MECE法则下，还会带来一个对B端产品发展来说非常大的好处，就是随着产品不断发展，新增的功能不会再被零散地随意堆砌到产品上。每一个新增的功能，都能快速对应到原本的大类当中。这就能够非常好地解决B端产品本身的复杂性，让客户可以清晰地理解整个产品的结构，快速地找到对应的功能。
这里有一个明厨亮灶前后一级标签的对比图。原本具备5个大功能的复杂产品，在客户眼中成为了清晰的7个功能集合，不再感觉到复杂，只需要循着自己的业务感觉，在产品中找到对应的功能，就可以简单地使用起来，达到了化繁为简的效果。
2. 语言体系：“看得懂”并“搜得到”
想要客户看得懂，有一个前提，就是必须使用客户的语言体系，而不是我们自己的语言体系。特别是做软件开发的团队，很容易忽视这一点。比如刚才提到的明厨亮灶案例中，我们以前也会用“违规”“监控”这类词汇，但实际上，客户每天的业务工作中并不会这么叫，所以总找不到我们产品对应的功能在哪里。
实际上，他们经常会叫“巡查”“追溯”这类词汇，并且他一看到“追溯”，立即就会反应过来其中有供应链管理、投诉这些信息。这个反应已经是经过多年的业务磨炼，刻入到客户的条件反射中去的。就像作为用过多年PS的设计师，一看到“钢笔工具”，就想到平滑的曲线绘制，而普通人看到“钢笔工具”，第一个反应大部分是蘸墨水写字的钢笔，这个就是对专业语言理解带来的差异。
这个语言差异还会带来一个很大的问题。因为很多平台型的B端产品都会加一个搜索功能，觉得这个可以解决掉客户找不到功能或内容的问题，但实际上这个是有前提的。如果客户脑袋里都没有“违规行为”这个概念，他根本不会输入这个词汇去搜索，而会输入“追溯”去搜索。虽然你的产品有对应的内容，但因为没有匹配上，那么客户还是什么都没有搜到，就会感觉你的产品什么都没做，带来极其糟糕的体验。
所以在B端体验的设计上，只要你的词汇没有和客户对应上，就一定会让客户产生“复杂”的感觉，这一定必须要注意。
特别是在功能归类上，因为找到功能是客户进入产品的第一步，如果连功能客户都找不到了，那么你的产品界面设计得体验再好都无济于事——因为客户根本就见不到那些内容。
总结时刻
最后，我在这里给你分享一下我之前总结的产品迭代情况。
大部分B端产品从刚建立的时候，有着1个核心功能，以及2-3个衍生功能，整体改版一次要花费10-30万的成本。到了3.0版本，很多会有3-6个核心功能，几十个衍生功能，产品内容非常多，迭代成本可能会达到几十万甚至上百万。如果是3.0后续的产品再进行整体改良，可能需要上千万的成本。
对于提供服务的企业来说，客户提出了需求，我们再去执行，当然是没有问题的。但问题是，又有多少客户的体量是足以担负这样的迭代成本的呢？快速响应，从一开始就打造体验优质的产品，才能带来好的口碑与长期的合作复购。
而信息架构这个设计环节，就是后续想要打造优秀体验界面设计的重要前提。相对于大界面的体验设计，优秀的信息构架是决定性的前置条件，没有一个好的信息构架，客户都找不到你的功能，更不要说去感受界面的体验好坏了。
所以，想做到优秀的信息构架，我们首先就要理解客户本身在B端业务中对功能的划分逻辑。并且要理解到，B端产品的复杂性是不可避免的，每一个体验设计人员都必须面对并且解决这个问题，而解决的有效方法就是采用MECE法则，进行互相独立的功能归类，并且归类的逻辑与词汇要与客户的业务语言匹配，才能达到让用户“找得到”“看得懂”的最终目标。
解惑ToB体验设计
你可以打开阿里云的官网，想一想，你认为阿里云的信息构架如何？有没有更好的优化方案呢？
欢迎你在留言区和我互动。如果觉得有所收获，也可以把给更多的朋友一起学习。我们下节课见！
- 石云升 👍（2） 💬（0）
以前做思维导图的时候，一直没有意识到还可以根据信息架构来分类。隐约有个感觉，这个很重要。可以深入实操一下。 另外分享一下以前写的一篇关于MECE的文章： MECE法则，是麦肯锡咨询顾问芭芭拉·明托在《金字塔原理》中提出的一个思考工具，它的英文缩写是Mutually Exclusive Collectively Exhaustive，意思是“相互独立，完全穷尽”，也就是不重不漏的意思。 它是一个思考方法，当我们在面对一个复杂系统的时候，我们可以试着用MECE的方法把复杂系统给拆解。通过解决这些子任务。大问题也就解决了。只要是涉及到分解问题的都可以用。 目前很多方法都是在MECE原理下创造的。比如下面常见的几种拆分法。 二分法：男人、女人。已婚、未婚。 过程法：购买前、购买中（体验）、购买后。顾客进店、店内接待、送客。 要素法：优秀员工的七种品质，供需连。 公式法：销售额 = 销量 X 单价。 矩阵法：重要、紧急四象限。能力、意愿四象限。 有没有发现，这种拆分方法，是没有重复，也没有遗漏的。那它具体能用到哪些地方呢？ 一、产品创新 有一种创新叫，旧要素新组合。当我们在分析市场，创造一个没有人做的细分领域时，可以试着从产品相关的供给（供应方）、需求（使用方）、连接（连接供给和需求）三个方面来拆分。拆分的方式可以按照二分法来拆，拆解完之后再重新组合。这样一个产品的组合式创新就出来了。 大家注意到没，在后面上图里的供给和需求，拆分并没有完全穷尽。我们要尽可能地穷尽，但有时候你太过于追求穷尽使用起来会很累。所以只要不影响我们获得想要的结果，在某一层级选择几个要素也是可以的。不过有一点可以肯定，越是完全穷尽，越容易找到很少人做的细分领域。 二、开会讨论 如果你开会的时候，提不出好的想法，那么可以试试上面说到几个拆分方法。如果是讨论流程类的问题，我们就用过程法。如果是多主体的问题，就用要素法。如果是多维度的问题，就用矩阵法。如果是转化率相关问题，就用公式法。以公式法举例，如果你们这次会议的目的是讨论如何提高销售量，而你通过公式法拆分销售额 = 流量 x 转化率 x 客单价 x 复购率。那你就可以从流量为切入点想几个解决方案。以转化率为切入口想几个方案。这样一来。你的发言一定是有效的。 三、拆解工作计划 当项目需求确定后，一个大的需求要拆成各种小的可执行的需求。这时候就考验个人的拆解能力了。 原文地址：https://xie.infoq.cn/article/6b847f7379a72619136808f15
2023-09-01 - Felix 👍（1） 💬（0）
MECE原则在我们做B端产品分类上，还是很重要的一个原则。我的问题是，如果一个功能他具备多个分类下的功能，该如何划分呢？比如明厨亮灶这种产品，里面如果回溯里要加一个评分，那是应该分在回溯里，还是评分里呢？还是重做分类，还是不应该加这个功能？
2023-06-30