image.png

2014年,Brad Frost提出了原子设计这一概念,提出“原子设计是一种基于网络设计系统思维方式的规范性原则”的概念。它可以帮助网络设计者建立用户与产品元素互动的关系,以及如何将它们整合到一个整体的系统中。

2017年集团中诞生了 Fusion,它解的是在集团在各个业务线下重复建设设计系统的问题。设计系统的核心就是组件,每一个设计系统中至少30+的基础组件完全是重复的,拿一个「Input 输入框」来说,无非是你做的大一点,我做的长一点,用色颜色不同,图标不同。于是Fusion把所有底层组件一锅端了,别再重复磨样式了,你来我的站点,把你业务要的样式配到我给你准备好的基础组件骨架上,这样就在线生成一套独立样式的组件库了,点击发布前端就可以直接拿去做开发了。这是“原子设计”在集团内产品化落地的一个很好的案例。

2019年Fusion成为集团设计系统的底层标准,所有分业务线的设计系统没有意外都基于这个底层构建自己的物料体系。此时我在企业智能负责 DEEP Design系统,一夜之间,80%以上的现存组件库面临重新构建,我和Fusion的故事从此刻开始…

共生 👬

Fusion 的站点上共有46个提供UI配置的基础组件,它提供了一个很好的学习样板来帮我更深度地梳理基础组件中的原子引用关系。拿最常见的「Form 表单」来说,「Seclect 选择器」是表单域最常见的一种操作,它的下拉菜单引用的是「Menu 菜单」,「Menu 菜单」中的选择操作引用的是「Checkbox 复选」「Radio 单选」(下图)。而一个「Radio 单选」就是由一个图标和文字组合而成,这里的文字来源于全局样式中文字的某个序列的值。在对这行文字样式的设计时已经间接辐射到了一系列组件的联动变化。

image.png

这是集团内任何设计系统接入Fusion的第一步,也是影响一个设计系统生产的应用观感最基础的因素,该阶段的核心即是在基于原子引用关系去赋予视觉样式。这个阶段亦是一把双刃剑,设计系统从视觉观感上的差异即是样式差异,但在现有的Fusion配置平台中的变量极其有限,它的底层还没有足够地抽象到可以演化出多套差异化的设计语言。相对而言的益处是,Fusion现有的默认物料已经完成了基础物料工程化,它本质上通过Design-Token的方式定义设计系统中的设计原子,如颜色、投影、字体、字号等的寓意,使其与具体的样式值解耦。譬如DEEP Design品牌色为#FF6F00,对应的 Token 为 Brand1-6,所有组件中关联这个值的部分都会同步被着色,当设计语言迭代时只需要修改一次 Brand1-6的对应变量色值即可实现整套产品的UI迭代,同样的原理还会用于“文字”“间距”“线条”“阴影”等。对 Design-Token 定义的好处是可以让属性参数更容易理解,也更便于对产品风格的控制,保证实际设计中的视觉一致性和扩展性。通过抽取出来的Design-Token可以让设计者更快速地通过样式覆盖并应用一套物料库。

基于这个工程化的手段,DEEP Design 还是在看似严丝合缝的 Fusion 找到了形成自身差异化的一线生机。设计系统的差异化本质是品牌的辨识度,让用户形成视觉认知。要产生这种视觉认知,就得在用户界面中反复出现,Fusion 仅有的46个基础组件中就藏匿着这些带有图形元素的组件。在为“企业智能事业部”应用打造的物料中,我门抽取了LOGO中中“箭头”“弧度”“三角”的形状。配置在「菜单」「按钮」「加载」「气泡」「选择器」等底层组件中,通过组件的引用的网状关系间接覆盖到了41%的基础组件样式,DEEP 图形辨识度初步成形。

image.png

解决了部分视觉问题,回到更重要的组件能力本身。业务跑的往往比中台更快,随之而来的深度定制需求经过标准化过滤后最终还是依赖于 Fusion侧基础组件拓展性,比如组件的自定义区域,阶梯性的变量以及变种方案。于是DEEP Design 和 Fusion 合作了2年多的跨BU虚拟小组,以企业智能复杂的企业级办公场景实践去反哺Fusion基础能力的提升,输送了20+基础组件的优化方案,包含单一组件扩展性,样式层的多元性,原子关系的升级…但以上所述的这些都是基于“基础组件”的维度(Fusion 所解决问题的范畴),越过这个边界后还是得回到业务场景本身,DEEP Design 需要在此之上继续“进化”。

进化 🧬

2019年末,我在工位坐,KPI天上来,“提升 DEEP Design 的品质”体验部老大这一句话成了我的年度绩效目标。这话要是放在几年前可能是一个不用说设计都知道做的事儿,设计语言+品牌升级线上操作一把梭,然后再挑几个业务落地场景,完事儿P几张效果图群发一下邮件,阿里的套路莫过于此。但这根本解不了本质问题,DEEP Design 的用户已经不限于体验团队抑或这个BU了,跑在可视化搭建(宜搭)上的应用已经脱离设计的控制。且应用数字正在阶梯式的增长至7000+,物料体系的金子塔中“粒度”和“自由度”成反比,模版往往中看不中用,市面上大多数的搭建器为了保障产出能力依然处于消费最小粒度的“组件”阶段。要解DEEP Design 的品质问题,解的是应用最终呈现的品质,解的是没有设计介入的应用品质,解的是使用者的搭建行为符合设计预期的问题。

image.png

这7000+应用长啥样,设计的直觉告诉我,重点的项目一定会有设计资源,非重点的项目一定具备可被复制的规律。在走查300+页面后得到的答案亦是如此,大多数产出的页面逃不过以下这个框架(下图)

image.png

用颜色对这几种区块类型进行了一个分类:
红色:最常见的全局导航
蓝色:二级侧导航或者是当前页面的菜单
黄色:当前页面内容的页头
绿色:页面内容的分组区块
紫色:承载页面全局操作的工具栏
橙色:常驻于页面的悬浮操作

时代汹涌的进步时,有些习惯一但被沉淀便成了认知,你会发现在20年前都能找到这个框架它熟悉的模样(下图)

image.png

回到这300+页面中,可以拓展出4个最常见的页面布局(下图),基本涵盖了“首页”“工作台”“列表页”“数据看板”“详情页”“表格页”…但我接下来讲的不是模版,在这4张图中可以发现可控的区块是“红”“黄”“蓝”“紫”“橙”,它们都是可以叫的上名字的标准组件,比重最大的是“绿”,也是在页面中最不确定性的内容形式。让“绿”可控基本就掌控了页面“猛地一眼”看上去的标准化。

image.png

于是DEEP Design 在物料层全新定了一个容器组件「页面区块 PageSection」。首先,它的目的是标准化承载不可预期的业务场景形态,其次,它预设了高频出现的内容元素。比如“标题栏”,当需要它时可以直接被开启,且“标题”已经被预设好在页面中合适的层级样式,用户仅需更改文字。当你不需要标题时可以直接关闭“标题栏”,直接自定义区块中的内容,且在内容被填入时也不需要关注边距,因为这也是这个「页面区块」自带的能力。可以通过(下图)更结构化地去了解它的能力。

image.png

这样的一个区块即是一个页面顶层的超级容器,它可以包容内容的多样样化,同时具备页面全局的标准化排版能力。当视窗的终端发生变化时,「页面区块」内部的内间距自动发生变化,譬如从 PC 到 Mobile 后内间距会自动变的更小以符合移动化展示;「页面区块」外部的分栏布局亦会根据视窗发生变化,譬如 PC 的双栏布局到 Mobile 后会自动转换为单栏布局,内容展示顺序由至左向右变为至上而下。让用户只要关注区块中的内容设计,其他交给DEEP Design,页面默认多端,展示默认美好 (下图)。

image.png
image.png

同时,在这个阶段中我们也延续了 Fusion 原子体系的经验,把组件的工程化思维带入更大颗粒度的“区块”中,在这个「PageSection 页面区块」中引用到了「SectionHeader 区块头部」组件,它所具备的功能性亦可通用于「Dialog 对话框」和「Drawer 抽屉」。

image.png

而「SectionHeader 区块头部」继续向下拆分可分离出“标题”,你会发现“标题”这个东西非常高频,从常规认知上它无非是不同大小的文字,而“标题”必然会伴随“图标”和“释义”出现,那它为什么不能被标准化能?于是我们升级了「Title 标题」组件(Fusion 的标题组件仅有纯文字),将伴随标题出现的元素进行一体化封装,并在规范层赋予它在不同场景的使用建议,用户使用“标题”时仅需更改文字选择图标或配置释义,降低了设计投入的同时也满足了标准化产出。

image.png

以上的例子是 DEEP Design 在业务实践中其中一个具体方案,亦是在阐述我们基于 Fusion 基础物料之上对自有业务领域中通用框架进行收敛的方法,它们的相似之处是将UI的生产行为进行“标准化”和“定制化”的剥离。Fusion 在组件层定义了“标准化”边界,DEEP Design 在业务框架层定义了“标准化”的边界,为业务的“定制化”减负,更专注于内容本身的设计,也能在特定的场景完全释放设计行为,也让在设计不受控的大批量自交付场景中的标准化成为可能。如(下图)是DEEP Design 在早期完全通过内容配置生成缺省页的解决方案。

展示动画.gif
⬆️ 缺省页的0代码配置-2018 洪会

现在回想起来,这就是低代码编辑器(LowCode)的雏形,相对于缺省页更复杂的组件, 我们可能希望通过限制拖拽、属性设置之后联动修改其他属性等更友好的方式来保障组件能对接到低代码平台,那么这份「限制」、「联动」就必然需要有一份配置文件来承载。这份配置文件集团前端委员会中后台小组给起了一个名字叫「组件描述协议」。

在低代码平台设计器中,选中一个组件,在右侧看到的区域就是根据这份「组件描述协议」渲染的:

image.png
⬆️ 一个按钮的属性配置面板

生态 🌲

从上述内容中,可以了解到DEEP Design 在通用框架层面进行收敛的方式,接下来面对各种各样的业务定制化内容就是进入了深水区。 Lego 乐高有一款 Speed Champions 赛车系列非常强大(下图),玩家可以用相同砖块种类与数量搭出16种“车型”方案。
image.png
这和我们所面对的“中台标准化物料”和“业务定制化内容”其实是同一个问题,纵使业务设计使用的都是这一堆基础物料,依然无法把控用户去创造出千差万别的页面。所以这里就需要建立起物料的一个“生态”,这个生态主要包含3种供给关系:

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

中台将物料供给到业务

DEEP Design 每生产一个物料,包含了3种产出物“线上组件库”“本地Sketch组件包”“在线的设计指引及API文档”,来保障“输出“和“接收“之间的损耗尽可能降到最低。就像给玩家一堆积木的同时给他一张图纸,来保障基础能力的组合应用符合预期。如(下图)是一个「Tag 标签」的文档,我们在 Fusion 平台配置好一个标签基本的几种样式,然后结合DEEP Design 业务场景的实践对它的使用的上下文规则进行补充,并告知推荐的使用规则,以及当现有能力不满足时扩展它的方式。

image.png

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

在设计侧业务物料的呈现形式有3种“低代码物料”“业务组件”“业务模版”,这些名字听起来太过专业,我们还是可以拿“Lego 乐高”做一个比喻,(下图)左边的松树就是拿基础砖块拼成的,此时就是基础组件通过有序的组装形成了一个更具象表达,形成了一种特定的能力,这个其实就是低代码组件。而右侧的“树”它们是独立模具开模具生产出来的,它明显比左侧“组装树”更精致,它是特定场景的最佳方案,这其实就是自定义的业务组件。当然它也会使用基础砖块的底座,即插即用,来和大场景进行更标准化的衔接。

image.png

当业务组件的“树”被生产出来后,中台要做的就是做好这棵树的“底座”,在前文“进化🧬”这个章节中讲到的「页面区块 PageSection」这个东西其实就是一个“底座”的概念,它能去承载自由变化的业务“低代码物料”或“业务组件”并将其整合为颗粒度更大的“业务模版”的范畴,如(下图)

image.png

为了解决业务上生产的“业务组件”“区块模版”跨业务域使用的问题,前端团队开发了“物料研发平台”,让原有的“闭门造车”式开发转为线上标准化开发。这个开发模式可以简单理解为所有增量的新能力必须经由最基础的组件构建而成,所有的样式参数必须来源于唯一的Design-Token,不允许出现任何的常量。这样的优势是新增的业务物料都会是一个和底层建设打通的集成体,一但跨业务域后的Fusion主题包发生变化,依然可以从固定的Design-Token路径进行样式转换,避免了核心物料脚本的开发。如此一来,中台和业务不但做到了求同存异,并一起携手收敛了呈现的标准化与持续增量。

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

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

拿我们内部的“会议室预定”应用举一个例子,中台设计和业务设计配合将该应用特有的业务物料输送给“宜搭”,这样“宜搭”就具备了通用基础物料和业务物料的基础,中台前端和业务前端统一API、数据接口、沉淀业务模型。
当湖畔大学需要复刻一个独立的会议室预定系统时,他们的开发团队就可以通过模型或数据驱动一个应用的生成,再根据自己的业务差异对页面进行微调,开发少量的业务脚本即可完成交付。在内部完成业务的0-1沉淀,满足未来1-N的复用价值。
image.png
image.png

结语 🙏

最近,听闻钉钉已经在小范围的使用Figma进行日常的设计执行,在数据存储本地化配置后有推广到大钉钉之势,且厂外的字节跳动也早已在全公司范围使用Figma作为设计主要工具。自2018年以来,Sketch使用率从42%的受访者下降到31%,而Figma从12%增长到26%。而Sketch 5年前的逆袭仍历历在目,它在全球扁平化设计浪潮下取代了Adobe PS成为了UI Designer的主流的工具。但这一次Figma的后浪并不是因为它做了一款更好用的全平台(Sketch只能在Mac系统中使用)设计工具,它更像是一次跨维打击。在线可视化搭建应用,或者应该说应用的交付方式变革正在悄悄到来…下一次,我们谈谈如何面对“在线设计”的趋势进行针对性的物料升级。
image.png数据来源:https://uxtools.co/survey-2019