前段时间阅读了一篇好文，是来自5key老师发表的「Design System」系列文章，受益良多，所以也想分享给热爱设计的你们，在此对「Design System」系列文章做了一个摘录概括，留存学习～原文地址：https://zhuanlan.zhihu.com/p/31197706

什么是Design System？

可以定义为解决数字产品生产的整体解决方案，包含设计、内容、工程等多个方面。

如果大家对Design System感到陌生，那么说到 Design Pattern、Design Component、Design Language、Design Guideline 等等这类词相信大家一定不会陌生。即使对于这些概念并不太清晰，但或多或少都会在设计的过程中受到一些影响。

说到Design System，也是特别巧，因为楼主前段时间恰巧在进行公司B端产品设计体系的制定，这篇文章犹如及时雨一样给了楼主很多引导和帮助，特别是在Component和Pattern这部分，避免了两者之间的混淆，同时融入了Design Principle的指导与思考，让笔者可以站在一个完整的、全局性的视角去思考设计体系规范的制定。

Design Principles(设计原则)

Design Principle，其中文翻译是设计原则。Principles 是一系列的规则、指导以及设计中的注意事项。它是我们构建一套Design System 的起点，用于解决业务、用户体验中的问题，引导设计往既定（正确）的方向前进。

每一个公司(团队)，由于其业务的特性将可能产出不同的 Principles。

以 IBM 的 Carbon Design 为例，他们的 Design Principles 是: 1. Be essential (必要的) ；2. Be inclusive (包容的) ；3. Be consistent (一致的) ；4. Be humanistic (人文的) ；5. Be delightful (愉快的)。这是 IBM 对其云产品在整体产品体验上的定义与要求，也是它们想要传递给用户的感受。作为设计的基本原则，它将嵌入到其产品、设计、开发、文案等一系列场景中，成为产品的“灵魂”。

Design Principle可以分为业务型和抽象型两类：

1、业务型：

以 SAP 的 Fiori Design 为例，它强调的基于角色  、愉快的、一致连贯的、简单和适应的。如果你对 SAP 的业务有一些了解(甚至是它的用户)，你应该不难解这些关键词对于 SAP 用户的重要性。这些关键词与 SAP 的业务特性有着非常密切的关联，甚至说做不好这些点他们的用户将不会愿意继续选择他们的产品。

2、抽象型：

相对SAP，Material Design 给出的 Principles 就比较抽象了，似乎很有道理但似乎又什么都没说。作为一款操作系统级的语言，它更多的是提供一个土壤，却又不知道下一个新出现的产品会是什么样。他们更需要的是赋予整个环境一个完整的世界观，一个经得起推敲(Material)的世界观。

Material Design 这类 Design System 很重要，我们需要去学习研究它，不过更多是站在其平台(iOS 也一样)进行产品设计。对于 Principles 的研究，我们应该放在这些偏业务的类型上。毕竟我们很难(也不一定需要)创建一个世界观，但做好一款产品是迫切需要的。

Components 是什么？

它是整个产品设计的基础，是组成一个界面的最基础元素，为完成一个基础操作提供支持。早在 Web 时代我们就有  Components 的概念，输入框、按钮、文字、链接、下拉菜单... 从网开始出现，这些元素就已经被大家所认知、牢记。无论页面的设计如何变化，它们基本上都是由这些组件所组成的。

当然，网页时代的早期我们可用的组件并不多，偶尔出现一些新的形式也都是基于现有的组件组合或变形 来的。所以对于用户来说记住并理解它们的用途并不太难，这也就为日后的设计的不断发展提供了一个可被认定、认知的基础。

移动互联网时代的到来，用户的互联网环境已经逐步迁移到手机。于是对于设计师和用户大家开始接触到  了iOS、Android、Microsoft 等新的平台，开始与这些新的组件打交道。

事实上这些元素并没有发生太大的变化，它们很多只是基于屏幕大小和可触控的新特性发生了进化。 我们所看到的那些组件在不同平台上的差异性更多是源于系统平台本身以及它们的设计理念差异。这个现状给设计师带来了更多的麻烦，我们在设计产品的同时还需要更多的关注不同操作平台的组件差异性，以顺应 不同用户的使用习惯。当然，随着行业的不断发展我们所面临的麻烦会更多，我们现在所能看到的 VR设备、线下实体以及我们还未看到的新的形式都会让 Components 不断的进化，也变得更复杂。

Patterns 是什么？

相对于 Components，Patterns 要处理的事情会更复杂一些。它的目标是为完成一个任务提供基础操作，是解决一系列问题的全局解决方案。

举一个直接的案例，在 Material Design 中有一个叫做 Confirmation &Acknowledgement (确认与知会)的 Pattern。简单来说当用户在App 中执行了一个操作，我们需要给予反馈，告知用户， 这个 Pattern 要解决的问题就是为这一系列场景提供一套设计解决方案。

Components 与 Patterns 之间的差异

1. Components 相对稳定，是整个 System 中的基础物料(砖、瓦、泥)，是解决单点问题的基础元素。大家对它是具备基础认知的；Patterns 则是解决一类问题的整体解决方案，有多种的可能性;

2. 从工程角度来说 Components 也是相对稳定的，Patterns 是基于这些相对稳定的 Components 组合而成的;

3. Patterns 具备领域的差异化，不同的领域它所关注的点以及设计的处理形式都存在着差异;

4. Patterns 更加的复杂，不只是界面，也可以是流程、手势、甚至是透过视觉、动效、方案传递出的一种气质。

Design Language

一套设计理念更像是一个世界观，它最终需要落地在一种 Language 上便于大家理解、交流，Material Design 就是一个太好的案 。从真实世界的观察到数字世界中的模拟，Material Design 很好的解释了其设计理念的由来、论证其合理性。

「Design System」这本书中也有提到一套 Design Language，把 Component 比作名词或动词、Style 比作形容词，组成一个短语(Pattern)。这套基于语言推导出来的 Design Language 通过 Conversation(会话)很好的构建了另一套世界观。将 Language 比作世界观，也就说明了创建它本身的难度。所以我并不认为一套新的 Design Language 的创建是件容易的事情，它需要体现出设计理念，要经得起大家的挑战。

Develop Library

Develop Library 是 Design System 中的设计工程化，也是 System 必不可少的重要一环。设计和工程的同步才有可能保障产品设计中的一致性和效率。

有很多“Design System”是基于 Pattern、Component 等文档型，准确的说应该是 Guideline。 只有将设计模式再落地到工程环境中才能称之为 System(如 Carbon、Lightning、MailChimp)。随着设计的更新迭代，工程师进行 Library 的更新迭代以确保整个系统及其衍生的产品稳健的更新、服务。

Design Guideline

最后我们再来说说 Guideline。在基于 Design Principles 创建出服务于自身业务的 Pattern(Component)、除了 Language  便于大家理解和交流，我们还需要一系列的文档辅助生态中的用户(团队内、外)正确的使用它们创建满足要求的产品体验，这就是 Guideline 的目标和意义。

最典型的案例也来自 Material Design 。在 Guideline 中它描述了某个Component 或 Pattern 的定义、使  法、最佳实践，甚至还有 do 和don’t，帮助设计师更有效的使用 Guideline 辅助设计。

对于 Guideline 业内似乎并不刻意去区分它的意义，可能会导致大家对于它和Pattern、 Component 甚至是 Language 之间的混淆。从使用角度来说 Guideline 也许可以包含(代表)那些其他概念，但从逻辑角度出发我们依旧需要清楚它的目的以及何时出现。

在明白了这些理论后，我们还需要多多实践，就像楼主给公司B端产品做设计体系一样，有机会能在工作中去运用这些知识，发现不足、错误，然后去改进和吸收正确的方式，我想只有切身体会和经历，这些知识才会变成你的知识，载入到你的知识库里，然后一直受用～