5.2 UI 设计与设计系统

Overview and motivation

用户界面(UI)设计是塑造人们所看到、所触碰之物的技艺:布局、排版、色彩、间距、控件和状态。设计系统把这门技艺转化为一份共享的、可复用的、受治理的资产:一套有文档记录的原则、组件、模式和设计令牌(token),供每个团队取用,使整个产品在外观和行为上表现得像同一个整体。UI 设计决定的是一个屏幕应该长什么样。设计系统决定的是众多团队所维护的上万个屏幕,如何保持彼此一致。

对大型组织而言,设计系统是在 UI 质量和交付速度上杠杆效应最高的单项投资。如果没有它,每个团队都会重新发明按钮、表单、模态框和错误处理逻辑,每一份都略有不同,每一份都各自维护,每一份也各自出问题。用户为此付出的代价是困惑和不信任;企业则为此付出重复劳动和参差不齐的质量代价。设计系统把一次性的设计决策转化为可复用的资本:在一个组件中一次性解决无障碍性、响应式设计和品牌形象问题,每个团队都能继承这个成果。

企业和政府场景还带来两个特有的压力。第一是规模:数以百计的应用程序,许多是由供应商构建或通过并购获得的,却都需要给人一种”同一个组织”的感觉。第二是长期性和变化:品牌会被更新换代,机构会被重组,同一个平台可能需要从一份代码库出发,同时服务多个品牌或多个下属机构。一个架构良好的设计系统,配合恰当的主题化和令牌化,能让这些大范围的变更变得可控,而不是灾难性的。

Key principles

一致性能降低认知负荷;一个按钮无论出现在哪里,外观和行为都应该一样。
设计决策是资产:把它们作为可复用的组件和设计令牌一次性捕获下来。
设计令牌是视觉决策的唯一真相来源;组件只消费设计令牌,绝不使用硬编码值。
无障碍性和响应式设计应内置于组件之中,而不是在每个屏幕上事后补加。
设计系统是一个拥有用户(开发者和设计师)的产品,而不是一份一次性的交付物。
视觉层级引导注意力:字体、色彩和空间应让重要性一目了然。
治理让系统保持连贯一致;贡献机制让系统保持活力。

Recommendations

Structure the system in layers: tokens, components, patterns

设计令牌是为颜色、间距、排版、圆角、层级和动效等命名的、与平台无关的值:是最原子级别的决策。把它们分层构建:原始调色板(原始数值)、承载含义的语义化令牌(color-action-primary、space-inset-md),以及在确有需要时才使用的组件级令牌。组件消费的是语义化令牌,因此一次改动就能传播到所有地方。在组件之上是模式:经过验证的组合方式,比如一个数据表格、一个多步表单,或一个空状态展示。把这三层全部记录在同一处,附带实时示例和使用指导。

Get the visual fundamentals right

建立一套具有清晰层级、行距充裕以保证可读性的排版比例尺度,并把字号和字重限制在有限的集合内。把色彩定义为一套体系,具备足够的对比度以满足无障碍性要求(参见无障碍章节),并赋予其语义化角色,而不是让原始色相散落在整个 UI 各处。使用一套间距比例尺度和一套布局网格,使对齐和节奏保持一致,而不必在每个屏幕上凭猜测拿捏。视觉层级应当让主要操作和最重要的信息一眼就能看清。

Design responsive and mobile-first

先为合理范围内最小的视口进行设计,再针对更大的屏幕进行增强。这会迫使你优先考虑最核心的内容和控件。使用流式布局和相对单位,使界面能够适配任何屏幕,而不是在几个固定断点之间生硬跳变。让触控目标足够大,并确保交互在触控、鼠标和键盘下都能正常工作。尤其在政府场景中,要假定有相当一部分用户使用的是小屏、老旧或低端设备。

Make design-to-dev handoff and parity a first-class concern

只有当交付的 UI 与预期设计相符、并持续保持相符时,设计系统才真正带来回报。要追求单一的真相来源:从设计工具导出的令牌直接输入代码,使设计师和工程师引用的是同一套数值。提供一个工程师真正会使用的、有代码实现的组件库,其命名和属性与设计组件保持一致。使用视觉回归测试(将渲染出的 UI 与已批准的基准图像进行自动化比对)和设计评审检查来捕获偏差。并把”设计，代码一致度”作为一项明确的健康指标来衡量:即由系统组件构建的 UI 占比,相对于一次性代码的占比。

Support theming and white-labelling at enterprise scale

只要存在任何需要多品牌的可能性,就从一开始就为多品牌进行架构设计。由于组件消费的是语义化令牌,一套主题不过是一组不同的令牌取值,因此品牌焕新或新增一个子品牌就变成了一次数据变更,而不是一次代码重写。通过同一套机制支持浅色和深色主题、高对比度模式,以及按租户区分的品牌样式。把品牌专属的逻辑排除在组件之外,转而推入令牌集合和配置之中。

Govern the system as a product

给设计系统配备一支专职团队、一份路线图、版本管理、一份变更日志和一个支持渠道。明确说明团队如何为新组件做出贡献,以及这些贡献如何被评审和晋升。在中央管控(以维护连贯性和无障碍性)与贡献机制(使系统能随真实需求演进,而不是沦为瓶颈)之间取得平衡。清晰地传达弃用和迁移信息,并给使用方团队留出足够的提前期。

Trade-offs: pros and cons

Decision	Pros	Cons
构建自有设计系统	一致性、速度、一次性解决无障碍性、更易于品牌重塑	前期和持续成本高,需要专职团队
采用现成的系统	起步快、模式经过验证	外观通用化,难以契合独特的品牌和需求
严格的中央治理	保证连贯性、质量和无障碍性	可能造成团队瓶颈,给人官僚的感觉
开放的贡献机制	随真实需求演进,责任共担	若无评审,存在偏差和不一致的风险
大量的令牌化和主题化	品牌重塑成本低,支持多品牌	抽象层级更多,学习曲线更陡

设计系统是以前期成本和治理成本,换取长期的一致性和速度。对于只有一个团队的小型产品而言,这份开销可能并不划算。而对于拥有众多团队、长期维护产品的大型组织而言,问题不在于要不要建立一套系统,而在于要投入多少、如何治理。最常见的悔恨,是在治理和一致性工具上投入不足:系统在纸面上存在,但各团队却在悄悄背离它。

Questions to discuss with your team

我们的令牌架构是如何分层的?组件是否被禁止使用硬编码值? 设计系统的全部回报(低成本的品牌重塑、多品牌主题化、一次性解决无障碍性)都依赖于组件消费像 color-action-primary 这样的语义化令牌,而不是散落在代码各处的原始色相和像素值。现在就决定好分层方式:一套原始调色板、承载含义的语义化令牌,以及仅在真正需要时才使用的组件级令牌。过度抽象是一个真实的风险,因此要就”多少层算太多”以及”开发者如何快速找到正确的令牌”达成一致。带上对你们代码库中硬编码颜色和间距的一次 grep 结果,作为偏差的证据。如果品牌逻辑被烘焙进了组件之中,一次品牌重塑就会变成一次代码重写,而不是一次配置变更,而这正是令牌化机制本应阻止的那种灾难。
我们如何衡量并维护设计，代码一致度?有哪些工具能自动捕获偏差? 一个只存在于设计文件中的设计系统,不过是一张贴纸表:工程师反正还是会重新构建一切,交付的 UI 也会逐渐偏离原本的设计意图。就一项明确的一致度指标(由系统组件构建的 UI 占比,相对于一次性代码的占比)达成一致,并把视觉回归测试接入 CI,使渲染出的屏幕能够与已批准的基准进行比对。这在企业和政府规模下尤为重要,因为数以百计的应用程序,许多是由供应商构建或通过并购继承而来,却都需要给人一种”同一个组织”的感觉。带上当前的一致度数值,以及各团队反复重新构建的那些定制组件清单。如果没有人负责这项指标或这套回归测试套件,偏差其实早已在悄悄取胜。
我们如何治理贡献、弃用和迁移,才能既不让系统成为团队的瓶颈,也不让系统四分五裂? 严格的中央管控能保证连贯性和无障碍性,但可能把设计系统团队变成一个团队们绕道而行的瓶颈;开放的贡献机制能让系统保持活力,但也有可能导致出现无人评审的分歧变体。决定好贡献路径:一个团队如何提议一个新组件、谁来评审它,以及它如何被晋升。同样,要就如何传达破坏性变更达成一致,因为没有迁移支持和提前期的弃用,会导致使用方团队陷入停滞或另起炉灶。带上团队在系统之外自行构建的组件案例,问一问他们为什么没有把这些贡献回系统。答案通常会揭示出,你们的治理究竟是一种服务,还是一种障碍。
我们如何保证无障碍性在组件内部被一次性解决?什么能阻止某个团队交付一个不具备无障碍性的一次性组件? 支持设计系统最有力的论据,是色彩对比度、焦点状态、键盘操作和屏幕阅读器语义能够被一次性解决,并被所有地方继承,但这个承诺一旦有团队手工打造自己的控件就会崩塌。对大型组织而言,这正是最大的法律和声誉风险所在,因为一个不具备无障碍性的支付表单或日期选择器,就可能阻挡真实用户,并在每一个复制它的产品中引发投诉。要权衡中央强制执行(可访问的组件,加上一道拒绝原始标记的代码检查工具或评审关卡)与团队自主权之间的取舍,并决定这条硬性界线划在哪里。带上一次无障碍性审计的结果、各组件及其合规状态的清单,以及团队在系统之外重新构建的定制控件数量。在企业和政府场景中,这不是一项锦上添花的事:像 WCAG、Section 508 和 EN 301 549 这样的义务,使合规成为采购和审计的硬性要求,因此一个有文档记录合规状态的组件库,本身就是一项合规资产。
这套系统必须服务多少个品牌、租户和主题?我们现在是否已经为此架构好了令牌层,而不是留到以后再回头改造? 如果你为主题化做过设计,它就会很廉价;如果没有,它就会很残酷,因为一个从未被预见到的品牌或租户,会把品牌逻辑重新逼回组件内部,从而破坏令牌化机制的整个意义。对大型团队而言,这个决策会影响未来数年的工作:一个必须服务多个品牌、一套浅色和深色主题、一种高对比度模式,以及按租户区分品牌样式的平台,需要一套足够干净的语义化令牌层,使一套主题不过是一组不同的取值。在这种灵活性与过度抽象之间取得平衡,因为一棵没有人能够导航的令牌树本身就是一种失败。带上你们能预见到的品牌和租户路线图、当前实际使用中的主题数量,以及任何已经把品牌专属逻辑泄漏进组件的案例。在企业和政府场景中,并购、收购和机构重组经常会带来你们原本没有计划到的新品牌,因此从一开始就为多品牌进行架构设计,是”一次数据变更”和”一次持续数年的重写”之间的区别。
我们要如何把遗留应用程序和供应商构建的应用程序迁移到这套系统上?设计系统团队的经费如何保证,使它能挺过下一个预算周期? 只有当真实的产品采用了设计系统,它才会带来回报,但最难转化的应用程序,恰恰是那些最需要它的老旧的、外包出去的应用程序,而维护这套系统的团队,往往是预算收紧时最先被砍掉的对象。对大型组织而言,你必须在大爆炸式迁移和增量式迁移之间做出选择,并想办法让供应商基于你们的组件来构建,而不是绕开它们构建。带上应用程序清单及其当前的一致度得分、每个应用程序的迁移工作量估算,以及你们对供应商所持有的合同约束手段。在企业和政府场景中,把设计系统的合规性写入采购条款,使新的供应商工作默认就落在这套系统之上,并把维护团队作为持久的共享基础设施来提供经费,因为一套在组织重组中失去了维护者的系统,会在一年之内重新滑回四分五裂的状态。

Sector lens

Startup. 只有两三名工程师、没有多余余力时,不要去构建一套受治理的系统。花上一两天时间,为颜色、间距和字体定义一小套语义化令牌,再加上十几个共享组件,全部放在整个团队都会引用的同一份文件中。在困难的部分依靠一个现成的原始组件库,并且不要留下任何硬编码,这样你们第一次真正的品牌重塑就会是一次令牌变更,而不是一次重写。

Small business. 没有专职设计师、预算紧张时,买而不是造:采用一个成熟的组件库或 UI 套件,再对其品牌做轻度的主题化调整。你的目标是在不组建设计系统团队的情况下获得一个一致、具备无障碍性的产品,因此要优先选择一个开箱即用就自带无障碍性和响应式设计的系统。要抵制住去分叉(fork)它的冲动,因为一份你维护不起的定制副本,一旦上游项目继续演进,就会立刻变成一项负债。

Enterprise. 这里的难题是在众多团队和长期维护的产品之间保持连贯一致,因此要把设计系统当作受治理的共享基础设施来对待,配备专职团队、版本管理和路线图。把设计，代码一致度作为一项真实指标来追踪,把视觉回归测试接入 CI,并从一开始就为多品牌和多主题架构好令牌层。为治理和迁移成本明确编列预算,并把采用情况作为一个组合来管理,而不是假设各团队会自行慢慢靠拢到这套系统上。

Government. 采购规则、透明度和公共问责制塑造着每一个决策。符合 WCAG、Section 508 和 EN 301 549 等标准的无障碍性合规,是一项法律要求,而不是一种偏好,因此一个有文档记录合规状态的组件库,本身就成为一项合规资产。优先采用或扩展一套共享的公共设计系统,使公民在各项服务之间遇到的是相同的模式,把设计系统的使用写入供应商合同,并公开发布你们的组件和指导文档,使各机构及其供应商能够采用它们,并被要求遵守它们。

Examples

Startup. 一家两人工程团队的初创公司,在每个新屏幕上都在以略微不同的方式反复重建按钮和表单字段,产品也开始显得像是七拼八凑起来的。他们没有构建一套重量级的系统,而是花了两天时间,为颜色、间距和字体定义了一小套语义化设计令牌,再加上大约十几个共享组件,全部放在整个团队都会引用的同一份文件中。由于没有任何硬编码,当他们第一位有设计头脑的新员工提出一套更清爽的调色方案时,这次焕新只是一次令牌变更,在一个下午内就传遍了整个应用,而不是一场逐屏推进的苦活。

Enterprise. 一家拥有数十个产品团队的全球软件公司,构建了一套令牌化的设计系统,配备一个共享的、有代码实现的组件库。语义化令牌让他们能在几周内为所有产品完成一次完整的品牌焕新,而不是一场持续数年、逐团队推进的苦活,因为这次变更只是一套新的令牌集合,而不是成千上万处硬编码颜色的修改。作为仪表盘指标被追踪的设计，代码一致度,随着各团队替换掉定制组件而不断上升,这也削减了重复的 UI 维护工作。

Government. 某国政府为公共服务创建了一套通用设计系统(共享组件、模式,并内置无障碍性),并在各机构间强制推行。一位在税务服务、医疗服务和许可服务之间切换的公民,遇到的是相同的页眉、表单控件和错误提示模式,这建立了信任,也缩短了学习曲线。各机构及其供应商能够交付得更快、也更具无障碍性,因为这些困难的问题已经在中央层面被解决,政府也能够一次性更新指导文档或无障碍性修复,并让它们传播到所有地方。

Business case: motivations, ROI, and TCO

设计系统的投资回报,来自消除重复工作和加快交付速度。团队不再各自设计和构建相同的组件,而是从一个共享库中进行组合,这能显著加快交付速度,并把设计师和工程师解放出来,投入到产品特有的工作之中。在组件中一次性解决的无障碍性和响应式设计问题,为你省下了按项目逐一整改的成本。曾经要花上数年才能完成的品牌重塑和主题化工作,如今只需数周。

在总拥有成本方面,采用这套系统的成本在于一支专职团队、相关工具,以及让现有产品迁移到这套系统上所需的工作量。不采用它的成本则是持续在支付的:各团队之间重复的构建和维护工作、不一致且不具备无障碍性的 UI 所带来的支持成本和法律风险,以及缓慢而昂贵的品牌重塑。由于这种重复分散在众多团队各自的预算之中,很容易被忽视:设计系统能把这种隐藏的成本变得可见,并把它集中在一处呈现出来。

要向管理层论证这一点,可以量化各团队之间重复的组件工作、通过组合复用带来的上市时间收益,以及你们上一次品牌重塑的成本和耗时,相对于一套令牌化系统本可实现的成本和耗时。把这套系统定位为共享基础设施,并配上一项可衡量的采用指标(一致度百分比),这样它的价值就能随时间被追踪,而不只是被口头宣称。

Anti-patterns and pitfalls

把设计系统当成贴纸表:一份静态的设计文件,没有任何代码实现的组件,导致工程师反正还是要重新构建一切。
到处都是硬编码值:颜色和间距散落在代码各处,使主题化和品牌重塑变得不可能。
没有治理:随着各团队添加各自分歧的变体,系统逐渐四分五裂;一致性不断侵蚀。
有治理却没有贡献机制:中央团队变成瓶颈,各团队绕道而行。
忽视一致度:有代码实现的 UI 逐渐偏离设计意图,却没有人衡量这个差距。
过度抽象:令牌和层级太多,没有人能找到或用对正确的那一个。
品牌逻辑被烘焙进组件:使多品牌和主题化变成一次代码重写,而不是一次配置变更。
没有迁移支持的破坏性变更:使用方团队陷入停滞,或干脆分叉出自己的系统。

Maturity model

Level 1: Initiate. 每个团队都各自随意地、被动地构建自己的 UI。没有共享组件,外观和行为不一致,颜色和间距在每个屏幕上都是硬编码的。每一次品牌重塑都是一场手工的、逐屏推进的苦活。

Level 2: Develop. 存在一份共享的样式指南或组件库,但它是不完整的、可选的,并且经常在设计和代码之间不同步。一些团队在使用它,另一些则没有,基本实践在各团队之间差异很大。

Level 3: Standardize. 一套令牌化的设计系统,配有持续维护的代码实现库、文档和治理机制,在整个组织范围内形成文档并被强制执行。组件消费语义化令牌,主题化得到支持,无障碍性和响应式设计被内置其中,而不是在每个屏幕上事后补加。

Level 4: Manage. 系统被用数据对照基线来度量和管控。设计，代码一致度作为一项明确的指标被追踪,并为每个产品设定目标,视觉回归测试在 CI 中运行以捕获偏差,无障碍性合规是被实际测量的,而不是被想当然地假设。采用情况仪表盘按团队展示组件覆盖率,品牌重塑的成本和耗时被记录下来,使改进情况能够随时间被看见。

Level 5: Orchestrate. 设计系统是一个持续改进、在整个组织范围内整合、并能随变化而调整的产品。它具备版本管理、路线图和一套运作良好的贡献机制,因此能随真实需求演进。品牌重塑和新主题成为例行的令牌变更,多品牌和多租户主题化成为常态,团队依据使用数据的证据来淘汰、重新界定范围,并晋升各种模式,让设计工具和交付流水线都从同一个真相来源中获取数据。

Ideas for discussion

你如何在中央治理和团队自主权之间取得平衡,既不四分五裂,也不造成瓶颈?
“设计，代码一致度”的正确衡量指标是什么?你如何保持它的真实可信?
一个团队在什么情况下应该被允许构建一个一次性组件,而不是使用系统本身?
你如何为设计系统提供经费和人力,使它能挺过预算周期和组织重组?
多少主题化灵活性,才值得付出额外的抽象成本?
你如何把遗留应用程序和供应商构建的应用程序迁移到一套共享系统上?

Key takeaways

设计系统把一次性的设计决策转化为可复用的、受治理的资本。
把它分层构建(设计令牌、组件、模式),让组件消费语义化令牌。
把无障碍性和响应式设计内置到组件之中,使每个团队都能继承它们。
把设计，代码一致度当作一项可衡量的健康指标来对待,而不是一种假设。
令牌化使品牌重塑和多品牌主题化变成一次数据变更,而不是一次重写。
把这套系统当作一个产品来治理,配备路线图、版本管理和贡献机制。
在企业和政府规模下,一套共享系统是可获得的、杠杆效应最高的 UI 投资。

References and further reading

Brad Frost, Atomic Design
Alla Kholmatova, Design Systems: A Practical Guide to Creating Design Languages
Josef Müller-Brockmann, Grid Systems in Graphic Design
Robert Bringhurst, The Elements of Typographic Style
Ellen Lupton, Thinking with Type
Luke Wroblewski, Mobile First
Ethan Marcotte, Responsive Web Design
Nathan Curtis, writings on design tokens and design system governance
W3C Design Tokens Community Group, format specification
Government design systems (e.g., UK Government Design System, U.S. Web Design System) as reference implementations