这篇文章的内容来自 UXPin 组织的 Design Systems Virtual Summit 系列视频分享。本文并非对视频内容的详细字幕记录，而是对主讲人的口语化表达和偏个人化内容做出主观编辑、梳理重点内容之后汇总而成。有机会的同学前往 YouTube 观看原视频能够获得更丰富的体验～
视频地址：Consistency vs. Flexibility in Design Systems by Ken Skistimas
你将会了解
怎样定义设计系统中的「一致性」与「灵活性」
企业产品中不同的业务场景会影响哪些特性
怎样从品牌设计中获取灵感，对「一致性」与「灵活性」做好平衡控制
怎样维护设计系统的「一致性」
主讲人
本期主题
我们的设计系统团队：
由 5 位设计师，7 位设计技术专家（同时具备编程与设计技能的成员）， 1 位产品经理，1 位 QA 组成
我们与其他分布在全世界各地区的团队协作
支撑了上百个应用，服务于大约 10000 多名开发者
位于 San Ramon，CA
以季度为周期做计划，每天都有更新，能及时地处理反馈
代码都在 GitHub 上开源
那么进入今天的主题，「设计系统中的一致性与灵活性」。这两点是我们自己经常在设计过程中有所纠结的，我们也因此总结出了一些经验与大家分享讨论。图中的 Slider 其实就是我们系统中的一个组件，接下来它会频繁出场（笑）
大家普遍会认为「一致性」与「灵活性」是互相对立的。但其实一个成功的设计系统需要对这两点做到很好的平衡控制。
我相信大家和我们一样，在开始进行设计系统构建的时候往往对「一致性」投入很大的关注，毕竟这是我们作为产品设计师的天性，也是设计系统的一个重要特性。
我在 2016 年 10 月加入了 GE Digital，开始在 Predix 这个 IoT 服务平台工作。
这是一个能源厂里的测量机，图中圈出来的地方都是传感器，用来测量震动、温度、旋转、压力等数据，这些数据都会被收集上传到 Predix Cloud 上，再由 Predix UI 渲染成界面呈现给用户。
这里是一些我们的设计系统需要服务的行业场景：
资产评估
Predix 平台
能源
地区管理
航空
可再生能源
交通运输
制造
当我加入的时候，我们已经有了两个网站，一个是给开发者服务的组件库（左），另一个是给设计师服务的设计规范（右）
虽然看起来这两个网站已经构成了一个不错的设计系统雏形。但事实上我们去收集了不同业务部门的界面（上图），发现了残酷的现实：有一部分业务部门发现 Predix 并不能满足他们的需求，因而开始使用自己设计的组件，各部门之间又疏于沟通，最后的结果就是及其混乱的界面和交互，应该不会有用户相信这些应用是属于同一个平台的。这给我的感觉就像…我们还处在 Wild West 时期。
这简直是「灵活」到极致了，但我们已经不敢把它称为一个系统了。我们痛定思痛决定再次在企业里进行一次「一致性革命」。我们开始针对不同的组件来组织 Workshop。
不同业务部门的设计师都带着自己的业务洞察和建议来参加 Workshop，倾听用户声音的感觉很棒！
这项活动进行了一个半月之后，我们发现有一个呼声总是在不断的出现：“我们需要更多的「灵活性」！”
好吧…灵活是个人人都爱的优质特性。但我其实是有点困惑的，因为我们系统里已经有了相当多的可配置属性，自定义程度相当不错了，你可以修改单个控件的各种属性，也可以将它们像乐高积木一样拼凑成更复杂的组件。
为了真正搞清楚大家所提到的「灵活性」意味着什么，我们决定深入到每个业务的实际场景中。
我必须得说我们的业务真的是上天入地无所不在。你会在能源厂、消防站、风力发电厂看到我们的系统，这也意味着极度复杂的使用场景。比如消防站里的电脑系统很落后，我们的系统需要在 IE9 中流畅运行才能保证业务顺利进行；又比如这位在风力发电厂工作的员工，他在移动设备上使用 Predix，很可能数据信号质量非常差，人身安全也没有完全的保障，那这个时候用户对我们系统的需求显然只是极度的高效和稳定吧，“我要赶紧把活干完，再待下去我要窒息了！”
其实业务场景的不同会造成一些特性的不同，比如：
购买者和使用者：购买业务软件的人不一定就是使用者本人；同一个软件的用户也会有各自不同的使用目的。
使用环境：如阳光明媚的户外和阴暗幽静的地下室，是两种不同的使用环境。
使用案例：如老板和普通员工的视角和出发点不同，就形成了两种不同的使用案例。
已有的使用习惯：在使用我们产品前，用户可能用了很久其他的软件完成同一种工作，这样就形成了使用习惯。他会习惯性地按旧有的模式操作新的软件。
技术栈：同一平台下，业务场景的不同往往会导致软件使用不同的技术栈，导致数据难以互通。
这么一分析，我们就意识到如果我们一味地追求「一致性」，大家根本不会使用这个死板的系统。实在有太多的场景我们无法保证完全覆盖。
定义「灵活性」：
高度可配置可自定义并不意味着高度灵活
注意不要过于纠结单个组件的细枝末节，时刻保持系统性的全局视角
一定要搞清楚需求背后的原因，再开始进行调整或设计
不要在没有必要的时候追求「一致性」
这里我想从品牌设计的角度来讲解下为什么「一致性」并不总是对的。
在品牌设计中，我们可以看到三种子品牌模式：
Branded House（同在一个屋檐下）：如 FedEX 的品牌，所有子品牌都建立在父品牌的基础上
Blend（混合式）：如可口可乐，他会有零度、健怡等等支线，同时也拥有雪碧之类完全不是可乐的品牌
House of Brands（独立子品牌）：如联合利华，各种子品牌是完全独立的
那么我们其实可以借鉴这些模式来设计我们的系统。对于 Predix 来说，前两种更适合我们。
例如，航空业是我们所服务的一大行业场景，其中有四种关键业务：维护、航班计划、零件库存、通知，这些业务各自对应一个 App。而航空业的核心工作模式和流程要求这些 App 之间的数据必须互通，一个员工可能要使用不止一个 App 来完成他的工作，因此不同 App 的使用体验也要保证一致。那么在航空业这个场景下，「一致性」的价值就凸显出来了。
但我们再来看其他行业场景，交通运输业就有着和航空业完全不同的工作模式和流程。例如，一个交通运输业的员工只需要使用一个特定的 App 就可以完成所有工作，不需要数据的互通和体验一致。
而资产性能和能源两个行业场景的核心工作流程是有重叠的，会产生一定的依赖性。这种情况，就需要将「灵活性」纳入考量。
定义「一致性」:
在 Branded House 模式下，做到「一致性」很简单
Blending 模式需要更多的「灵活性」考量
不同行业或业务的核心工作流程会帮助你决定何时需要「灵活性」
这时我们意识到要做好两者的平衡
我们来看一下英菲尼迪的车族，它们虽然是不同的车型，尺寸和细节也有很多不同，但这张图里你会发现它们放在一起还是非常和谐。这是因为它们的骨架和曲线非常相似，融入了设计师对「一致性」的思考。
这里的两个界面都是从我们的系统里组装出来的，乍一看有很大不同：导航、图表形式、颜色、布局等等，但整体观感仍然是和谐的。
这是因为其中有很多一致的元素，例如字体。我们的系统只用了一种字体：Inspira Sans，使用 CSS 样式来增加「灵活性」，建立层次关系。
我们有提供「主题」功能，并且考虑到使用场景复杂多变，并没有对灰度进行严格限制。而且我们的产品有很重的数据可视化需求，因此我们建立了层次丰富的色板来提供支持。
由于我们在颜色上提供了丰富的可能性，各业务团队就可以灵活的配置出自己的视觉效果。
这三个界面的结构、布局、内容是一样的，只是使用了不同的灰度组合。左边的界面就很适合在暗光环境下使用。而中间和右边的界面可以凸显不同的区域。整体来看仍然符合 Predix 的气质。
网格和间距方面。我们更偏好用留白来表达空间关系，这比使用卡片或线条更加简洁大气。我们会把正确的间距直接在组件里呈现出来。
表单和输入组件则是在经过可用性测试后做到了桌面端与移动端样式和交互的统一。
我们也建立了 SVG 图标库
在 GE 我们不可能只用一套技术栈来构建所有产品。于是我们用 Polymer 来写桌面端组件，同时我们也提供了 CSS Module 来方便地进行样式套用。
我们为设计和代码都编写了详细的指南文档，记录下那些被提及了不止一次的问题。总结出 使用指南和 最佳实践 可以帮助建立「一致性」。
并不是每个人都习惯在网站上下载一个 Sketch 文件来查看你的系统到底是什么样。更友好的方法是让用户可以在网站上对他感兴趣的组件进行直接的交互。提供可供参考的开发实例和设计案例减少上手难度。
当然我们的 Sketch 文件里也放入了一些最佳实践的案例，这些页面里的配色、版式等等都是经过我们验证并推荐的。这些做法都给用户提供了极大的方便。
维护「一致性」:
建立一条阻力最小的上手流程，让系统使用者轻松上手
没有被写到文档中的都是模糊的，优秀的文档能够降低用户的决策成本
给用户提供能够即时查看即时操作的参考
指南并不是定死的规则，很多事情都是有讨论空间的。限制太死就会导致用户另辟蹊径
把设计过程公开出来才能够建立良好的信任关系。在 GE，我们经常会把用户叫过来与我们的设计师一起进行讨论和设计，你能够很容易地看到我们的 Roadmap。这样大家才会对你所做的设计判断产生足够的信任。
下面是一些可供参考的做法：
把正在做的东西拿出来分享
鼓励大家贡献想法
鼓励更多的协作行为
我们通过建立公开的 Slack 频道，Office hour 等方法来让大家获得更多的参与感
总结：
单纯地提供多种选项或自定义功能并不意味着灵活
「一致性」和「灵活性」一定是相辅相成、和谐共存的
关注用户的工作流程，可以很好的帮助判断何时需要更多的「灵活性」
上手阻力越小，就会有更多的用户采纳你的最佳实践，更有利于「一致性」
设计系统参与者之间的信任感是「一致性」的重要保障
感谢大家阅读。我是 Teambition 视觉设计师 孙浩，最近在负责 Teambition Clarity Design System 的设计工作，之后会在该专栏分享更多和 Design System 相关的译文与实践经验，期待与大家有更多交流～
