DEEP Design 的诞生

企业智能事业部的前身是信息平台事业部，在2012年10月份成立，将阿里巴巴集团的信息系统统一起来，逐步取代购买的外部 Oracle 管理系统，逐步开始去PS（PeopleSoft）。此前，我们的绩效、薪酬、假期等使用的都是PS，随着去PS开始，当时的信息平台基本上要把所有的系统都翻一遍，这件事情直到2017年1月份最后一个应用（iHome）上线后，去PS才画上了句号。这期间，我们自主研发超过10个HR系统，仅薪酬核算的后台系统，就有50几个页面，而当时支持所有去PS项目的设计师只有 2个交互、1个视觉，也是基于这个大背景，我们从14年开始就逐步建设面向中后台场景的设计规范。

继HR系统落地后，随着企业管理应用数量爆发式的增长，传统项目流程已经无法满足大量的开发需求，为应对这个问题，我们启用了“组件式开发”的解决思路，从而提高工作效率，并产生更加规范的应用。在这个土壤下为了让设计能够扩大规模，为了提供一种标准来供不同的设计者参考， DEEP Design 第一代设计资产开始成长。

5年的发展历程

2017-2018：完成基础设计资产建设

2016年的信息平台，支撑着“人财事物法”等集团内的办公应用，在这个阶段就是将产出实现复用的初期阶段。在达成了设计的一致化产出后，前端将物料代码化实现可被即时调用的「组件库」，设计一致化增值为开发效能的提升。该阶段是0-1的阶段，时间跨度是漫长的，但好在可以参考业界已有的经验沉淀。我们基于自身业务场景的共性定义了“文字”“颜色”“图形”“动效”，DEEP Design 在该阶段的主要产物就是“组件”（PC+Mobile）数量的积累。

2018-2019：完善设计系统，完成设计管理闭环

这一年，横向拓展出了业务研发流程的“自交付”体系，比如在表单场景的设计解决方案沉淀就造就宜搭1.0版本的诞生，0代码平台让技术小白可以在线搭建出一个可用的网页；物料库存的增长也直接夯实了低代码搭建平台“乐高”能力的覆盖面；同时“体验+”的衍生让开发链路形成体验质检的闭环，形成了更完整的DEEP体验管理体系。

2019-2020：为业务提供多端一体化的交付标准

我们设计了一套多端响应框架，通过容器层实现不同屏幕尺寸的响应布局及默认样式的自动化转换。然后在基础组件层面联手Fusion 对物料进行了多端样式转换的覆盖，接下来针对区块级的场景通过“适应式”方案生产业务组件补齐高频业务场景需求。实现了PC端为主业务场景下在“PC””Pad”“Mobile”3端的页面信息都可以得到体验更好的展示和操作

2020-2021：业务交付变革下的物料体系升级

通过“PC”“Mobile”“Charts”3类基础物料协助业务侧沉淀“组件”“区块”“页面”3类业务能力，所有设计输出在线 DEEP Design 主站点，实现多站合一，同时与技术打通，打造【一站式研发平台】对设计产出的物料进行统一“生产”“管理”“消费”。设计物料最终转化为低代码组件，最终向我们的低代码搭建平台及在线设计平台持续输出：

• BU内：服务企业智能在线设计及业务研发
• 集团内：打通 D-One 平台实现工具普惠
• 商业方向：服务“宜搭”外部业务场景

企业品牌下的视觉语言

以组织形象演化的视觉语言

颜色
品牌色彩是品牌识别系统中的重要组成部分。根据品牌的特点，品牌文化，指定某一特定的色彩系统，应用于所有的视觉传达设计当中，利用色彩所具有的视觉刺激及心理反应，体现品牌本质特点。
橙色是阿里巴巴的品牌色，是一种温暖、亲和的颜色。而企业智能是为阿里巴巴服务的，同时也依附于阿里巴巴，所以橙色代表了组织温度。阿里巴巴亦是一家科技公司，蓝色代表冷静、商务、未来、科技、安全，它是一种比较理智的颜色，这是工作需要的状态，所以蓝色代表了智慧办公。

品牌色是品牌识别元素重要的一部分，我们可以通过不同场景的设计输入强化品牌意识，在企业智能200+应用体量下，icon是一个强有力的抓手。将橙蓝两色融入到icon设计中，产出一套具有企业办公图标标准，让色彩语言游走与用户界面的字里行间。

图形

我们提取了品牌的视觉锤。企业智能品牌生于阿里巴巴组织&员工，DEEP Design 生于企业智能，通过“橙蓝箭头”这个视觉锤的运用，我们可以更好诠释品牌的内涵。

在为“企业智能事业部”应用打造的物料中，我门抽取了LOGO中中“箭头”“弧度”“三角”的形状。配置在「菜单」「按钮」「加载」「气泡」「选择器」等底层组件中，通过组件的引用的网状关系间接覆盖到了41%的基础组件样式，DEEP 图形辨识度初步成形，使设计语言从线下到线上一脉相承。

以员工形象演化的插图物料

企业级产品场景中任务流页面占了90%以上，老司机可以几分钟快速撸出一个表单流程，但剩下的10%辅助用户观感体验的视觉插图工作量却一笔一画用掉了50%的总工时。它的价值远远低于业务逻辑，属于事倍功半的产出物，食之无味，弃之却又不可。

在阿里集团正式员工中设计师占比为2%，比如我们企业智能有13+业务线，187+产品，但设计师仅38人，这38人里能画插图的视觉设计师不到1/5，平均每个人要支持27+产品的图。别说996了，007都是画不完的！而且在阿里人才能力模型中，不会让一个设计师天天在那生产插图。怎么办呢？同样的资源下，只有重要的项目会投入视觉设计，被迫弃掉一些“不重要”的产品，或者花钱由供应商来外包，每年集团在这块的开销也不是一个小数目。

再者，插图是一个非常具有主观意识的艺术形态，「造型方式」「用色习惯」「画风特征」是插图的3个主要表现力。但这3个好东西往往会在协同上出问题，人多了产出一致性反而变得不可控。而企业级产品的用户往往是同一类，品牌化的观感是不可或缺的。

让插图变成普惠的艺术

艺术是独特，商业设计是普惠，普惠的艺术具备相对的通用性，且能拉高基础品质的水位。在200+产品的历史沉淀中，我们发现企业级产品的插图具备较高的同质化内容，它不会像电商大促的品牌KV那样标新立异，也不会像漫画具备细腻的表现细节，更多地是将商业行为朴实地图像化来补充产品UI中对用户的情感化体验。而且我们的业务场景面对的都是阿里员工，插图恰巧描绘的就是员工的日常工作行为。有了这个确定性，我们将团队内的视觉设计师拉到了一个虚拟小组中，定义了一套阿里人形象。从职能的差异性上有“设计师”“程序员”“运营”“产品”…从人物关系的维度上有“员工”“管理者”“供应商”“客户”…

“人物”是绘图中最复杂的变量，但人体结构具备标准的定量，我们将动画中的骨骼运用到静态的2D插图中（选择2D平面的风格是因其生产成本低，且其视觉表现足够朴实，不至于成为UI中的焦点）。设计一个人设即可快速拓展到多种姿态，将骨骼坐标结合技术，还可以在特定骨骼姿态中一键切换人设。

画面有了主角，在配合一些场景物品，就可以快速通过组合素材的方式“拼”出一张插图。在标准化插图素材生产中，我们依然是以中台的方式去解决问题，一来解放业务整体的绘图投入成本，一来让各个视觉设计师统一维护一套标准化物料能让图形资产不断的积累，提升新需求的支持效率，最重要的是让所有阿里员工在使用我们的产品时感知到一个贯穿始终的品牌形象。视觉虚拟小组第一阶段中优先解决设计师层面的协同问题，形成一个企业插画物料的设计标准，并在真实的业务场景中进行落地，同时沉淀该场景特有的图形元素反哺物料库存，以及场景化的方案。

降低获取插图的成本，提升生产插图的效能

达到以上阶段，仅是完成了设计师群体的协同和标准化，同时也是建立了插图生产的SOP，此时我们就可以结合一些技术的产品化，让生产插图这件事突破职能的边界。正版Photoshop 6000一个，Sketch 99$一年，OS系统还要买苹果电脑，而线上一个站点免费帮你搞定插图设计。在2018年末，我们在阿里内部提出了这套全新的插图生产方式，随之百花齐放有蚂蚁设计的Hitu，Icon font的插画库，集团客服CCO的虚拟服务形象，Alibaba Design正在以更简单的方式赋能行业，让商业美而简单！

企业数智化转型下的数据可视化

DEEP Charts 是刚加入 DEEP Design 的新成员，补齐这几年图表规范的缺口。在数据产品范畴，应用场景的不同导致不同的看数需求，DEEP Charts 不是图表的基础规范，而是对基础图表库进行封装、专注在企业数智化管理场景的设计体系与解决方案，在服务管理者向下管理、员工自我管理、同事间横向协作时，提供良好看数体验的数据产品，支持他们进行复杂决策，进而提升整个企业的组织活力，并促进业务创新。

经过一年的业务实践，累计沉淀了17类组件、114个模板，覆盖了企业智能事业部20+业务产品。

在设计产出就绪后，我们将图表资产输送到我们的数据搭建平台（有数），进而对接低代码搭建平台（乐高）
从数据的生产到应用赋能业务看数体验的升级，全程把控了图表的标准化生产到高效率使用。例如基于全局框架的「PageSection 页面卡片」数据卡片对顶部扩展区域进行了定制化的衍生，使常规的页面内容随时可升级为数据卡片，且在整体框架的融合下，数据呈现也能实时响应多端的视觉展示。

专题传送门：《企业数智化转型下的数据可视化：DEEP Charts 1.0》

业务拓张下的物料体系升级

随着业务的拓张“数量”和“深度”都在阶梯式的增长，定制化内容是每个设计系统的深水区，纵使业务设计使用的都是这一堆基础物料，依然无法把控用户去创造出千差万别的页面。所以这里就需要建立起物料的一个“生态”，这个生态主要包含3种供给关系：

• 中台将物料供给到业务
• 业务基于中台供给建立自身领域的业务物料
• 中台将业务物料整合再次供给多个业务域，形成平台的服务化

中台将物料供给到业务

DEEP Design 的中台团队侧重于基础物料的维护，基础物料亦可被成为通用组件，它一定是有一个上限的。对其维护的重心在于拓展其能力以及将这个能力更好地传达给使用者。所以每一个基础物料都包含了3种产出物：“线上组件库”“本地Sketch组件包”“在线的设计指引及API文档”，来保障“输出“和“接收“之间的损耗尽可能降到最低。

业务基于中台供给建立自身领域的业务物料

在设计侧业务物料都是基于“基础物料”之上被生产出来的，从被集成的复杂程度上可分为“组件”“区块”“页面”3种颗粒度。前端团队通过“物料研发平台”，让原有的“闭门造车”式开发转为线上标准化开发。这个开发模式可以简单理解为所有增量的新能力必须经由最基础的组件构建而成，所有的样式参数必须来源于唯一的Design-Token，不允许出现任何的常量。这样的优势是新增的业务物料都会是一个和底层建设打通的集成体，避免了核心物料脚本的开发。如此一来，中台和业务不但做到了求同存异，并一起携手收敛了呈现的标准化与持续增量。

中台将业务物料整合再次供给多个业务域，形成平台的服务化

2020年初在我们的平台战略中提到了业务中台的概念，因为我们的业务能力逐渐要供给给企业智能之外的生态化场景，这对我们的考验是要以平台化输出我们的积淀。没人能把业务中台是什么说清楚，在物料层，我认为业务中台其中一条策略就是由业务本身对不同时期不同场景的收敛，找到共性，有所沉淀，有所割舍。使其可以在面对新需求时不必重复0-1的过程，可以从0.4或0.6起步。结合上一段“业务物料”的成果，DEEP Design 将整合后的物料输送至UIPaaS（UIPaaS是为低代码平台开发者提供可视化搭建解决方案的平台），并通过“宜搭”（低代码平台）去支持外部的生态化项目。

业务交付方式变革下的“在线设计”

伴随着物料体系的升级完善，我们也在思考如何在业务中更高效地消费。传统方式设计输出一套统一的DPL，然后再根据不同角色、不同平台输出三个版本组件：Axure组件库、Sketch组件库、前端代码组件库，前两者主要面向产品、设计师，后面一个则是最终将页面线上化的代码物料。

如果要做一个需求的交付，按照传统的方式，通常是PD通过Axure产出需求Demo，设计师基于PD的产出用Sketch产出设计稿，最后，前端基于设计师的产出，用编码的方式将页面线上化。按照时间投入折算，产品和设计各有约 1000 个 HC 忙于画 DEMO，前端中有大约 600 个 HC 在做 Layout 的事情，而这部分工作存在着大量的交集。

除了协同成本外，由于设计过程大多是离线，带来的管理成本：产品和设计的工作过程不在线，工作行为数据沉淀不足，无法给大脑输送足够数据，实现数据化管理（此前设计在线率仅为55%，是兵力在线率最低的一个岗位）。另外，在线下的共创会时，也发现产品/设计/前端存在基于DEMO的协同割裂感强，有比较大的优化空间。

因此，我们希望基于企业智能已有的低代码技术储备，打造一个多角色协同的在线设计工具。

经过过去一年的努力，我们也在D-One上跨出了「在线设计」这一步，同学们可以点击这里体验：

• D-One产品链路：让D-One 从纯离线设计到离线+在线设计；在线设计输出物能够向低代码研发平台交付、多角色基于设计稿的评论（圈评）。
• 物料：支持VC物料体系（90+）、Fusion低代码物料体系（16+）、自然布局体系、100+模版/区块模版即将上线。
• 引擎：接入UIPaaS，同时基于设计场景，提供页面管理、研发模式&设计模式切换、逻辑编排、多端切换等能力。

通过「在线设计」这个工具，我们初步实现基于同一个平台、同一物料，产出统一的交付物，最终实现基于同一产出物的多角色在线协同。在过去的一年中，我们落地了54个有效项目，创建737个页面、发布 354 个页面（仅统计企业智能中的PD、设计师产出的有效项目）。

专题传送门：《「在线设计」研发全链路交付模式的变革探索》

常见的一些 FAQ

在我们参与的业务合作项目中，大部分时间是在和不同职能的协作者描述 DEEP Design 的能力以及合理的使用方式，为了最大化地完善和业务研发方式的耦合度。其中，最大的感受便是，设计系统最具挑战的不是物料的制作过程，而是得到项目团队即组织的支持，以下3点是比较常见的对“设计系统”的误读：

设计系统限制了业务设计的创新？
这是大部分设计师对“设计系统”的看法。他们觉得作为设计规范会限制他们的发挥，以致于他们不能去实现一些新的样式和交互方式。我个人觉得作为设计师我们不能仅仅为了有创意而去引入新的样式或交互方式。我们的设计都应该解决业务域特点或用户习惯的问题。对于那些以完成任务为导向的系统应用，在组件样式能带来的收益微乎其微，甚至全新的交互可能会打破既有的认知习惯。“设计系统”的存在可以减少很多基础的工作，比如布局、常规交互、调整间距等等，业务设计师有更多的时间来关注全局体验链路和业务流程上的机会点。

只关乎设计，可由设计师独立完成？
对“设计系统”的另一个误读便是以为它仅仅是一些在设计软件中的可重复使用的“基础物料”，仅在设计阶段能发挥价值。其实物料的生产更多依赖于技术栈的架构以及更上层的中台管控，比如基于 React的JavaScript是我们最底层的前端语言，和集团设计的Fusion平台对阿里全量设计系统的统一标准。每一个物料都需要横向和这些“约束”建立有机的联系，这需要中台团队的成员建立更紧密的信息和技术沟通，才能为“设计系统”建立起一条通畅的坦途。

基础物料做完就是大功告成？**
既然基础物料是有上限的，那么是否只要做完就大功告成了？其实基础组件的维护只是无限让它趋近于一个更全面的能力，但来自于不同业务的诉求本身就会发生矛盾，想要“设计系统”获得认可，就需要像对待一个产品一样对待它。业务的发展在变化，侧重点也在变化，如从“研发效能”到“体验极致”的鸿沟，设计系统的项目团队应该定期收集项目组及用户的反馈，帮助用户形成最佳实践或直接引导业务建立自身的业务物料增量。

作者：多月、正颜、龟苓、洪会