避免这些设计系统陷阱！

在过去的 10 年里，我一直热衷于帮助企业在用户体验方面走向成熟。在此期间，设计系统已成为企业和设计的主要组成部分。那么，为什么还有那么多人陷入10年前解决的陷阱呢？

什么是设计系统？

一种在数字环境中实施、维护和扩展视觉和交互模式的系统方法。

这通常会产生以下资产的组合：

• 关于元素可能是什么样子的一个事实点（通常是Figma）。
• 关于如何在代码堆栈中实现元素的单点事实（故事书，生活风格指南）。
• 使其工作的代码（HTML、CSS、JS）。
• 有关实施、愿景、创建新资产、指南等的文档（融合）。

目标是：

• 最大限度地减少维护。
• 提高可扩展性。
• 用户体验模式的一致性、质量和标准化。

想象

任何产品负责人都可以告诉你，成功的产品很大一部分是拥有强烈的共同愿景，设计系统也不例外。

Maui9 的愿景是：“我们相信设计系统应该使开发人员能够正确实现样式，这就是为什么我们：限制开发人员需要学习的类的数量。我们使用上下文感知类。空白由父元素（gap 和 flex）决定。CSS 变量用于确保白色标签和响应能力。我们不断关注开发人员如何使用设计系统、他们做得好的地方以及我们失败的地方，以便我们可以让他们更轻松”

设计原则

设计原则是帮助指导设计的清单。例如，他们可以帮助确定用户故事的优先级，并指导如何开发新功能。

我们的客户 Entidad 的设计原则是：

1. 它是否为用户解决了问题（我们试图解决的问题是什么）？
2. 使用起来是否直观？ （无需阅读文档）。
3. 它使用常见的模式吗？
4. 是否有清晰的视觉层次结构（在设计系统文档中进行了解释）？
5. 它是否为用户尽可能实现自动化（与开发人员聊天以了解我们拥有的数据或我们可以获得的数据）？
6. 操作数据时、保存数据和取消数据时是否清楚（与开发人员讨论性能问题）？
7. 预防错误比解决错误更好。
8. 视觉设计和交互设计分离（先线框，然后选择视觉元素）。
9. 最少地引入新模式。
10. 实施应侧重于开发人员实施的便利性、可扩展性和维护性。

设计系统的愿景和设计原则与业务目标保持一致非常重要。当两者协调一致时，这种影响就会渗透到业务的各个方面。开发人员、销售和业务工程师开始共同工作，并就某些功能如何以及为何发挥作用进行沟通，并且机会通常可能会从意想不到的角落出现。

实现方法：基于组件的设计系统与面向对象的 CSS。

我认为创建设计系统的第一个陷阱是不理解所使用的方法，导致使用多种方法，或者代码堆栈的方法错误。

基于组件的设计系统已经取得了长足的进步，而 React 一直是其中的驱动因素。 React 无法理解上下文，每个元素都是孤立存在的，并且可以通过传递 props 来改变。因此，React 通过创建小组件来工作，然后您可以拥有非常具体的样式。如果您需要更改组件，则可以在一个位置执行此操作。这适用于诸如 Tailwind 之类的框架，在该框架中您拥有高度特定的类（有人认为 Tailwind 距离内联样式仅一小步，如果您使用可重用组件，这并不是最糟糕的事情）。

可重用的组件也可以在Figma（组件）和Webflow（组件）等成熟工具中找到。这还允许您使用 UI 工具来设计组件，然后将其渗透到该组件的其他实例。

在组件级别管理视觉设计的一个重要好处是，您消除了开发人员根据他们认为好看的内容调整设计的能力（这是在设计系统中出现不一致的最快方法）。

“我喜欢使用 H3 作为主标题，因为它更小”“是的，我知道，我经常使用 H5 而不是标签”——如何让你的设计系统经理精疲力尽。

但是，如果无法在代码堆栈中创建和管理组件（*咳嗽* Mendix），那么您应该避免使用基于组件的设计系统。

面向对象的 CSS与基于组件的 CSS 正好相反。当使用 HTML/CSS 框架时，我们可以利用 React 无法做到的事情，即理解上下文。例如，卡片中的H3 的样式与面板中的H3 的样式不同是很简单的。这可以扩展到其他元素，例如填充和边距。如果卡需要填充，开发人员只需添加填充类，设计系统就会知道要添加的填充量。这消除了开发人员作弊的能力，并将责任转移到前端团队。

Maui9 通过诸如“icn-context”之类的类来解决这个问题，这些类将根据“上下文类”获得正确的图标，而“上下文类”可以根据业务逻辑进行设置（在此处阅读图标映射）。这还允许您在一个位置更新所有图标（参见愿景）。

使用非 Mendix 设计系统。

我经常被问到这样的问题：“那么，我们当前的环境使用MUI设计系统，我们希望继续使用 MUI 并将 MUI 代码作为我们的单点事实，我们如何将其导入到 Mendix 中？”

简而言之，你不能（而且你可能不想）。

为了让样式找到正确的样式元素，它使用了一种称为 CSS-Hook 的东西。与 API 需要非常严格的指令类似，CSS 也是如此。

如果您无法控制 HTML，那么您就无法重复使用来自不同平台的代码或技术文档。

这很快就会变得非常技术性，如果您想要技术故障，请DM我，所以我知道我应该写一个技术含量较高的博客来解释为什么不能混合和匹配CSS框架。

我能想到的最好的例子是：它类似于尝试将正在开发的非关系数据库映射到无法更改的关系数据库。这是可以做到的，但节省的时间很少，甚至可能会花费您更多的时间。

关于 Tailwind 的说明。

Mendix 社区平台（论坛、epics、sprintr）甚至考虑使用 Tailwind，因为 Mendix.com 使用 Tailwind。在与一些相关人员交谈后，他们表示不建议在 Mendix 中使用 Tailwind。

两个主要原因是Mendix 不支持组件，以及 Tailwind 严重依赖工作流程中的CSSPurger部分，而这无法用 Mendix 轻松完成。请随意忽略此建议，但您已收到警告。

概括

请注意，拥有一个设计系统并不是一个需要勾选的业务复选框。设计系统应该提升整个公司的水平，使其更加以解决方案为导向。

另一方面，您应该意识到，如果您在一开始就做出了错误的选择，那么您等待设计系统成熟的时间越长，您将拥有的遗产就越多，需要在某个时间点进行重构。

原文：medium