使用组件构建设计系统，以标准化和扩展我们的 UI 开发过程。
在本文中，我将展示和解释我们创建设计系统的过程。我将在每一步分享真实的例子。
创建设计系统是为了将秩序带入不可避免的熵中。第一个设计系统由NASA 于 1976 年推出，如今几乎所有大型组织，如 Uber、Pinterest、Airbnb 或 Shopify都有这样的系统，可以为更多产品和团队的混乱带来一致性。
在Bit，我们为 150,000 多名使用组件的开发人员构建工具。我们的平台帮助开发人员构建、共享和协作组件，以加快和改进 Web 应用程序开发。
我们享受由组件驱动的设计系统。
在过去的 2 年中，我们一直在“dogfood”我们的平台来构建一个设计系统，并将其变成一个共享模块化组件的活生生的生态系统。
我们系统的好处远远超出了 UI/UX 的一致性。我们极大地加速和扩展了我们的开发，提高了我们的产品质量，并极大地改善了开发人员、设计师和其他所有人之间的工作。
通过让每个人以协作的方式创建和共享组件，我们能够更快、更广泛地采用我们的设计系统。
在本文中，我将专注于开发人员方面，并将分享我们的目标、过程和结果。在下面的评论中随意参加 AMA。
视觉语言
共享组件
文档和发现
增量升级
对依赖项的涟漪变化
项目更新
团队沟通
设计师——开发者协作
- 我们的视觉语言
审核，然后订购。
我们创建视觉语言的过程与您在大多数关于设计系统的文章中所读到的有点不同。这是为大型企业保留的特权，对于年轻公司来说通常是一种奢侈的选择。
作为一家成长中的公司，我们没有时间停下来将我们的设计系统变成一个庞大而复杂的项目。相反，我们必须审核并将我们现有的视觉语言变成一个有组织的系统。
这个过程由 Bit 的设计主管领导
阿米尔·沙列夫
，是双重的：首先审核我们现有的样式和元素，然后创建一个一致的系统来将我们的视觉语言标准化为一个强大而灵活的基础。
我们在 bit.dev 中使用的表面和颜色
视觉一致性意味着为颜色、字体、大小、位置和视觉语言的所有其他部分创建统一的样式指南标准。字体、排版、原色和二次色等方面仍然可以指定为设计系统的一部分。
此外，我们需要创建一组一致的 UI 元素，以后可以使用现代框架（例如 React）将其实现为组件。
我们的按钮、头像和其他基本组件
为了使您的元素系统在现实世界中具有可操作性，它必须包含的不仅仅是一组基本的 UI 组件，如 Button 或 Avatar。它应该包括更具体的实例或组件组合的具体示例，这是您的功能的最基本实现。
组件组合以创建更具体和高级的功能
在您拥有两项资产之前，您的系统设计还没有准备好：
a)定义 UI 样式和实现的样式指南。这通常是一个相当长的文档，包含大量文本和排版。
b) 一组可重用的视觉元素，通过组件将视觉 (UI) 和功能 (UX) 一致性结合在一起。这通常是一个相当大的画布，上面绘制了元素
无花果
要么
草图
等（我们同时使用）。
2. 共享组件
构建组件生态系统。
有些人只是发布一个包含所有组件的单版本包。我们更喜欢创建一个共享的组件生态系统。
我们的流程
如果您前往Bit.dev 的主页， 您会看到一些很棒的东西。当鼠标悬停在一个组件上时，一个荧光笔将打开，指示组件的名称、版本和父 Scope。试试看。
Bit.dev 主页 — 共享组件的组合
您在这里看到的是一个由共享组件组成的页面。但是，这些是由不同团队开发和拥有的独立组件，并从不同项目发布，它们混合在一起并集成在一起。
在 Bit，我们拥有不止一个设计系统。我们有不同的团队在 UI 组件生态系统中构建和共享他们的组件。
如果您将鼠标悬停在链接或段落等组件上并单击链接，您将看到这些组件是“ base-ui ”范围的一部分。这是我们最基本的设计系统，由我们的设计系统团队在一个自治的GitHub repo中开发，并发布到 Bit.dev 供大家使用。
“Base-ui”——我们的基础设计系统组件
然而，营销团队需要一些更具体的组件，例如营销“标题”或“操作按钮”。这些不是 base-ui 设计系统的一部分，而是另一个名为“ Evangelist ”的 Scope 的一部分。在这个GitHub 存储库中，他们自主地属于营销团队。由于他们使用来自 base-ui 的组件，因此他们从 base-ui 团队获得更新。
“布道者”——我们的营销组件
Evangelist只是组成和扩展 base-ui 组件的众多 Scope 组件之一。事实上，公司中的每个团队都构建并与其他人共享自己的组件范围。
我们不是为组件发布一个单一尺寸的包，而是创建一个生态系统，每个人都可以一起工作但独立交付。设计系统的团队角色是促进和规范，而不是阻止或强制执行。
结果证明这是一个巨大的成功，我们能够将新营销页面的构建时间减少约 75%，同时保持我们的设计一致。尝试访问bit.dev/enterprise页面或/support页面以查看示例。公司的许多其他团队也取得了类似的成功。
使用我们自己的工具
我们自己对 Bit 的“dogfooding”意味着我们以帮助他人构建的方式构建。自 2017 年以来，我们已经这样做了几年。这是要点。
我们使用Bit 的 OSS Workspace在不同团队拥有的不同代码库中开发、管理和发布解耦组件。
我们喜欢Bit 的云平台，帮助所有团队顺利地公开、共享和集成组件。
设计系统团队提供我们的基础组件、控制更新并规范变更以确保一致性和标准化。
选择反应
出于各种原因，我们在 2017 年选择使用 React，并且对我们的选择感到非常满意。自从在 React 16 中引入 Hooks 和 Context API 以来，即使在状态管理方面，组件相互分离的能力也变得非常出色。
然而，我们看到许多团队选择将 Bit 用于 Vue 或 Angular 甚至 Stencil Web Components。我们甚至一直在与 Angular 团队合作，为 Bit with Angular 提供支持。在考虑了所有因素之后，我们相信 React 是目前最适合我们的解决方案。
独立组件
Bit 工作区可帮助您构建模块化项目，同时享受简单而全面的开发体验。每个组件都是独立开发、构建、测试、记录、发布和集成到新应用程序中的。所有组件都和谐地组合和管理。试试看。
标准化发展
实现设计一致性的另一个好方法是标准化组件的开发。Bit 通过各种功能帮助我们做到这一点，例如标准组件开发环境、可重用的文档模板，甚至可扩展和可重用的构建管道以标准化发布过程。
可定制、可扩展、可重用的构建管道
3. 文档和发现
始终保持最新。没有额外的工具。
使用 Bit 的另一个优势是我们不需要为组件创建或维护额外的文档网站。
地方发展
在我们编写组件时，Bit 的 UI 会显示本地开发环境中每个组件的文档。这包括描述、示例，甚至是单独呈现组件的组合。
您可以创建可自定义和可重用的文档模板，以便所有组件都可以按照相同的标准和设计进行记录。
文档是本地开发的一部分
云上的文档
文档只是每个 Bit 组件的一部分。当它被导出到云端时，它的文档就成为了组件的首页，供大家查看。可以在托管组件的同一位置查看和探索文档。如果您安装或导入组件，您也可以在本地开发文档。
“令牌，然后是 React，UI 工具包，然后是文档站点，用于更改指向这些 + 发布文档的链接”
— Kaelig Deloumeau-Prigent，开发人员，Shopify 的 Polaris
Bit.dev 上的所有文档都是我们在本地开发时看到的。对于组件的每个新版本，它的文档也可以轻松更新。没有额外的开销，没有复杂的流程，没有过时的文档。
你在本地开发的就是你在云端得到的
可发现性和搜索
随着我们拥有越来越多的组件，Bit.dev 通过组件搜索和上下文过滤器等功能使组件可被发现，帮助我们轻松地立即搜索许多组件。
前往 bit.dev 并搜索数千个 OSS 组件，或添加您自己的组件
4.增量升级
独立的组件版本控制。
我们的设计系统是按组件进行版本控制的，而不是作为一个单独的包。
对独立组件进行版本控制比将所有组件作为单个包进行版本控制要好得多。独立的每个组件 sem-ver 已经改变了我们的游戏规则。我还建议令人敬畏的Nathan Curtis的这篇精彩文章。以下是我们的主要优势：
我们只获取您使用的东西所需的更新。
我们可以轻松快速地升级单个组件。
我们可以轻松地修复或回滚任何组件。
我们混合和匹配组件来创造任何东西。
Bit 帮助我们将每个组件作为独立包进行版本化和发布。由于每个组件都是独立版本的，我们的不同项目可以对组件进行增量升级，而不仅仅是一个大包。
如果您查看此按钮组件，您会注意到它当前的版本为 1.5.0，并且不久前从版本 1.0.0 开始。
这为我们的设计师和开发人员提供了极大的自由来不断创新和发布升级到生产。
例如，这里是生产中使用的 ‘button’ 版本 1.5.0。
布道者/button@1.5.0
这是以前的版本 1.4.0。
这是“按钮”的最早版本 1.0.0。
布道者/button@1.0.0
如果您返回 1.5.0 版本，您会注意到它有一系列示例，这些示例支持比以往更多的设计用例。
我们的设计师和开发人员能够自由创新和交付升级，而无需等待大型臃肿版本或长时间发布。
组件开发人员可以根据 sem-ver 规则控制每个组件的版本变化，查看其历史记录，甚至查看其更改日志。
应用程序开发者不会获得他们不需要的更新。每个人都很开心。
- 对依赖项的波动变化
管理所有组件关系。
Bit 管理项目中所有组件之间的依赖关系图。这意味着当我们升级或破坏一个组件时，Bit 将“知道”哪些其他组件依赖于它，并将运行它们的构建和测试。
因此，在单个项目中开发多个组件变得更加容易，因为更容易掌握它们的内部关系。
“如果我们升级和破坏一个组件，我们必须遍历并修复所有依赖的组件”
— Jony Cheung，Atlassian 的 Atlaskit 软件工程经理
在每次更改时，所有相关组件的构建和测试都会运行，并让我们确切地知道哪些是损坏的，哪些不是。如果一切顺利，我们可以简单地告诉 Bit 一次碰撞所有依赖组件。
我们现在正在开发一种名为Ripple CI的新产品。通过云，Ripple 的构建过程会将更改传播到组织所有应用程序中的所有依赖组件。我们（和您）将能够准确地看到每个组件是如何受到影响的，在哪里以及如何受到影响，然后修复和发布（想了解更多信息？要求加入我们的 Beta 计划）。
6. 项目更新
通过 GitHub 集成实现自动化。
我们使用公开可用的集成将 Bit.dev 与 GitHub 连接起来。当组件的新版本发布到 Bit.dev 时，它将“知道”哪些 GitHub（或 GitLab）项目应该获得此更新。
然后该过程变得完全自动化。
组件的新版本作为自动拉取请求发送到所有消耗项目，只需单击即可接受。
这使得我们的设计系统团队可以很容易地持续提供升级并帮助所有产品构建者接受和集成这些更改。
而且，我们的设计系统团队可以随时监控谁忘记更新什么和在哪里。这里
吉拉德肖汉姆
谁领导我们的核心团队只是避免了严重的推动！当心吉拉德，我们看到了一切。
- 团队沟通
通过 Slack 集成实现自动化。
当新的组件版本发布时，所有使用该组件（即将该组件作为依赖项）的团队都将通过平台以及 Slack 集成获得更新通知。
因此，例如，当“购物车”中的“按钮”版本被导出时，我们的团队会收到一条通知，其中包括用户名、操作类型（导出）以及与该特定操作相关的组件数量。
这里
伊甸园艾拉
来自 Envagalism 团队的升级按钮被抓获。
导入时，会显示相同的通知，但会显示原始范围。
此工作流程可帮助每个人保持同步并更好地协同工作。
8. 开发者——设计师协作
以可视化的方式通过代码协同工作。
设计系统对设计师和开发人员意味着不同的东西。
设计师通常谈论他们画布上的元素。开发人员在他们的 IDE 中谈论 React 组件。用户将获得代码，而不是设计。
这就是为什么将设计师纳入我们的 UI 开发过程至关重要的原因。
我们使用两种出色的工具来实现牢固的相互握手。
第一个是
齐柏林
— 这是设计师与开发人员合作的好方法。我们用来将设计任务转换和组织成开发任务，并且我们每天都在使用它。
第二个是Bit——这是开发人员与设计师合作的绝佳方式。它为我们的设计师搭建了一座桥梁，让他们能够积极参与 UI 组件的开发。此外，帮助我们的设计人员监控代码更改和组件的新版本并进行协作。
💡 Zeplin 和 Bit 团队现在正在进行联合集成！
设计人员可以以可视化的方式查看和尝试实际的 React 组件
我们使用 Bit 向我们的设计师展示我们所有的组件，并帮助他们始终确保一切都与设计保持完美一致。
热重载渲染和可编辑示例等功能是设计人员查看组件甚至尝试不同设计的好方法。
当有一个新组件发布到 Bit.dev 或现有组件的新版本时，设计人员可以立即直观地看到发生了什么变化。这使得确保一切都与设计保持一致变得很容易。
然后，在设计人员批准后，可以将更改作为自动 PR 发送到受更改影响的所有项目。这意味着我们的设计师现在直接与开发人员合作开发组件。很酷，对吧？
在不久的将来，我们的团队打算为 Bit.dev 添加更多面向设计人员的功能，例如交互式属性面板，以便设计人员可以对组件进行更改，并将其保存为新版本。应该在 2021 年准备好。
结论
NASA 2020 年设计系统
在产品的每个接触点创建并保持一致的 UI/UX 有助于用户直观地导航并成功地与应用程序的不同部分进行交互，而不会混淆。这是你的品牌。
你需要一个好品牌。
在我们的过程中，我们一直在从头开始创建一个设计系统。我们审核了现有的设计，然后把它变成一个有序的系统，定义我们的视觉元素和风格指南，讲述我们品牌的故事。
我们依靠我们自己的工具云平台来创建一个共享组件系统，在这个过程中将每个人聚集在一起。我们让组件在一个民主化但受监管的生态系统中推动我们产品的开发。该系统得到快速和几乎绝对的采用。
我希望这可以帮助您了解我们的流程以及在现代世界中共同构建 Web 应用程序的可能性。
我们一直在帮助许多非常优秀的团队以类似的方式构建自己的系统，请随时与我们联系并提出任何问题！
感谢阅读🍻 🎨 ❤️
若有收获，就点个赞吧
0 人点赞
