“专有云”是云的一种部署形态。得益于传统行业客户上云步伐不断加快，其对信息安全可控和企业业务稳定的要求不断催生对于专有云服务的需求。我国专有云市场于2019年接近100亿元规模，并以接近60%的年复合增长率持续扩张。2020年6月9日，阿里云“专有云”全面升级为“混合云”，以业务应用为中心，帮助企业客户构建开发平台和云基础设施，助力客户建好云、管好云、用好云，形成完整的数字化转型支撑。混合云售卖给客户的不仅仅是一个或多个控制台，而是“建+管+用”的产品服务矩阵。
公共云上人人都是devops，是服务的开发者，是原厂工程师，只需要运维自己团队的服务。公共云用户在一个控制台里就能使用到最新产品服务，不用担心运维和数据安全。混合云面向的多数是大型或超大型政企客户，相比公共云几千万的线上用户数，混合云用户数可谓寥寥无几，但多角色、多场景、一人千面却是混合云用户的显著特点。混合云产品是多版本发布的，用户需要升级版本才能获得产品最新能力。不同角色使用者会在多个控制台间切换使用，以获得相对独立而关联的管控能力。比如决策者最希望在同一个地方看到云的所有资源分布和使用率；运营管理人员要为企业中每个部门的权限控制、成本分摊负责，需要一整套分权分账的企业IT治理体系。企业硬件利旧，各省市分级管理等等，都是混合云客户IT治理的个性化需求。
二.解题：系统手段解决系统问题
**
当业务演进到平台化、规模化、采购市场阶段时，体验设计也会面对更多挑战：
面对这些问题，混合云的体验工程建设已经远远不止于用一套设计规范或一套组件库来满足了：
- 业务规模化发展，要求产研团队必须以“高通量”的生产效率来应对。
- 业务个性化服务化，要求产研团队要有足够“智慧”的生产工具来支持。
我们意识到混合云产品体验是一个”系统问题”，而解决系统问题只能靠“系统手段”。
**
我们开始并没有直接切入设计，而是反思：
- 过往的设计系统有什么问题？
- 混合云业务特性需要什么样的系统支撑？
- 我们的设计系统和其他团队的设计系统有什么共性和差异？
- 我们的设计系统如何与上下游系统衔接？
**
面向多业务、多客户、多场景，建立业务适应性的设计系统
从云下到云上，从具象到抽象，从内部到外部，从企业到个体，从一端到多端，设计师应该秉承开放和包容的心态，将设计系统不断「进化」以适应各混合云业务的多样性变化。重新审视设计系统的角色，连接业务和工程。
好的设计系统应该是双向促进和共同进步，而不是阻止约束或强制执行。设计师所讨论的画布元素，最终会在开发环境中转化为代码编写的产物。如何让设计从业务源头就产生价值，并让设计规范有效落地，需要和研发工具紧密相连。
混合云设计师和工程师共同打造了一套服务于混合云全域云服务的设计系统Pixel Design System。设计系统不再是孤立的面向设计师群体，而是诞生于真实业务，服务于业务应用，真正落地在研发生产的设计系统解决方案。
**
三.选择：更好的协同和管理
设计系统协作模型
Nathan Curtis提出三类设计系统的团队协作模型：Solitary（独立式）Centralized（集中式）Federated（联合式）。混合云设计系统要服务的产品大多数是跨团队、跨部门、甚至跨组织的，有时直接面向外部客户交付及赋能ISV生态。所以需要一种更持续、更开放的协作方式，最终我们选择了联合式模型。我们邀请了不同业务线的设计师共同参与规范制定，也包括跨团队与公共云设计师进行共建。
管理过程和结果
确定协作方式后，另一个关键问题接踵而至：如何保障设计生产大规模交付？
造一台车不难，造一台酷炫的车也不难，难在造很多酷炫的车。我们从汽车制造业中获得启发：一台车上万个零件，没有哪个整车厂会自己全部生产，大部分零件都是外包出去，而且都是层层外包。其中任何一个环节的问题都可能导致整车厂无法量产。但汽车制造业在供应链、组装生产、测试验收等环节，通过制定严格的标准来控制质量，将潜在风险降到最低。
设计规范制定者往往也是维护者，他们把方法传播到各业务线，让业务设计师流水线自行组装，所有输出物通过标准把关，判断是否能成为有效资产。当标准和方法在一个业务中被验证可行后，就可以复制到其他业务，不同业务就可以“自运行”生产出符合自己业务特色的模式库。
最终，我们的设计模式库包含「设计物料」和「设计规范」两部分：
- 「设计物料」是在设计规范约束下生产出来的设计资产，是设计规范传播的载体，可以被其他平台消费。比如，物料Symbol化配合插件可拖拽用于设计输出，物料经过代码化开发形成Lowcode/Procode物料用于搭建或生产。
- 「设计规范」是控制从“元件”到“场景”所遵循的组装逻辑，是设计师对业务理解后的规则抽象，需要被在线化有效管理。
四.实践：设计模式库构建的4个方法和1个标准
方法一：固定常量+控制变量
通过抽象样式常量，并赋予变量值，可以快速生成满足不同业务品牌风格化的主题包，非常适用于基础组件和图表的风格化扩展。需要将样式属性与UI组件解耦，并支持配置化，才能支持主题自定义。
方法二：物料分层+模块拆分+元素穷举
不管是原子理论还是粒子理论，核心思想都是用“小粒度物料”组装成“大粒度物料”。我们从物料使用和粒子大小两个维度，将物料分层为：元件→容器→模块→页面→场景。
「元件」包含组件库、图标库、图表库、插画库，无法单独形成页面。「容器」面向搭建使用，是针对页面划分和内容组织的一种有效区域。「模块」是介于「组件」和「页面」之间的一种合适粒度，如果将模块拆分为更小粒度的子模块，在子模块里穷举元件，就能裂变产生更多模块。「场景」是在业务模型和数据驱动下，以「页面」为单位的串联骨架。
方法三：建立交互模式库并可视化索引
交互流程由于不容易被直观感受，所以很难被固化下来。即便处理相似的交互逻辑，设计师也会因个体偏好和经验不同，输出差异化的设计方案。我们发现不同业务线的监控运维平台中，用户“监”“管”“控”的行为模式存在高度相似性，但由于不同业务设计师各自为政，内部缺少横向对标统一，就导致了多个平台间很难做到体验的深度统一。
我们从多个相似业务平台中抽离相似的用户行为，收敛交互模式，建立一个共识性的交互模式库，把不可见的交互流程可视化，让大家直观看到哪些交互是已经被固化下来的，使用于哪些场景，交互细节是如何定义的。无论是设计师、产品经理还是开发人员都无需进行重复脑力和体力劳动，遇到类似问题时可以快速索引，获得启发。
方法四：场景物料-从1到N快速组装产品界面
以往设计物料常常止步于典型「页面」输出即可。尽管设计师会写清楚使用场景和注意事项，但在实际开发中往往出现使用不受控，样式满天飞的现象。
复杂平台一般由若干大功能模块组成，大功能模块又可分为更小的功能模块。工程师会从技术架构角度，根据不同功能模块来建立不同工程分支，独立管理开发部署；业务方也会基于某个功能模块，迭代性提出产品需求。我们发现“页面”和“页面”的串联关系和这些“功能”是紧密相关的，所以我们提出“场景”的粒度概念：
“场景”是满足某种功能的最小关联页面集合。
**
多个“场景”构成“站点”，多个“站点”构成“平台”。比如，我们将ECS控制台视作一个站点，它由“资源管理”、“资源监控”、“资源创建”三个场景组成；ECS控制台和RDS控制台是不同的两个站点，多个云产品控制台站点整合一起，就可以形成一个功能强大的云管平台。场景化组装，也为搭建平台提供了一种搭建思路。
管控场景的典型页面模板大部分以列表、详情、表单为主体，框架及布局都及其相似，但数据内容可能不同，业务模型是导致内容差异的变量因子。
我们对混合云产品体系进行了场景梳理和归纳，形成一套可复用、可组装的场景解决方案：
每个场景都有对应的业务模型和一套页面关系。搭建者可以根据业务模型选择合适的场景模板，只需替换数据就批量化完成原型搭建；开发者可以通过复用页面结构信息，快速组装站点界面；设计师可以通过参考不同业务模型，复用或抽取设计样式去解决相似业务需求。同时我们也在探索通过数据特征和用户行为，建立业务模型与页面的映射关系，解决简单而重复的设计场景。
一个标准：「物」尽其用
行业普遍认知是，复用率越高的物料越应该被抽象沉淀并应用于通用场景。但我们在实际应用中发现，“越通用”往往“越难用”。因为混合云业务庞大而复杂，一旦功能无法满足，大部分通用物料都需要经过深度二次开发才能得以应用，开发成本并未显著降低。所以我们认为：面向物料的不同应用渠道，分别沉淀不同类型和不同价值的物料。
面向开发和搭建两个渠道，Pixel沉淀这几类物料：
- 原子组件和高级组件：复用率高，可交付性高。对table、form、tree这类后台高频使用的基础组件做能力扩展，通过源码二次封装为高级组件或高级模块。
- 业务物料：业务特性高，可交付性高。业务自行沉淀，在平台内部完成使用闭环即可，存在即合理。同时建议面向搭建平台做改造，以扩宽物料的应用渠道。
- 可搭建物料：复用率高，可搭建性高。一般由设计师使用元件或模块在搭建平台里自定义组装而成，并在搭建平台中可反复调用，并非需要代码化开发。
目前，这三类物料已经在搭建平台和业务开发中得到充分运用。Pixel 设计系统也正朝着深水区迈进：
若有收获，就点个赞吧
0 人点赞
