更智能的设计系统工具

让我真正兴奋的是网站构建，主要围绕着设计系统以及我们用来构建它们的工具。不过，设计系统当然不局限于网站。

缩小差距

在如今炙手可热的设计系统领域，人们最常使用的一句话是“弥合差距”（设计师和工程师之间）。这出现在我在 Salesforce 工作时审查的几份简历中，当时我们正在为 Lightning Design System 团队招聘。这是一个值得努力的目标，因为我们希望在产品设计和工程方面实现一致性、连贯性和统一性——所有这些目标都是为了让使用我们产品和服务的人拥有高质量一致的体验。

然而，“弥合差距”仍然意味着存在差距。为什么一开始会出现这个差距？是由于多年来遗留的流程和工作流程，它们仍然渗透到我们日常工作中吗？我能看到遗留问题是现实世界中的一个场景，需要去解决。但那些更新更小的初创公司呢？为什么他们中许多人也存在差距？

作为一名设计系统实践者、倡导者和爱好者，我一直在寻找改善工作中的人员方面的方法：我们如何见面和交流、如何优先考虑路线图以及如何迭代我们的流程和工作方式。但是，这方面还有另外一个因素是**我们使用的工具**。

我们的一些工具已经取得了长足的进步，而且现在似乎经常会发布新工具。但真正让我兴奋的是，我看到它们所做的事情超越了“弥合差距”。

有一段时间，当Modulz 出现时，我注意到他们使用了标签#closethegap。我忍不住喜欢它。

我非常喜欢@Modulz #closethegap 的口号。为什么弥合差距，当你完全可以消除差距时？填补那个差距！哈哈。

—— 设计系统 jina (@jina) 2018 年 10 月 22 日

我非常想看到我们的设计工具不再仅仅是弥合差距，而是更进一步，彻底消除差距。例如，我认为只有弥合差距的功能是“开发人员移交”（这往往依赖于作为规格提供的像素尺寸和十六进制代码）。根据我的经验，提供这样的规格可能会导致代码中的重复、不一致，并且容易出错。然而，消除差距的例子是使用实际、真实、高质量代码而不是矢量框的工具。

一些工具通过公开设计令牌 来实现这一点——你可以在 InVision DSM 中看到这一点，它内置了令牌作为一项功能。另一个工具Diez 是一款开源开发工具包，它使用令牌将你的设计语言转化为可扩展的代码。还有其他工具，例如前面提到的 Modulz，以及 Interplay，它们都使用代码化的组件，但以一种可视化的方式。这比过去早期所使用的所见即所得编辑器要好得多，因为它们生成的代码可以访问且具有生产质量。当然，还有这个领域的其他人，比如 Adobe、Figma、Framer、Sketch、UXPin，以及许多其他公司，他们也在为推动这一进步做出很多努力。

无形的设计系统

我一直都在思考一个问题，那就是我们花费了多少时间来制作精美设计系统网站。我喜欢浏览它们。它们很棒。但是，随着我们的设计和工程工具越来越接近，我们会达到不需要网站的时候吗？我们的工具可以针对更好的可访问性、本地化、性能和可用性提出建议吗？因为我们的设计系统已融入到这些工具中？只是一个想法。

无代码运动

Webflow 允许人们在不编写代码的情况下构建网站（包括业务和电子商务功能），最近举办了一场名为 No Code Conf 的会议。根据他们的网站，这次会议庆祝了可视化开发的未来。

这场运动虽然并不新鲜，但正在迅速发展。除了使用 Webflow 构建功能齐全的网站之外，可视化的、声明式的应用程序构建多年来一直在像 Salesforce（及其 Lightning App Builder）这样的大型科技巨头和像 Glide 这样的较小公司中得到探索，Glide 允许你从电子表格生成整个应用程序。并且，随着 Zapier 和 IFTTT 等所有基于任务的自动化服务的出现，你可以完全不用编写代码就能完成许多事情。

现在，不要误会我的意思。我仍然喜欢编写代码，并且喜欢看到其他设计师编写代码。我也喜欢与工程师密切合作。我不是说我们不应该完全编写代码。但我很高兴看到我们从更缓慢的“将设计扔过墙”的流程中摆脱出来。我希望看到人们能够在不需要编写代码的情况下创造事物。摆脱“设计师是否应该编写代码”这一老掉牙的争论也很好——我们都朝着**我们能一起创造什么？**的方向前进。

如果我们能够达到一个不需要弥合或消除任何差距的阶段，因为差距从未存在过——嗯，那是一个我非常想进入的世界。