浅谈复杂系统的设计治理

说到系统，我比较认可的一种解释是：“系统是指将零散的东西进行有序的整理、编排形成的具有整体性的整体。”所以系统是具有整体性，同时也具有叠加性。整体性是指系统需要协调的处理内部零散的子系统或者子功能来对外展示统一性，叠加性是指系统是可以叠加的，复杂的系统可以由多个子系统甚至子子系统整合而成，例如人体有消化系统、呼吸系统、运动系统等，而呼吸系统又包括呼吸道和肺部两个子系统。

钱学森先生在系统科学的研究中对系统进行了一个概括性的分类，他开创性的将系统分为简单系统、简单巨系统、复杂巨系统和特殊复杂巨系统（社会系统）。钱先生对系统的理解远非我能比拟，但我对钱先生的这个分类十分认同，所以斗胆把这个分类引入到我的设计实践领域，所以我接下来讲的系统与钱先生说的系统并不是一个系统，特此说明。

我对简单系统的理解是可以由一种或几种规则支配的系统，这些规则可以被抽象和归纳出来，例如经典物理学领域的牛顿三定律。阿里云产品发展之初就可以被视为一个简单系统，因为整个公司的业务不超过5款。产品的形态单一，功能简单，设计的方案一只手都数的过来。随着业务的发展，简单系统开始演化，从5款产品衍生出了5条产品线，此时的系统虽然容量扩展的不少，但之前的设计框架和思路还是可以从容支撑的，设计师的工作主要集中在大量的输出设计稿。从系统的多样性和复杂度上来说提高的不明显，依旧可以用通用的框架逻辑来做批量化的设计输出，此时的系统可以看做是一个简单巨系统。

但系统的进化过程是非线性的，短短几年的时间，阿里云的产品体系就拓展到了覆盖IAAS、PAAS、SAAS以及行业应用等不同赛道的200多款产品，成长速度之快超出预期，且看不到发展的边界。整个传统行业的数字化转型都在催生不同的解决方案、而这些解决方案又需要大量的云计算产品来协同支持。由于组织调整的原因我有3年的时间不再负责具体云产品的设计，3年后再接手时，云产品家族已经从最初的几株央央小苗变成了一片生机盎然的茂密森林。不同领域的云产品形态各异，功能繁多，相互间有错综复杂的协同关系，但又有独立发展的动机和欲望，此时的系统就有点复杂巨系统的味道了。

当我开始踏入这片几乎看不到阳光的密林后，接踵而来的混乱打得我措手不及。因为缺少规则和管理，各个产品线野蛮生长，设计方案五花八门，有的参考竞品A，有的觉得竞品B的思路更符合自己心意。技术上也百花齐放，把控制台当做新技术框架的练兵场，一时间Angular JS、Node JS、jquary、React等各种技术架构，如雨后春笋般在控制台体系中肆意生长。用户用不同产品会用到形态各异的组件和完全不同的操作逻辑，如果不是在左上角有个阿里云logo，很难想象这些产品是属于同一家公司的。

在混沌中摸爬滚打两个月后，我突然意识到一个问题，系统越复杂，通过探寻规律来找最优解的方式可能越不可行。

作为设计师，我们常常挂在嘴边的一句话是“给用户极致的体验”，对于一个功能相对单一，用户群体可控的简单系统来说，追求极致体验可能会比较实际。比如，“躺在床上看电视”这个行为的极致体验对于我来说，就是要把零食柜、饮水机、饮料机等合理的规划到我的床边，外加一个距离适中的卫生间，在我伸手可触及的地方就可以完成吃喝拉撒的所有需求，我会觉得这种体验“非常极致”。但如果把行为拓展到我在卧室生活的极致体验的话，需要考虑的问题就指数级增长了，除了看电视、我还要睡觉、看书、锻炼身体等等等等。同理，如果把人群拓展到老人、男人、女人等更广泛的范围，极致体验可能就是个伪命题了。

面对复杂系统，设计师如果过于追求“极致体验”会陷入无从下手甚至自我怀疑的困境，这是我在接手野蛮生长后的控制台时最真切的感受。对于复杂系统来说，维持子系统间的和谐与稳定，让整个系统朝着可持续发展的方向演进，会更有意义。如果系统中的各个子系统都各自追求“极致的体验”，那整个系统可能会迅速的瓦解，最终产生新的平衡。想清楚了这一点，我对控制台的设计思考渐渐从追求“极致”转向到了构建“和谐”。面对“杂草丛生”的控制台，在设计策略上，更多的思考如何守住体验的“底线”，如何把体验这个虚的事情更好的治理起来。

谈到治理，我很喜欢治理理论创始人詹姆斯·罗西瑙对治理的表述，他的表述有两个核心点，一、治理是一种流通于不同利益群体规则空隙间的原则、规范和决策程序；二、治理的目标是解决和整体不同利益冲突方的关系让系统保持平顺。作为控制台的体验owner，在协调好各方利益和需求的基础上，我需要尽快找到体验治理的“原则、规范和决策程序”，再具象化一些是一个核心原则、一份指南和规范以及一套评价和执行机制。

看过《用户体验要素》的对于经典的用户体验分层理论应该都不陌生，里面有提到用户体验三原则，可用性、易用性和创造/愉悦性。从治理和发展的角度看这三个层次，可用是治理侧，易用和创造性是发展侧。如果交叉上简单系统和复杂系统，这三个原则有些捉襟见肘。复杂系统存在着子系统间的交互耦合，可用、易用、创造性更多的是在描述一个单一系统的体验水平，无法把子系统间的协调关系反应出来。经过审慎的思考后，我们丰富了用户体验的三原则，在可用性和易用性之间增加了一个新的原则——一致性。

一致性的提出就像一个爆破手，轰开了当时控制台的毒障，让我找到了破局的入口。控制台上有不同的交互方式和形态各异的UI组件本质上都是缺少一致性的约束，大家各做各的，缺少协同，老死不相往来。有了一致性的原则，各个产品就必须遵循这个原则并约束自己的行为，这就像给即将溃散的系统套上了“紧箍咒”，避免系统持续的恶化。

一致性原则的提出相对容易，但对于如何圈定一致性的范围和度量一致性的程度我们还是零经验，翻遍了国内外的相关资料和学术论文，可以学习和参照的内容不多，只能自主创新。

我们从人认识世界的过程中得到了灵感，人类认识世界是一个由静到动再到时间感的过程。所以，我们把一致性也分成了三个维度，分别是物理、行为和认知的一致，其中物理一致和行为一致是路径目标，认知一致是牵引目标。

简单讲，物理一致是希望子系统间通用组件、模块、场景的设计表达上保持一致，让大家看上去同属一套体系；行为一致是希望子系统间通用功能的流程和链路保持一致，让用户能够用起来一样，降低学习成本。认知一致是水到渠成的结果，就像我们看到宝马的双口进气格栅就知道是宝马而不是奔驰。关于一致性的相关内容如果要讲可以单独再开一篇，感兴趣的可以看下《从业务解法到学术论文：一致性量化评测体系》。

一致性是追求的目标，但目标距离现实还有遥远的距离。我们不希望阿里云控制台是一个没有任何个性的平庸系统，打造一个能够满足阿里云复杂产品发展需要的一套指南和规范——Xconsole，成为接下来重点要做的事情。

打造Xconsole的过程是一个为阿里云控制台寻找“灵魂”的过程，也是一个为用户创造“梦境”的过程，整个过程充满了挑战，为此我曾专门写过一篇文章，也在2020年的UCAN大会上做过相关的分享。

Xconsole诞生于阿里云的复杂环境和细碎流程里，他肩负的第一个使命是用系统性的思考来确定阿里云管控产品的最终形态，满足当下和未来若干年内阿里云的产品增长并合理的管控复杂。Xconsole的诞生让我们相信复杂系统的体验治理是一条可行的路，也是一条极具价值的路。不过，Xconsole只是引我们到了这条路的起点，接下来怎么走，怎么让规范落地到实际的业务里，让那些混乱不堪的产品能够开始发生变化，而且是向好的变化，需要的是治理的第三个要素一套评价和执行机制。

斯坦福大学行为科学家BJ Fogg教授总结了一个经典的用户行为模型(Fogg Behavior Model)，他认为一个行为的发生有三要素，动机、能力和触发器。按照这个理论，如果我们希望Xconsole能够成功落地到各个产品中，我们需要的是提高业务线做出改变的动机并让他们拥有做出改变能力，最后给出临门一脚，促成改变发生。关于动机和触发器的产生，我觉得和运气以及阿里云发展的时机相关（阿里云整体开始重视用户体验并收到了用户对于不一致体验的大量吐槽）。在我看来，对业务伙伴的赋能会更有启发性，也是我们投入精力最多的部分。这个赋能包括两个方面，“更容易的发现问题”和“更容易的纠正问题”。一致性的自动化检测能力，通过算法来对每一次产品迭代做一致性的护航，让每一个一致性问题都能第一时间暴露出来。Xbuild，孵化于Xconsole最佳实践上的可视化搭建工具，能够完成从设计到代码的一站式发布，“没有中间商赚差价”，减少了因为不同团队、不同框架带来了还原误差。

当然，一致性评估以及Xbuild工具只是落地体验治理评价和执行机制的一部分，整个复杂系统的体验治理需要更高层面、更大范围的共识和认可，包括公司战略层面的重视、战役执行层面的强力支持以及产品发布和功能迭代流程数字化管理能力的建设等等。

体验治理（Experience governance），目前业界谈论的还不多，但随着产业互联网的深入发展，我相信会越发的走向前台。一点浅见，多多指教。