UI 设计系统和组件库：问题出在哪里

设计师和开发者之间在 UI 组件方面的工作流程是否被打乱了？2020 年情况会好转吗？

那么，哪一部分是您的实际设计系统？

这里有一个问题……“你的设计系统到底是什么？”

如果你问设计师，他们会说是一些图片和指导原则。除了组件之外，它还会包含字体、大小、边距、位置以及其他与视觉体验相关的重要方面。

作为开发者，他们会说这是 GitHub 上的一个库，用 React、Vue、Angular 或纯 JavaScript 编写的。他们或许还会提到 Zeplin。

这是一个真正的问题，因为你想象和期望的成果与几年后最终实现的成果之间的差距每天都在扩大。为什么？因为有些东西在视觉效果和代码之间的转换中丢失了，也因为随着时间的推移，现实迫使开发人员不得不做出改变。这就是生活。

因此，让我们暂时抛开我们目前熟知的Sketch->Zeplin->GitHub->Apps工作流程，尝试探索未来的发展方向。此外，我们还会介绍一些可能有助于巩固现有工作流程的工具。

这篇文章基于 30 多个团队在构建组件设计系统过程中不同阶段的经验撰写而成。欢迎在下方留言，分享您的任何想法、见解或建议。这也会帮助其他人学习。祝您学习愉快 :)

您的设计系统到底是什么？

Airbnb 的组件设计系统

唯一真正的事实是：

你真正的设计系统就是你的用户所得到的。不多也不少。

你可以在 Figma 或 Sketch 中拥有最棒的组件，以及迄今为止最优秀的设计系统指南。如果它既不适合你的开发人员使用，也不适合你的用户使用，那它就不是你的设计系统。

即使使用 React、Vue 或 Angular 编写，你也可以拥有最好的 UI 组件库。如果构建你应用的开发人员只是从你的库中复制粘贴代码或进行修改，那这并非你的设计系统。

这就是为什么一个实用的设计系统必须能够适应图像和代码之间的差距，以及计划和后续演进之间的差距。运用正确的思维和工具，您现在就能找到一个切实可行的解决方案。展望未来，这套工具链和工作流程应该得到真正整合。我们将探讨Bit、Framer等能够实现这一目标的工具。

• 另请参阅：构建 UI 组件设计系统

设计与 UI 库之间的差距

许多公司，如Uber Design和AirbnbEng，正在构建 UI 组件设计系统（参见Uber和Airbnb 的视觉语言）。

为了将这些系统转化为应用程序中使用的代码，他们实现了 UI 组件库（例如HP、Atlassian、Pinterest等公司的库）。这些库又被安装并应用于不同的应用程序。

图书馆建设中的差距

但是，当开发人员需要将图像转换为代码时，结果可能会与预期有所不同。Zeplin 等工具可以简化此过程，但更改往往不可避免。例如，相对定位与绝对定位是一个常见问题。字体以及在组件中使用字体也是一个常见问题。

当设计需要融入现实世界中可用的组件并应用于实际应用时，开发人员必然会做出一些选择。即使在与设计师协商后，也难免会产生分歧。

差距随时间推移而演变

随着时间的推移，这个库必须由 2 个、20 个或 200 个开发人员在 2 个、20 个或 200 个应用程序中使用。有些人需要进行一些修改才能使这个库适用于他们正在进行的项目。否则，他们就不会使用它（Bit可以极大地帮助减轻这种痛苦，我们稍后会讨论）。

其中一些更改可能会回到库中，修改代码，使其更适用于您正在构建的应用程序。然后，设计和代码之间的差距就会进一步扩大。

UI 库和应用程序开发人员之间的差距

UI 组件也可用作 UX 组件，结合其功能为您的用户创建功能和视觉一致性。

基于组件的设计系统可以为您的应用程序提供视觉和功能的一致性，帮助您的用户感到宾至如归，并轻松导航以完成与您的产品所需的交互。

有时，应用开发者会因为各种原因无法使用该库。例如，某个组件的样式或边距不合适。又或者，该库给需要轻量级和快速运行的应用增加了太多负担。

当开发人员需要修改库中的某些内容时，他们必须发起拉取请求，而该请求可能会被接受，也可能不会被接受，而且具体日期也不得而知。这严重阻碍了此类库的采用，并且非常常见。

应用程序开发人员不会总是使用该库

那么，实际上会发生的情况是，有些开发者不会使用这个库，而是自己构建组件。或者，他们可能会把库里的代码复制粘贴到自己的项目中，然后私下做一些修改。

你不能真的责怪开发人员，因为他们需要完成工作。你不能强制执行你的设计系统，因为它应该切实可行。你需要接受改变是必要的，并且优先考虑监管、透明度和协作，而不是强制执行。始终如此。

使用Bit会变得更加容易，任何开发人员都可以直接从他们正在构建的任何项目中建议更新组件，因此您可以协作进行更改并进行规范以跟踪更改而不是忽略它们。

整合设计和开发？

让我们把人们聚集在一起；图片来源

正如生活中的许多其他事情一样，你需要将人们聚集在一起，才能成就更伟大的事业。在这种情况下，你需要为三个不同的受众创建共同点，以便他们共同构建和迭代你的组件：

• UI设计师

• UI组件库开发人员

• 应用程序开发人员（使用该库）

只有创建一个可供所有 3 者协作的整合空间，您才能（希望）确保用户的最终体验与规划人员设定的设计指南和视觉资产一致。

现在我们来谈谈真正的问题：

设计师不使用 GitHub，也不阅读 React/Vue/Angular 的代码。库开发人员必须翻译代码，你永远无法指望所有东西都能用。应用程序开发人员只想找到并使用组件来构建应用程序。

Sketch、Zeplin 或 GitHub 都无法满足所有这些需求，在这些问题得到解决之前，我们将不得不经历一个支离破碎的工作流程。但是，现在有没有工具可以做到这一点呢？让我们来检验一下。

未来的 UI 组件工具

让我们快速回顾一下一些工具，展望未来，它们可以帮助弥合开发人员和设计师之间的差距。

Bit 和 bit.dev（针对开发人员）

Bit 是一款开源工具，可将组件转换为共享的构建块。使用 Bit 和bit.dev组件平台，开发者可以立即将组件从库和项目中分离出来并共享到一个“类似播放列表”的集合中，方便随时随地发现和使用。

通过此集合，可以安装（npm/yarn）组件，甚至跨不同项目开发（bit import）组件，因此开发人员和开发团队可以轻松共享和协作 UI 组件来构建应用程序。

通过 bit.dev，实际的代码组件（React、Vue、Angular）将被渲染和可视化，以便开发人员和设计人员能够准确了解其组件的外观、行为和用户体验。他们甚至可以随时在可编辑的 Playground 中试用这些组件。

当开发人员对特定组件进行更改并更新版本时，设计人员可以立即看到新版本并监控更改，以确保实际组件适合他们的设计系统。

这样就形成了一种平衡，开发人员可以在必要时灵活地对组件进行更改，并从他们自己的项目中提出更新建议，而设计人员可以协作来审查一段时间内的更改。

Framer 和 FramerX（适用于设计师）

FramerX是一种快速原型设计工具，可让设计师在 React 中创建逼真的组件并为他们的应用程序设计高级交互。

内置的 React 组件使设计师能够更接近高保真原型设计。在大多数设计工具中，设计主要以视觉形式呈现——按钮、滑块或切换按钮的图片。Framer Team的编辑器让设计现在可以更具交互性。得益于 React 组件，滚动、点击、移动和处理输入等交互现在都成为可能。

Framer X 的底层构建于 framer.js 之上，framer.js 是一个开源库，用于将 React 代码转换为交互式设计。您可以自行编写用于实现这些设计交互的 React 组件，也可以从应用内的设计商店下载。

另请查看：**Hadron **

FramerX 和 bit.dev 一起吗？

通过集成 Framer 和 Bit，您可以创建一个工作流程，使用 FramerX 设计 React 组件并将其分享到 bit.dev。这是一个使用 Framer 设计并分享到 bit.dev 的基本 React 按钮组件的示例，因此现在可以在不同应用中轻松发现和使用它。

展望不久的将来，将这两个强大的工具结合在一起，可以弥合 UI 组件设计和开发之间的差距，从而整合设计师和开发人员之间的工作流程。很酷吧？

结论

展望未来，我们希望设计师和开发人员的设计和构建组件的工作流程能够得到整合。

我们的工具链中容错的空间越小，我们为与我们的产品和应用程序交互的用户打造的体验就越好。这种协作应该从一开始就统一起来，并随着我们的设计系统和组件的不断发展和演变而保持活力。

希望我们能尽快看到这一点。在此之前，请随时分享您对如何处理这个复杂工作流程的看法，以及您认为可以改进的地方。感谢您的阅读，希望您喜欢 :)