了解设计系统和模式

虽然它看起来像是一种处理数字工作流程的新方法，但设计系统的概念对创意产业来说并不是“新”的。 任何设计系统的核心都是一种设计模式语言，可以解决设计师可能面临的常见问题。

模式语言的想法起源于 40 多年前的建筑和城市设计，几乎可以应用于任何设计学科。

像 Material Design 这样的设计系统是一个流行的话题，但几十年来，系统化的设计方法一直是杂志出版商不可或缺的一部分。 在翻阅任何主要杂志的页面时，很容易看到每个部分都被独特地定义为具有通用布局、字体、颜色等的模板。

用于页面部分的设计模式允许文本和图像以一种补充出版物的创造性愿景的方式一致且有效地排列。

在查看竞争对手的杂志时，很容易看出其中一本的设计语言与另一本相比如何。

如果他们还没有，来自众多行业的设计师将很快将设计语言和模板整合到他们的工作流程中。 对于数字产品设计师来说，这个话题正在发展，许多人第一次从复杂系统中的模式库中学习设计（甚至帮助定义它们）。

将软件设计模式与前端代码库对齐时会增加复杂性，这会使学习设计语言感到不知所措。

设计语言是整体的

与任何语言一样，设计语言是错综复杂的，并且包含最初可能看起来令人困惑的细微差别。 这就是为什么将设计语言视为“由许多可能相互交互的组件组成”的复杂系统会有所帮助。

要理解一个复杂的系统，从整体上考虑设计语言很重要：

• 从鸟瞰设计如何影响品牌或业务开始。
• 然后，与跨职能团队和其他设计师一起考虑设计的作用。
• 最后，考虑设计在特定时刻如何影响产品和用户。

这种整体视角强调了对设计工作流程的系统化思考方式，它允许在解决特定问题时轻松应用设计语言。

在实践中，设计语言是一种资源，用于帮助减少冗余并提高设计师处理常见设计问题的方式的连续性。 例如，产品设计师面临的一个常见问题是， “我需要发出号召性用语，让用户点击。”

这是以前已经解决的问题，因此设计语言不会重新发明轮子（或按钮），而是定义一个可重复使用的按钮“设计模式”，其中包含预设属性，例如颜色和形状，以及最佳实践指南。

数字产品设计语言通常是一种跨职能资源，旨在提高团队的工作流程效率和协作。

在某些情况下，该语言会扩展到一个实时模式库，该库直接连接到前端代码库和模式的度量分析。 这种具有各种依赖关系的复杂系统使得解决问题的整体方法非常必要。

学习设计语言最棒的地方在于，团队成员通常对用于定义产品的界面和交互充满热情。 学习一门新语言通常是一项挑战，但它也可以是一种凝聚团队的身临其境的体验！

“设计”系统思维的常见问题

流利的设计语言将通过布道来确保系统的质量——这可能包括：

• 培训新设计师；
• 指导初级员工和管理承包商； 要么
• 直接与工程师合作，在发布前完善产品前端。

通过这些协作努力，设计人员将能够确保系统的指导方针能够根据需要得到维护或改进。

无论职责是什么，关于设计系统的一些常见问题都认为设计师可能要对此负责：

在设计系统中进行设计时应该考虑什么？

根据设计系统的复杂性，重要的是从对要解决的问题采取综合方法开始。 考虑之前的按钮示例。

如果颜色预设为# 1f9efc并且设计者在没有先咨询使用相同图案库的其他设计者的情况下将其设置为 #1b3e9b，这可能会导致系统错误。

在设计系统中工作时，请考虑所解决的问题将如何影响整个产品开发周期。 在许多情况下，不会也不应该有太大影响，因为模式库已经过验证。

如果要解决的问题对设计系统来说是新问题，则可能有机会发展模式库并帮助定义新的设计模式。

当系统不断发展时，它对团队的工作流程来说是新的。 这里需要灵活性，因为设计模式会随着时间的推移而迭代。 然而，虽然更改按钮的颜色很容易，但必须始终考虑更大的系统复杂性。

为此，定义用于组织设计系统和模式库的分类是很有帮助的。 所使用的术语应该易于跨职能理解。

单击以查看全尺寸图像。

通过将设计工件分组到普遍理解的主题中，模式库允许系统跨团队工作流进行操作，并以设计模式被谈论的方式进行交流。

我如何知道何时需要在设计系统中打破模式或创建新模式？

是否需要打破或创建新的设计模式通常取决于系统的成熟度。 当设计系统不断发展时，模式经常发生变化。 随着系统的建立，应该有一个变更请求流程来帮助确保连续性和质量。

系统的复杂性也是需要考虑的重要因素。 如果更改模式会影响其他设计人员和团队，则该过程可能需要更长的时间来实现，并且通常需要更深层次的努力或资源（例如，更新设计语言指南、模式库或前端代码库）。

通常，模式库并不意味着僵化。 把它想象成一个可以解决问题和完成任务的工具箱。 如果所有在模式库范围内的设计尝试都没有实现项目目标，直觉可能会导致寻找新工具——或者可能会改变现有模式。

看看下面的图表。 一般的经验法则是，作为基本品牌构建块的身份和元素很少改变，因为它们有助于定义品牌和设计工件。

大多数大型组织都有针对品牌相关元素的单独样式指南，尤其是徽标、颜色和字体，它们不会经常更改。 对于按钮等元素，这可能会或可能不会根据设计语言的演变进行迭代，但由于它们与产品的各个方面都有联系，因此它们的更改频率也较低。

设计模式更改或新模式通常出现在组件和交互级别，因为它们定义了用户流程和功能集。 在产品路线图中定义新的用户流程是很常见的，尤其是在推出功能时。

新的设计模式将具有类似于库中已经定义的模式的属性（例如字体和颜色），但可能需要除设计语言之外的界面更新或交互状态。

与设计师合作的产品经理或产品负责人将为符合业务目标的新功能提供要求。 在决定打破或创建新的设计模式时，请记住复杂系统的理论，并确保解决方案是一个共同的决定。

在考虑如何打破或更改设计模式时，需要考虑以下几个步骤：

1. 确保质量控制和连续性

   请记住，质量是一个共同的产品目标。 每个人都有责任确保设计系统正常工作。

   始终采用整体方法，并考虑打破模式或创建新模式的潜在影响。

   问你自己：

   • 打破模式是解决我的问题的唯一方法吗？
   • 如果我打破这种模式，其他团队会受到怎样的影响？
   • 如果我打破这种模式，模式库会发生什么？

2. 与合作者沟通

   与设计师和跨职能团队成员交谈，看看其他人是否有同样的限制。 了解有关平台要求的所有信息，以及建议的模式如何在整个产品系列中发挥作用。

   问你自己：

   • 还有谁在这个产品或平台上工作过？
   • 我正在设计的平台的最佳实践是什么？
   • 我可以与谁交谈以帮助我做出决定和提出建议？

3. 了解前端功能

   了解前端实现的可能性。 如果更改只是对 HTML/CSS/JavaScript 属性的更新，通常不需要打破模式或创建全新的东西。

   相反，它可能是对设计语言指南的简单更新。 作为设计师，与前端密切合作并可能找到每周或每天协作的方法非常重要。

   问你自己：

   • 前端团队是否参与了这次设计更新？
   • 我正在考虑的更改是前端更新吗？
   • 最佳实践指南中是否缺少某些内容？

4. 验证决定

   如果确定需要新模式，则应与合作者和最终用户一起验证该决定并与业务目标保持一致。

   如果前端组件与指标相关联，则快速 A/B 测试将有助于验证。 如果没有，进行可用性测试会很有效。

   问你自己：

   • 我们的团队是否有验证新设计模式的变更请求流程？
   • 我需要做什么来验证我的决定？
   • 这个决定是创建一个新的用户流，还是一个附加功能？

同样的工作，不同的心态

在系统内进行设计时，产品设计师采用决策所需的大局思维至关重要。 复杂系统和系统思维的原理将帮助设计师在他们的职业生涯中成长。 从模式库构建的过程也是如此。

这些方法对于开始一种新的设计语言或为现有的设计语言做出贡献很有用，因为一旦思维定势到位，系统化的方法就会变得“系统化”。

知道其他行业和设计学科多年来一直使用类似的方法来简化工作流程，这为产品设计师提供了最佳实践的绝佳参考点。

归根结底，在系统内进行设计不会完全改变工作的完成方式。 当然，将会有一些新工具用于连接和管理复杂性，但最终，这是向整体思维方式的转变，这将真正有助于改善工作流程。

• • •

进一步阅读 Toptal 设计博客：

• 如何创建草图样式指南、库和 UI 工具包
• 设计问题陈述——它们是什么以及如何构建它们
• 发挥你的灵感——情绪板指南
• 协同设计——成功的企业产品设计指南
• 设计未来：等待我们的工具和产品