A/B 测试是一种随机测试，将两个不同的东西（即 A 和 B）进行假设比较。A/B 测试可以用来测试某一个变量两个不同版本的差异，一般是让 A 和 B 只有该变量不同，再测试目标对于 A 和 B 的反应差异，再判断 A 和 B 的方式何者较佳 ¹。A/B 测试的前身为双盲测试 ²，在双盲测试中人员会被随机分为两组，受试验的对象及研究人员并不知道哪些对象属于对照组，哪些属于实验组，通过一段时间的实验后对比两组人员的结果是否有明显差异。在各种科学研究领域中，从医学、食品、心理到社会科学及法证都有使用双盲方法进行实验。

一个简单的 A/B 测试流程如下：

1. 对目标人群进行随机划分，以进行有效的独立随机实验。
2. 对不同分组应用不同的策略。
3. 在确保实验有效的前提下，对不同分组的结果进行分析，以确定不同策略的优劣。

A/B 测试的主要目的是帮助我们更加科学的判断不同策略的优劣性，避免拍脑门的决策，不给杠精们互相 BATTLE 的机会。同时我们也需要认识到 A/B 测试只是一个工具，它能够帮助我们对产品和策略进行不断优化，但对产品和策略的创新更多还是需要洞察力。它可以让我们在已达到的山上越来越高，却不能用它来发现一座新的山脉。一句话：A/B 测试不是万能的，但离开 A/B 测试是万万不能的。

A/B 测试的科学性

流量分配

进行 A/B 测试的第一个问题就是如何划分用户，如果采用上面简单五五开的方式我们一次只能做一个实验，当我们需要同时做多个实验时就无法满足了。如果对用户分成多个桶，当桶的数量过多时，每个桶中的用户数量就会过少，从而会导致实验的置信度下降。

为了保证可以使用相同的流量开展不同的实验，同时各个实验之间不能相关干扰，我们需要采用正交实验。正交实验的思想如下：

每个独立实验为一层，层与层之间的流量是正交的，流量经过一层实验后会再次被随机打散。

有些情况下实验并不是独立的，例如同时对按钮和背景的颜色进行实验，按钮和背景颜色之间并不是独立的（即有些按钮和背景颜色搭配从设计角度是不可行的，没有必要进行实验），这种情况下我们需要采用互斥实验。互斥实验的思想如下：

实验在同一层进行流量拆分，不同组之间的流量是没有重叠的。

在 A/B 测试中，当多个实验内容相互影响应选择互斥方法分配流量，当多个实验内容不会相互影响应选择正交方法分配流量。更加精细的流量分类和控制可以参考 Google 的论文 Overlapping Experiment Infrastructure: More, Better, Faster Experimentation ³。

评价指标选择

在设计实验之前我们需要明确实验的目标，根据目标才能确定合理的评价指标。更多情况下我们应该从业务的视角出发选择合适的评价指标，我们以风险策略模型实验为例，我们可以从技术和业务角度选择不同的评价指标：

1. 技术角度：准确率和召回率
2. 业务角度：客诉率和追损金额

单纯从技术角度出发我们会忽视很多现实问题，例如两个策略的准确率和召回率差不多，但识别的结果人群不一样，这些人造成的损失也可能不一样。因此能够帮助我们追回更多损失同时有更小的客诉率才是更优的策略。

在进行实验时结果指标至关重要，但有时我们也应该关注一些过程指标。以页面优化实验为例，可能的过程指标和结果指标有：

1. 过程指标：页面平均停留时间，页面跳出率等
2. 结果指标：商品加购率，商品转化率等

策略和模型最终都是要为业务服务的，因此我们应常关注业务指标，一些常用的业务指标有：点击率（CTR）、转化率（CVR）、千次展示收入（RPM）等。

有效性检验

当实验完成得到结果后，我们还需要判断实验结果是否有效，这部分主要依靠统计学中的假设检验进行分析。针对两个实验在确定合理的统计量后，需要构建如下两个假设：

• 原假设 $H_0$：两个实验的统计量无差异
• 备选假设 $H_1$：两个实验的统计量有差异

对于假设检验只可能有两种结果：一个是接受原假设，一个是拒绝原假设。在进行假设检验过程中，容易犯两类错误：

第一类错误（弃真）即原假设为真时拒绝原假设，犯第一类错误的概率为 $\alpha$，即显著水平。第二类错误（取伪）即原假设为假时未拒绝原假设，犯第二类错误的概率为 $\beta$。

在进行有效性检验时我们有多个指标可以参考：

1. P 值。P 值就是当原假设为真时，比所得到的样本观察结果更极端的结果出现的概率。如果 P 值很小，说明原假设情况的发生的概率很小，而如果出现了，根据小概率原理，我们就有理由拒绝原假设，P 值越小，我们拒绝原假设的理由越充分。
2. 置信区间。置信区间就是分别以统计量的置信上限和置信下限为上下界构成的区间。置信水平是指包含总体平均值的概率是多大，例如：95% 的置信水平表示，如果有 100 个样本，可以构造出 100 个这样的区间，有 95% 的可能性包含总体平均值。在 A/B 测试时，如果置信区间上下限的值同为正或负，则认为存在有显著差异的可能性；如果同时有正值和负值，则认为不存在有显著差异的可能性。
3. 统计功效。一般情况下我们希望拒绝原假设，得到新的结论，即在进行 A/B 测试时希望实验组的效果优于对照组。也就是我们希望不要出现在应该拒绝原假设时却没有拒绝的情况，即犯第二类错误。统计功效就是我们没有犯第二类错误的概率 $1 - \beta$，在进行 A/B 测试时表示当两个策略之间存在显著差异时，实验能正确做出存在差异判断的概率。

综上，我们可以认为当 A/B 测试实验数据在 95% 的置信水平区间内，P 值小于0.05，功效大于 80% 的情况下，实验结果是可信赖的。

A/A 测试

在做 A/B 测试的时候，有时尽管我们发现 A/B 两组有明显差异，但我们依旧无法确认这种差异是由于实验条件不同还是 A/B 两组用户本身的差异带来的。尽管 A/B 两组用户是随机抽样，但两组用户在空跑期（即实验条件一致）也会出现显著差异。因此为了避免这个问题，我们会选择进行 A/A 测试，即在正式开启实验之前，先进行一段时间的空跑，对 A/B 两组用户采用同样的实验条件，一段时间后，再看两组之间的差异。如果差异显著，数据弃之不用，重新选组。如果差异不显著，记录两组之间的均值差，然后在实验期结束时，用实验期的组间差异减去空跑期的组间差异得到最终实验结果。

A/A 测试也会存在一些局限，在实际情况中，组间差异是一定存在。因此在这个前提下，可以用统计方式来衡量差异大小，在计算实验效果的时候，把差异考虑在内即可。差异产生的主要原因就是“随机性”，我们同样可以利用置信度和置信区间来描述 A/A 实验的波动。在进行实验时直接进行 A/B 测试，不需要考虑 A/A 测试，在分析结果时，需要考虑 A/B 测试实验之间的差异要大于 A/A 测试实验之间的差异。

为什么构建设计语言？

统一

通过设计语言可以在整个平台中统一颜色、字体、组件、动效等各种规范，避免由于设计师的个人特点导致产品风格不一致。

体验

优秀的设计语言符合大众审美，可以提高产品的可用性和易用性。设计语言可以使用户能够与具备一致性的应用进行交互，让用户在使用过程中获得愉悦，提升用户体验。

效率

优秀的设计语言使得设计和开发团队能够快速、经济、高效地进行开发、重构和迭代产品。通过不断更新和完善的文档库，可以改善团队之间的协作，提高生产力。

品牌

设计语言的构建可以传达一个统一的公司品牌形象。设计语言让产品具有自己的身份，使其在市场上的众多产品中更容易被识别出来，加深用户对品牌的印象。

设计语言构建

在此我们借助语言学的角度来讨论数字化产品的构建 ²。在语言应用中，我们通常会涉及语法、语素、语句、语义、语境、语气、语素和响度等维度，通过不同的组合达成应景的表达和适时的沟通。

语法

设计语言中的语法即设计价值观和设计原则，这是构建设计语言系统的起点，用于传达品牌主张或设计理念，它将指引业务设计执行的方向。

制定设计原则时，首先研究用户特性，聚焦产品核心价值，然后通过脑暴等形式选择有特点的维度，结合用户体验与品牌属性将其视觉化，最后用简要的语言归纳出来。

Ant Design 设计价值观 ³

	自然 数字世界的光速迭代使得产品日益复杂，而人类意识和注意力资源有限。面对这种设计矛盾，追求「自然」交互将是 Ant Design 持之以恒的方向。
	确定性 界面是用户与系统交互的媒介，是手段而非目的。在追求「自然」交互基础上，通过 Ant Design 创造的产品界面应是高确定性、低合作熵的状态。
	意义感 一个产品或功能被设计者创造出来不只是用户的需要，而更多是承载用户的某个工作使命。产品设计应充分站在工作视角，促成用户使命的达成；同时，在「自然」、「确定」之上，兼顾用户的人性需求，为工作过程创造富有意义感的人机交互。
	生长性 企业级产品功能的增长与用户系统角色的演变相生相伴。设计者应为自己创造的产品负责，提升功能、价值的可发现性。用发展的眼光做设计，充分考虑人、机两端的共同生长。

Ant Design 设计原则 ⁴

亲密性

如果信息之间关联性越高，它们之间的距离就应该越接近，也越像一个视觉单元；反之，则它们的距离就应该越远，也越像多个视觉单元。亲密性的根本目的是实现组织性，让用户对页面结构和信息层次一目了然。

对齐

正如「格式塔学派」中的连续律（Law of Continuity）所描述的，在知觉过程中人们往往倾向于使知觉对象的直线继续成为直线，使曲线继续成为曲线。在界面设计中，将元素进行对齐，既符合用户的认知特性，也能引导视觉流向，让用户更流畅地接收信息。

对比

对比是增加视觉效果最有效方法之一，同时也能在不同元素之间建立一种有组织的层次结构，让用户快速识别关键信息。

重复

相同的元素在整个界面中不断重复，不仅可以有效降低用户的学习成本，也可以帮助用户识别出这些元素之间的关联性。

直截了当

正如 Alan Cooper 所言：「需要在哪里输出，就要允许在哪里输入」。这就是直接操作的原理。eg：不要为了编辑内容而打开另一个页面，应该直接在上下文中实现编辑。

足不出户

能在这个页面解决的问题，就不要去其它页面解决，因为任何页面刷新和跳转都会引起变化盲视（Change Blindness），导致用户心流（Flow）被打断。频繁的页面刷新和跳转，就像在看戏时，演员说完一行台词就安排一次谢幕一样。

简化交互

根据费茨法则（Fitts’s Law）所描述的，如果用户鼠标移动距离越少、对象相对目标越大，那么用户越容易操作。通过运用上下文工具（即：放在内容中的操作工具），使内容和操作融合，从而简化交互。

提供邀请

很多富交互模式（eg：「拖放」、「行内编辑」、「上下文工具」）都有一个共同问题，就是缺少易发现性。所以「提供邀请」是成功完成人机交互的关键所在。

邀请就是引导用户进入下一个交互层次的提醒和暗示，通常包括意符（eg：实时的提示信息）和可供性，以表明在下一个界面可以做什么。当可供性中可感知的部分（Perceived Affordance）表现为意符时，人机交互的过程往往更加自然、顺畅。

巧用过渡

人脑灰质（Gray Matter）会对动态的事物（eg：移动、形变、色变等）保持敏感。在界面中，适当的加入一些过渡效果，能让界面保持生动，同时也能增强用户和界面的沟通。

即时反应

「提供邀请」的强大体现在 交互之前 给出反馈，解决易发现性问题；「巧用过渡」的有用体现在它能够在 交互期间 为用户提供视觉反馈；「即时反应」的重要性体现在 交互之后 立即给出反馈。

就像「牛顿第三定律」所描述作用力和反作用一样，用户进行了操作或者内部数据发生了变化，系统就应该立即有一个对应的反馈，同时输入量级越大、重要性越高，那么反馈量级越大、重要性越高。

虽然反馈太多（准确的说，错误的反馈太多）是一个问题，但是反馈太少甚至没有反馈的系统，则让人感觉迟钝和笨拙，用户体验更差。

Alibaba Fusion 设计价值观 ⁵

化繁为简的交互模式

面对互联网产品高迭代节奏和复杂的中后台场景，将复杂的业务组件抽象为用户标准认知层的交互方式，这套组件库来自于阿里巴巴上百个中后台场景的抽象结果，试图建立中后台 web 设计标准。

驾驭技术

你用的所有设计资料，小到 sketch 样式工具中的颜色、字体、字号、投影、边框、尺寸；再到组件，大到一套完整的中后台产品系统，均能找到其对应的代码，完整的释放整个团队的前端生产力。

追求新鲜，潮流

设计风格每年都会更新换代，由于 Alibaba Fusion 设计系统中的颜色、字体、字号、投影等样式均可通过线上配置修改，这也决定了它可以快速（甚至 15 分钟内）完成整套设计系统的样式迭代。

聚变/裂变

通过在 Alibaba Fusion 设计系统原则下，变换样式、多维度定制组件交互形式，可瞬间获取属于自己业务属性的设计系统；我们期待有无数业务线能够通过 Alibaba Fusion 的设计系统原则聚变出符合各类业务场景的 Fusion 生态系统。

效率

Alibaba Fusion Design 希望构建一套提升设计与开发之间 UI 构建效率的工作方式，让 UED 的工作能够尽可能多的投入在 UE（User Experience）的用户调研、用户体验、商业思考，而在 D（Design）的过程中更多的投入与创意而非日复一日的重复绘图。

腾讯 Q 语言理念 ⁶

	统一体验 QQ 作为一个社交平台，会容纳多样性的功能与体验，为了降低用户在不同场景功能下的学习成本，并提升易用性，统一体验是提升平台易用性的关键基础。同时有助于提升各角色间的协作效率。
	基因体现 当今同质化的社交应用越来越多，QQ 作为横跨多时期多平台的社交应用，一方面需紧贴时代趋势，在众多应用中脱颖而出，另一方面有足够的历史底蕴，应强化自身基因特征，提升整体品牌认知。
	社交向善 社交应用会融入琳琅满目的娱乐化规则与玩法，但吸引年轻人的不应只是单纯娱乐消费，需要考虑社交娱乐的本质初心，QQ 更倡导用户在一个积极健康，安全贴心，触动情感的环境进行社交，并最终导人向善。
	高效娱乐 伴随信息传播便利性提升，用户需要更高浓度的信息和更快的娱乐方式。用户时间愈加宝贵，偏向消费耗时较短的短视频、信息流等内容，希望更快找到喜欢的内容，以及更高浓度的内容。
	兴趣细分 互联网使用场景更细分，兴趣爱好更加细分深入。各种兴趣圈、游戏圈、粉丝圈等年轻用户基于互联网衍生出来的圈子，需要有更细分深入的功能场景去承载。线上和线下联动是细分圈子持续活跃的关键。
	社交压力 互联网信息传播的扩散效应，以及社会的复杂性给用户带来更多社交压力，原创越来越少。可以通过丰富的形象建立和维护体系增强用户的社交动力，引导产生更多原创内容和互动。

腾讯 Q 语言原则 ⁷

	活力灵动 对年轻人有吸引力，传递积极乐观情感，有怦然心动的感觉。
	亲和自然 体验过程犹如与朋友打交道，亲和自然，懂我所想。
	自我有范 用户能无压力表达自我，满足不同人群个性诉求。

语素

视觉基础是构成设计语言的最小单位，就像语素是语言中最小的音义结合体。在原子设计理论中，它属于最小粒度的元素，通常包括：色彩、布局、字体、图标等。

色彩

无论 UI 还是平面，颜色是视觉传达的最核心也是最基本的语言，不同的主色，会给人不同的视觉感受，同样的主色不同的配色，视觉感受也会不同。通常一款产品的色彩体系包含：品牌色、功能色、中立色三个部分：

品牌色：代表品牌形象及 VI 识别的色彩，品牌色的数量可以一个也可以多个，用于主按钮、主 icon 等需要突出品牌特征的地方。

功能色：代表明确的信息以及状态，如成功、出错、失败、提醒等。功能色的选取需要遵守用户对色彩的基本认知，如绿色代表成功，红色代表警示或失败。

中立色：灰或饱和度低的颜色，用于界面设计中的字体、背景、边框、分割线等，中立色通常是按照透明度的方式实现。

布局

空间布局是体系化视觉设计的起点，和传统的平面设计的不同之处在于，UI 界面的布局空间要基于「动态、体系化」的角度出发展开。在中后台视觉体系中定义布局系统，可以从 5 个方面出发：统一的画板尺寸、适配方案、网格单位、栅格、常用模度。

统一画板：为了尽可能减少沟通与理解的成本，有必要在组织内部统一设计板的尺寸。

适配：在设计过程中还需要建立适配的概念，根据具体情况判断系统是否需要进行适配，以及哪些区块需要考虑动态布局。

左右布局的适配方案：常被用于左右布局的设计方案中，常见的做法是将左边的导航栏固定，对右边的工作区域进行动态缩放。

上下布局的适配方案：常被用于上下布局的设计方案中，做法是对两边留白区域进行最小值的定义，当留白区域到达限定值之后再对中间的主内容区域进行动态缩放。

网格单位：通过网格体系可以实现视觉体系的秩序。网格的基数为 8，不仅符合偶数的思路同时能够匹配多数主流的显示设备。通过建立网格的思考方式，还能帮助设计者快速实现布局空间的设计决策同时也能简化设计到开发的沟通损耗。

栅格：以上下布局的结构为例，对内容区域进行 24 栅格的划分设置，如下图所示。页面中栅格的 Gutter 设定了定值，即浏览器在一定范围扩大或缩小，栅格的 Column 宽度会随之扩大或缩小，但 Gutter 的宽度值固定不变。

模度：模度是为了帮助不同设计能力的设计者们在界面布局上的一致性和韵律感，统一设计到开发的布局语言，减少还原损耗。

字体

字体是界面设计中最基本的构成之一。通过定义字体在设计上的使用规则，从而在阅读的舒适性上达到平衡。确定字体主要从下面四个方面出发：字体家族、主字体、字阶与行高、字重。

字体家族：优秀的字体系统首先是要选择合适的字体家族。提供一套利于屏显的备用字体库，来维护在不同平台以及浏览器的显示下，字体始终保持良好的易读性和可读性，体现了友好、稳定和专业的特性。在中后台系统中，数字经常需要进行纵向对比展示，将数字的字体 font-variant-numeric 设置为 tabular-nums，使其为等宽字体。

主字体：基于电脑显示器阅读距离（50 cm）以及最佳阅读角度（0.3），将自私设置为 14，以保证在多数常用显示器上的用户阅读效率最佳。

字阶与行高：字阶和行高决定着一套字体系统的动态与秩序之美。字阶是指一系列有规律的不同尺寸的字体。行高可以理解为一个包裹在字体外面的无形的盒子。

字重：字重的选择同样基于秩序、稳定、克制的原则。多数情况下，只出现 regular 以及 medium 的两种字体重量，分别对应代码中的 400 和 500。在英文字体加粗的情况下会采用 semibold 的字体重量，对应代码中的 600。

图标

图标是 UI 设计中必不可少的组成。通常我们理解图标设计的含义，是将某个概念转换成清晰易读的图形，从而降低用户的理解成本，提升界面的美观度。在我们的企业级应用设计范围中，图标在界面设计的诸多元素中往往只占了很小的比重，在调用时也会被缩到比设计稿小很多倍的尺寸，加上在图形素材极度丰富并且便于获取的今天，在产品设计体系中实现一套美观、一致、易用、便于延展的图标体系往往会被不小心忽略掉。

语句

组件就像由若干个语素组成的语句，比如一个基础按钮，通常就是由颜色、字体、边距等元素组成。而我们平时所说的组件库，其实就是一部词典，其中包含了设计系统中所需的基础组件与用法，在界面设计中也具有较高的通用性。

语义

符号是语言的载体，但符号本身没有意义，只有被赋予含义的符号才能够被使用，这时候语言就转化为信息，而语言的含义就是语义。在视觉传达设计中也一样，使用的图标或图形，需具备正确的语义属性。如果商场导视设计中非要使用「裙子」图标来代表「男厕」入口，如此混淆语义挑战公众认知，那就等着被投诉吧。

语境

语境包含 3 个维度：一是流程意义上的上下文，二是产品属性中的语境，三是用户当下所处的环境。

当设计需要对上下文进行特别处理时，有可能对话的层级次序是受限于屏幕稀缺性，通常可采用 z-depth 叠加（Material Design 属性）、步骤条、元素关联转场动效等方式。举个常见的例子，当用户发起一个删除数据的请求时，界面会弹出一个二次确认的模态会话，用户点击确认之后才会执行删除操作。

针对用户当下所处的环境来适配界面语境，常见通过界面换肤的手法来实现，比如微信读书等阅读应用为用户提供白天模式或黑夜模式的选择。用户所处的外部环境因素可以很大程度上决定界面语言的应用，就好像在菜市场买东西要靠吼，在图书馆借书仅需要用肢体语言便能达成。

语气

交互界面通常需要使用说明或提示文案来指导用户完成操作，大多数情况下都是使用第二人称，就像在与用户对话，从以用户为中心的角度上讲，建议保持谦逊、友善的语气，尽可能避免使用晦涩的专业术语，谨慎使用带有强烈情感属性的感叹号，或过于口语化的语言。另外，语气的拿捏也将直接影响到与用户的距离感，以及当下的应景度。

语速

语速在这里指的是界面的信息密度，在不同的场合对语速的控制能够提升接受者的体验，视觉设计也同样需要注意把握间距与留白，网格系统在这里可以起到「节拍器」的作用，借助节拍器可以让设计更具节奏感。而交互意义上的语速，更多体现在操作路径的长度，以及动效的速率。

下图分别展示了 QQ 音乐和富途牛牛两种不同场景的「语速」：

响度

其实就好像我们说话可以通过音量大小来控制信息的可感知程度，希望接受者听清楚的就说大声一点。汤姆奥斯本（Tom Osborne）的视觉响度指南（Visual Loudness Guide）是一个如何系统地处理按钮和链接的例子，它们不是单独列出，而是作为一个套件呈现，并且根据每个元素的视觉冲击力会相应的拥有一个「响度」值。我们在构建设计语言系统时，也同样需要设置梯级「响度」的按钮、字重等组件来满足不同场景的表达需求。

设计语言列表

Role-Based Access Control

RBAC (Role-Based Access Control，基于角色的访问控制) 是一种已经广泛应用于各种管理系统的权限管理模型 ¹。在 RBAC 中，操作权限与角色之间建立关联，再通过在角色与用户之间建立关联来完成对用户的授权，大大提高了权限控制的灵活性。在 RBAC 中包含几个关键的概念：

资源，权限，角色和用户之间的关系如下图所示：

「资源」和「权限」之间为多对多的关系，「权限」和「角色」之间为多对多的关系，「角色」和「用户」之间亦为多对多的关系。

RBAC0

RBAC0 为 RBAC 中最简单最基础的权限模型，包含了用户，角色，权限之间的关系，如下图所示：

用户，角色和权限之间都可以是多对多的关系，在系统分工简单权限清晰明确的情况下，用户和角色之间也可能是多对一的关系。

RBAC1

RBAC1 在 RBAC0 的基础上引入了角色继承的概念，添加了「子角色」，上级角色可以继承下级角色所有的权限。

例如，一个公司的不同人力资源副总监分管不同的职能，因此具有不同的权限，而人力资源总监则应该具有所有人力资源副总监的权限。同时，人力资源总监也可能具有其他人力资源副总监都不具有的权限。

RBAC2

RBAC2 在 RBAC0 的基础上增加了一些限制，引入了 SSD (Static Separation of Duty，静态职责分离) 和 DSD (Dynamic Separation of Duty，动态职责分离)。

SSD 主要应用于用户和角色之间，主要的约束包括：

• 角色互斥约束：同一个用户仅能分配到互斥角色中的一个。例如：财务系统中一个用户不能同时分配会计和审计两种互斥的角色。
• 基数约束：一个用户拥有的角色是有限的，一个角色拥有的权限是有限的。
• 先决条件约束：用户在获取更高的角色之前需先拥有低级的角色。

DSD 主要应用于会话和角色之间动态地限制用户及其拥有的角色和相应的权限。例如：一个用户在系统中拥有两个不同的角色，但在使用系统时只能激活其中一个角色。

RBAC3

RBAC3 是 RBAC1 和 RBAC2 的合集，既包含了角色分层也包含了相关约束。

权限扩展

接下来我们探讨在 RBAC 的基础上在真实的 ToB 产品中又有哪些权限扩展，这里有时我会以「种植」业务的 SaaS 为例进行简略分析。我们将权限又分为「功能权限」和「数据权限」两个部分，如下图所示：

功能权限就是指我们具体能够干些什么，例如：育苗，除草，施肥等等。数据权限是指我们是对谁做这些事情，例如：是对北京的实验大棚除草，还是河北的生产大棚施肥。

ToB 产品的销售对象并非个人，而是一个组织，在此我们引入「组织」的概念：

对于一个组织，我们设置有「功能池」和「数据池」。功能池即组织购买的产品的功能集合，一个组织的用户所能够使用的功能受限与此，并由组织的系统管理员分配功能池中的功能。数据池即组织自己的相关数据集合，由组织的管理员对不同的员工进行分配。

对于功能权限和数据权限，均为一个树状的层级关系，以功能权限为例，层级如下图所示：

功能的层级和菜单的层级有一定的对应关系，层级不易过深，这部分将在下文菜单部分详细介绍。数据的层级则需要根据产品涉及的具体业务做出相应的规范要求，例如：「根」-「种植场」-「种植区」-「种植大棚」-「种植地块」。同时，为了方便层级的扩充，在实现层面上不建议提前把所有层级固定死，可以采用父子层级的形式循环关联。

权限分配

在介绍如何根据上述设计进行权限分配前，我们再引入一个概念，「用户组」：

当一个组织中有大量用户需要具有相同的权限时，为了避免给每个用户分配权限导致的繁琐操作，可以将这些具有相同权限的用户归入一个用户组。对该用户组赋予一定的权限，则该用户组下面的所有用户自动具有相应权限，当需要取消其中某些用户权限时，仅需要将其从该用户组中移除即可。理论上，「用户」和「用户组」以及「用户组」和「角色」之间都可以是多对多的关系。

下图为一个最细力度的权限分配示意图：

首先，我们暂时限定一个用户仅能够隶属于一个组织，因此该用户所能够具有的最多的权限即为该组织所购买的产品的功能权限和组织自己的全部数据权限。

其次，一个最基本的权限应该是由一个功能权限对应一个数据权限构成的。这里面的功能权限和数据权限可以是任意一个级别的，同时当具有高级别的功能权限或数据权限后，子级别的相应权限自动获得。

最后，权限、角色、用户组和用户之间均可以是多对多的关系。

虽然通过很多概念的抽象使得权限管理变得相对简单，但是由于理论上支持各种细粒度的操作，在一定程度上又会加重权限管理的运维成本。在一个 ToB 产品的前期，组织的管理员可能对整个系统不是很熟悉，这样权限管理的工作会落到内部管理员的头上。当随着产品的不断发展，组织和用户的量级不断变大，内部管理员仅需为每个组织开通一个组织管理员并赋予该组织的所有权限即可，该组织内部的权限管理则交由组织的管理员进行运维即可。

菜单，页面和组件

以上我们都是从业务逻辑的角度解释权限控制，接下来我们从用户交互的角度出发简单阐述一下权限控制在用户交互上的体现。下图为一个 ToB 产品的原型界面：

在这个界面中，我们粗略的将其中的元素划分为三大块：「菜单」，「页面」和「组件」。这个划分并不是很准确，甚至可以说一定程度上概念之间有重叠，这样划分仅仅是为了更好的对应到上文涉及的相关概念上。

上文中我们提到一个角色的权限可以是任何一个级别的功能权限和数据权限的组合，同时权限、角色、用户组和用户之间都可以是多对多的关系，在此我们假设后台已经通过查询获得到了一个用户的所有权限。

菜单

菜单对应到主要是功能权限，但不是所有的功能权限都会以菜单的形式展现出来，因此我们可能还需要维护一套菜单的层级关系以及同功能权限的对应关系，或者我们直接利用功能权限的层级关系，但需要在里面补充上是否作为菜单显示的属性。具有不同权限的用户看到的菜单也会是不一样的。

在菜单设计时，建议的原则是层级不要过深，过深的话从交互上就会导致你的菜单像极了「箭头型代码」。

理论上，所有包含子功能的父功能都不代表一个具体的操作，一般仅仅是为了维护一个分组而创建的。

页面

页面并不是浏览器里面的整个页面，这里我们特指不包含菜单的部分。当我们单击一个功能菜单时，对应的页面则会相应的显示出来。当然，我们知道单击按钮 (下文会提到的组件) 也可能会打开一个新的页面，这种情况我们在下文中再展开说明。当我们单击了一个叶子界别的菜单后，其实我们已经使用了一个权限，一般情况下对应的是对一个资源的查询。

组件

页面中包含了操作的结果信息，一般情况下这些信息是不可交互的，同时页面中也包含了大量可以交互的地方，这里我们称其中的部分为组件，例如：按钮等。当然还有一些被我们在通常情况下也称之为的组件的元素，例如：输入框，下拉框等等，虽然他们也有交互功能，但是一般情况下他们并不会触发一个权限操作，因此这里我们就先将组件特指那些可以产生权限操作的元素。

一个页面可以包含多个组件，也就是说一个页面并不一定仅对应一个权限操作，可能是多个权限操作的集合。所以简单的说我们可以将功能权限设置的比菜单多一个级别，功能权限的倒数第二级对应叶子菜单，功能权限的最后一级对应页面上的组件。

权限运维

权限的精细化管理和运维成本是相互矛盾的，想更加精细化的管理权限必然会增加运维成本。因此一个 ToB 的产品到底使用什么力度的权限管理更加合适呢？我想这没有一个准确的答案，从个人角度给出两点有参考意义的设计原则：

1. 客户需求。ToB 产品吗，最终是要拿来卖的，跪添甲方爸爸就好，甲方爸爸的需求就是合理的需求，无需质疑。说的有点过了，意思其实就是尽可能满足合理客户需求的前提下，制定合适的权限管理系统。
2. 成本合算。有的时候客户也不是很清楚到底需不需要精细化的权限管理，那么问题就又抛回给了产品经理，那么我们需要考虑更多的是当下的实现成本和后期的改造成本。这是一个很现实的考虑，如果业务 KPI 压力比较大，有时候我们宁可承担更高的改造成本也会先实现一套简单的权限管理先用着。但是我个人认为，在研发资源相对充足的前提下还是尽量将权限系统设计完善，因为这是一个系统很底层的部分，甚至会影响后续所有的业务功能逻辑的设计和实现。

权限运维是一个很耗费人力的工作，解决这个问题没有太好的途径。提高用户的交互体验，编写简单易懂的使用说明书，只有将一个组织的权限管理交到组织的管理员手里。才能够真正解放内部管理运维人员的工作时间。