设计系统≠UI库！你必须知道的关键差异

初次接触设计系统的感觉，就像被吸进了一个黑洞。

那时，我在一家卡车软件公司担任产品设计师。随着业务的指数级增长，我们的用户界面库迫切需要改进，以支持业务需求。在对界面库进行审计时，我发现了许多需要优化的地方，并了解到 Figma 刚刚推出了自动布局功能。我决定将这项新功能引入我们的库，但这个看似简单的任务却逐渐演变成了一项复杂的挑战。不仅仅是优化组件，我最终构建了一个完整的设计系统。在这个项目中，我一人分饰多角：设计组件、进行研究、编写文档，还负责培训团队成员如何使用和维护这一系统。

我开发的第一个设计系统，初衷是解决设计与开发之间的协调问题。在深入探索设计系统的过程中，以及在后续的职业经历中，我汲取了许多经验和教训。回想起来，有些事情真希望当初就有人提前告诉我。

当 Figma 推出自动布局功能时，它改变了设计师构建组件的方式。为了充分利用这一功能，我对现有的界面库进行了一次全面审计，以确定可以重建的元素。在这个过程中，我发现设计和开发之间存在显著的组件差异：虽然开发人员和设计师可以访问所有组件，但却缺乏明确的指导原则来说明这些组件的使用场景和方式。

原本，我以为这只是一次组件更新任务，但事情远不止如此。我不仅需要为部分组件应用自动布局功能，还不得不创建一套文档，为产品提供更高的一致性。渐渐地，原来的用户界面库演变成了一个完整的设计系统。通过这次经验，我深刻认识到，用户界面库只是组件和样式的集合，而设计系统则是一套系统化的管理指南，指导这些组件和样式的使用和维护。

软件产品的核心在于解决用户问题并满足特定的业务需求。而要打造一个高效的产品，首先需要明确用户是谁、他们的工作流程是什么、痛点在哪里。同样的逻辑也适用于设计系统。在设计系统的构建过程中，你实际上是在为两类用户设计。第一类是最终用户，他们是公司最终产品的直接受益者；第二类是产品设计师，他们需要依赖设计系统来打造优秀的用户体验。当你把设计系统当作产品对待时，产品设计师可以将更多精力集中在如何为最终用户提供流畅的体验上，而不必浪费时间纠结按钮颜色等细节。同时，开发人员也能更方便地获取组件，并快速完成组装工作。设计系统的终极目标是优化用户的工作流程，提高效率，节省时间。从本质上看，设计系统是一种专门用于打造产品的产品。

开发人员和设计师在使用设计系统中的组件时，都能显著提升工作效率。然而，真正的难点在于确保这两个团队之间始终保持一致性。

最终用户并不会直接接触设计工具（如 Figma、Zeplin、Invision 或 Sketch），但他们会与最终产品交互。如果设计与开发之间存在脱节，用户往往能够察觉到，尤其当这种问题出现在设计系统层面时，会显得尤为明显。功能的一致性同样至关重要——用户需要能够预测组件的行为。一旦组件表现与预期不符，用户体验就会受到影响，公司也可能因此失去他们的信任。

因此，在设计系统的每个阶段，设计师与开发人员都需要密切协作，共同维护一致性。我深刻体会到，协作是设计系统取得成功的唯一关键。

在我创建设计系统的早期阶段，曾为自己设计的调色板感到无比骄傲。我赋予颜色风格一些独特的名字，比如“牛仔布”“浅灰色”“孔雀石色”和“朱砂色”，自认为既灵活又时尚。然而，问题很快浮现：当我们的车队管理产品需要支持深色模式时，调色板的缺陷暴露无遗。

最大的问题是，组件中的颜色使用缺乏标准化。设计师和开发人员常常不知道该在何时使用哪种颜色。有些边框是灰色的，有些是蓝色的，而在深色模式下，这种混乱进一步加剧——重新分配颜色毫无头绪。

我们通过基于上下文无关的用途对颜色进行标记，最终解决了这一问题。这一调整也大大简化了为设计系统引入主题的过程。其实，颜色命名的方法有很多，各家公司也有自己的体系。例如，Asana 采用“[情感-智慧-突出-交互]”的命名结构，而 Material Design 推荐“[设计系统-类型-用途]”的模式。我的建议是，根据当前需求和未来拓展性，研究并采用最适合的语义化或全局命名方案。这不仅是解决问题的关键，也是让系统更高效的基础。

在开始构建我的第一个设计系统之前，我深入研究了业界关于建立基础的最佳实践。这时，我接触到布拉德·弗罗斯特（Brad Frost）提出的一种独特的模块化方法——原子设计（Atomic Design）。

这种方法的核心在于：将组件分解为更小、更独立的部分，使其在不破坏整体结构的前提下，可以随时替换、修改或组合。这种模块化设计方式不仅提升了设计的灵活性，还能在多个项目中实现组件的自动更新，显著提高效率。

原子设计的理念彻底改变了我的工作方式，我深刻感受到其带来的便捷与力量。对于任何正在构建设计系统的团队，我都强烈推荐采用这种方法。它不仅能够帮助我们快速搭建出稳固的设计基础，更为未来的扩展和改进提供了无限可能。

设计系统团队不应与其主要用户相互隔离。与产品团队的互动不该是单向的，而是一个持续的双向交流过程。随着产品的不断迭代和成熟，设计系统也需要同步更新。然而，当公司快速扩张时，来自多个团队的请求和反馈可能会让设计系统团队手忙脚乱。

最有效的应对策略是将设计系统开放给跨职能部门的贡献者，并赋予他们参与改进的权限。通过建立明确的贡献流程，团队可以在确保一致性的同时，规避破坏性更改的风险。提供清晰的指导材料和培训资源，让贡献者能够轻松融入流程，自信地为设计系统增添价值。

跨职能合作不仅为设计系统注入了多样化的视角，也为其与业务目标保持一致提供了保障。这样的协作方式，不仅推动了系统的完善，还让整个公司在快速增长中始终保持灵活和高效。

在大公司中，设计系统不仅是品牌与产品愿景的核心体现，也是构建整体品牌体验的重要工具。其影响范围远超软件产品本身，涵盖了品牌形象的方方面面。

为了确保设计系统的持久性，团队需要持续倾听利益相关者和主要用户的反馈。产品团队、市场营销、品牌推广、客户体验部门以及管理层的紧密协作，是推动设计系统不断发展的关键。同时，这种协作让每个相关方对系统更熟悉、更认同，从而提高采用率和应用效果。

要实现这一目标，首先需要明确列出所有利益相关者，并分析设计系统如何优化他们的工作流程。这种以人为本的方法，不仅能帮助打造一致的客户体验，还能让设计系统真正成为推动业务成功的核心工具。

设计系统的成功不仅仅依赖于创建，还在于如何推广和有效采纳。在这一过程中，培训材料的制定至关重要，它能帮助相关团队更好地理解并应用系统。这些材料可以通过视频、互动游戏、研讨会、课程等多种形式进行传递，选择何种方式取决于公司资源和能力。

关键是让利益相关者认识到设计系统带来的实际优势。如果他们不清楚如何将设计系统有效融入日常工作中，便很难全力使用，甚至可能破坏最终用户的体验。而如果利益相关者虽然采纳了设计系统，但没有掌握持续更新的应用方法，他们可能会自行调整系统，忽视设计规范，进而导致设计的一致性受到影响。

平等的沟通和机会是每个人的基本权利，因此无障碍性应当成为设计系统的核心原则。虽然在设计和开发过程中加入无障碍标准可能增加一定的复杂性，但它能显著提升产品的商业价值，满足更广泛用户群体的需求。那些将网页内容可访问性纳入设计原则的公司，不仅能提升所有用户的可访问性，还能提高产品的一致性，优化整体用户体验。通过对包容性的理解，设计师可以成为更加道德和富有同情心的专业人士，而这一点不一定需要成为无障碍领域的专家。

与其他产品类似，设计系统在初次推出后也需要经历不断优化和迭代的过程。产品设计师会提交错误报告或新需求，这些都需要设计系统团队的持续支持。随着公司业务的发展，产品团队的优先事项也会变化，设计系统需要快速响应这些新需求。在此过程中，创建清晰的培训材料和工作记录尤为重要，这样可以随时追溯改动历史，明确责任分工。为了避免系统倒退的风险，建议通过版本控制来统一管理错误修复和功能更新，确保必要时能够快速恢复到稳定版本。同时，帮助团队成员掌握使用和贡献设计系统的知识，是保持持续改进的关键。

在实际操作中，我曾多次对设计系统进行重新设计，甚至废除部分任务。为了避免浪费时间和资源，建议从一开始就设计模块化、可扩展且灵活的解决方案，以应对未来的变化需求。虽然设计系统看似是一系列线性的工作步骤，但本质上是一个不断循环的过程，涵盖持续发布、定期维护以及跨职能协作的动态演进。

文章图片来源于：https://medium.com

作者：Diana Wolosin

翻译：马克笔设计留学