【译】设计系统的5个支柱——设计系统系列

2019-06-092381

原文传送门:5 Pillars of a Design System

系统设计像是一群我们想要驯服的野兽。我们可以通过充分的准备,以及刻苦用功和坚持不懈,去把它做好。

第一部分设计系统的五大支柱 第二部分设计系统清单 第三部分设计系统资源和链接


今天围绕设计系统有很多不同的想法。要了解设计系统的来源,让我们简单回顾一下历史:首先,存在发布规则集的企业设计。然后JavaScript的出现使得构建丰富的互联网应用程序的速度更快,更便宜。为了跟上速度,设计师开始创建可以复制粘贴的预制符号,以快速创建屏幕并将其称为模式库。

如今,设计系统将风格指南*,用户* 体验模式功能组件整合到一个独立的产品中,并长期关注的方式进行维护

至少这是我对设计系统的定义。我们可以在网上找到其他人 - 最后,真正重要的是符合我们组织需求的人。

在构建设计系统时,有两种不同的方法。这是一种快节奏,有机的方式,我们只为一种产品构建所需的产品。或者是一种非常结构化的产品,可以提供更广泛的产品。

img

(顶部的特快列车速度很快,而底部的货运列车可以承受重载。)

两种方法(以及其间的每个阴影)都是有效的。我们选择哪一个取决于我们的需求。我们需要服务的产品越多,我们的系统就需要设计得越健壮。如果只有少数人会使用它,我们可以采取更快的方法。在本文中,我将介绍“货运列车”方法。如果我们决定采用“特快列车”路线,我们可以缩短或跳过此处显示的许多步骤。

您知道吗,IBM的碳设计系统在他们的核心团队中有12个人担任过各种角色,还有许多个为实际代码实现贡献了组件?你可能已经在网上看到那些制作精美的陈列柜,并渴望建立类似的东西。请记住,随着时间的推移,他们已经发展并拥有一支致力于开发的整个团队。如果我们刚开始,最好从小做起。一旦我们的设计系统启动并运行,我们的核心团队稳定,我们仍然可以加入更多人并扩展规模。一开始,核心团队不必是全职的,只要每个成员都有预定的时间,他们可以定期投入。

设计系统存在简化其他产品构建的可能性。设计系统本身是没有保证。

如果你今天只想学习设计系统的一件事,那么这个引用应该是它。我知道,这听起来很明显,但在设计系统时提醒自己是最重要的事情。它使我们保持谦虚。并帮助我们找到镀金设计系统之间的平衡,以破坏我们的内部设计师或建立一个强大的设计系统来处理棘手的东西。

正如德国人所说的那样,让我们用鱼类涂上黄油。为了建立一个成功的设计系统,我们需要下面显示的所有五个支柱。

img

支柱1 - 出售我们的设计系统

我们采取的第一步是找出已存在的内容,并了解我们的系统应该提供的期望。要了解这一点,我们会与我们的同事,用户(开发人员+设计人员)以及我们组织内的赞助商进行交流。如果我们的组织已经对设计系统的想法持开放态度,那么找到这些需求并讨论可能的解决方案可能是一个非常协作的过程。我听说过在最初的研究之后,买入已经如此强大以至于不再需要一个球场了。

一旦我们获得了这些基本见解,我们就对当前组件环境进行快速技术分析。在所有这些研究中,我们希望为我们做足够的研究,以便能够理解问题并提出解决方案。一旦我们获得资金支持,我们将花费更多时间进行深入研究。

对于我们的投入,我们需要准备我们的价值主张,我们的设计系统的范围以及我们实现目标所需的资源。说到资源,有几种方法可以为设计系统提供资金。理想情况下,我们会获得专门的预算和团队,使我们能够不断努力。特别是在设计系统的开头,通常情况并非如此。在这些情况下,我们可以尝试其他方式:(内部)开源我们的设计系统,产品团队参与或许可模型等等。

一旦我们制定了一份强有力的计划,就该把它推给我们的利益相关者。在这样做时,重要的是我们要了解它们的来源以及我们可以通过我们的设计系统解决的痛苦。虽然开发人员可能会担心失去灵活性和过度复杂的维护,但设计人员可能会怀疑他们会失去灵活性。在这里说实话并确定正确的期望是很重要的。设计系统提供了一些明显的优势,同时限制了当前过程的其他部分。与任何投球一样,我们越了解他们的预订并解决他们的问题,我们就越能得到我们所要求的。说到我们他们,我们越能创造共享所有权感,一旦我们的设计系统发布,就会越容易采用。

支柱2 - 研究我们的设计系统

我们震撼了它!资金是安全的,现在我们可以从设计多汁的组件开始,对吧?Nein,das ist falsch!;) - 在我们开始设计奇特的组件之前,我们想先做一些深入的研究。即使是最可爱的设计系统,如果我们不仔细地照顾它们,也有成长为难以管理的野兽的倾向。

在建立团队流程(Jira,Scrum等)之后,我们可以更深入地了解我们需要构建的内容。根据我们在上一阶段所付出的努力,我们希望与我们的产品团队一起投入更多。一旦我们彻底了解他们的流程和需求,我们就能够决定我们将提供什么。(提示:它可能根本不是设计系统)
如果我们不能依赖以前的用户体验研究,可用性测试和组件库存是我们了解用户方面的更多信息的首选方法。

每个设计系统都需要知道它存在的原因。(那么设计系统是否会存在生存危机?我是这么认为的。)我们希望围绕它创建一个大多数产品团队所拥有的共同愿景。我们还希望定义一个实际的可交付范围(设计库,即用型组件,更改日志,路线图......),并在某些时候给它起一个名字。每个怪物都需要一个名字,甚至可爱的名字。

支柱3 - 设计我们的设计系统

在开始新的设计系统时,我们希望从小规模开始。我们添加到组件中的每个功能都会增加代码,模式,文档中的复杂性,并使测试成倍增加。作为设计系统的产品所有者,我们需要在减少的组件和增强的功能之间找到最佳平衡。

在我们设计组件之前,我们想要定义我们的UX模式。我有一个完整的清单,可以看看我们的模式应涵盖哪些问题。

设计系统清单 我刚刚开始为客户创建另一个设计系统,我需要首先提出一些概念性问题...medium.com

设计第一个组件之前的最后一步是定义我们的标记(颜色,字体,空格,动画)。这些代币是我们将应用于组件的基础样式。此外,我们应该将令牌作为scss文件包含在最终包中,供我们的产品团队在其样式中引用。我们不需要从一开始就准备好所有令牌,但它有助于定义最重要的令牌。

img

设计系统的所有层都相互依赖

最后,我们能够设计出我们的第一个组件。我们可以直接在HTML / CSS中构建它,或者在设计工具中绘制它。就个人而言,我喜欢从一个简单的组件开始,如按钮,并定义所有需要的变体(主要,次要,鬼)和状态(默认,悬停,活动,禁用)。这使我们首先熟悉整个设计系统。接下来,我将采用最嵌套/复杂的组件,这通常恰好是一张卡片。通过这样做,我可以对我们的概念进行压力测试,并确保它的稳健性和灵活性。

计算机科学中只有两件难事:缓存失效和命名事物。 - 菲尔卡尔顿

在设计组件时,最重要的事情之一是使组件,变体和状态的命名从符号到最终代码保持一致。一旦每个学科使用相同的名称,对话就会变得容易多了。

大多数设计系统的一个优点是我们牺牲了完美的用户体验流程以实现标准化和更快的实施时间。作为用户体验设计师,我们对自己造成了这些限制。像素完美微互动的日子已经一去不复返,以获得我们关键指标的最后一部分。必须有一个非常有效的商业案例,不使用我们现有的组件或添加其他功能。为了保持产品团队的可信度,对我们自己的UX设计师提出的功能要求尤为重要。如果我们在第一次启动时解雇我们的设计系统规则,为什么其他人会妥协呢?这样做的好处在于,通过严格控制自己,它可以让我们的设计人员自由地评估潜在的程序性用户体验问题。一旦可用性测试浮出一个实际问题,我们仍然可以自由地深入研究并创建自定义组件来修复这个特定的用例。

支柱4 - 建立我们的设计系统

在为我们的设计系统实现组件时,通常只编写一次代码(DRY原则)。另一方面,我们不希望所有变体和状态都被塞入一个主组件中。通过每个附加功能,组件内的可能组合会增加,并且可能会出现破坏它的边缘情况。这反过来又使组件成为测试的噩梦。在某些时候,为不同的变体构建不同的组件会更容易。由我们的开发人员和他们的用户体验设计师决定分割组件的正确时机。

在为多个产品构建设计系统时,质量不是一种选择,它是我们唯一的选择。我们希望我们的产品团队信任我们足够使用我们的设计系统作为他们日常工作的一个组成部分。如果他们选择这样做,他们会严重依赖我们的系统来正常运作。如果我们弄错了错误的组件并破坏了他们的产品,我们可能会遇到大麻烦。因此,我们总是希望在每次发布之前进行严格的测试。这与构建较少组件和限制其功能的口号紧密相关。拥有自动构建和测试管道也没错。

在这个时间点,处理公共文档可能是个好主意。目前,大多数文档框架都需要三个部分:

  1. 实际的代码
  2. 我们组件的互动演示(故事书
  3. 一个文档系统,用于添加我们的解释
    并嵌入交互式演示(零高度

img

实际的代码和文档是实际的可交付成果,而交互式演示是增强文档的一种方式。

我们的文档至少应包括令牌,组件,愿景,模式,更改日志和联系页面。

支柱5 - 维护我们的设计系统

如今,大多数设计系统都以npm包(或类似的东西)的形式发布,并包含在最终产品的构建脚本中。在大多数情况下,我们必须提供一些基础设施以及可以发布包裹的设计系统。这些要求通常已经定义,我们可以与我们的产品团队核实,了解他们的偏好。

更新任何组件时要记住的一点是,大多数方面都是公共API。不仅是明显的部分,比如代码中传递的参数,还有视觉外观。产品团队花费大量时间在可用的屏幕区域内完善其UI。将Button的填充增加一个像素可能会破坏精细调整的表单并使应用程序无法使用。使按钮背景更暗可能导致难以辨认的行动呼叫。

我们也应该接受我们的设计系统不适合所有应用程序,并且它将以我们并不打算的创造性方式使用。通过支持一定程度的自由和非正统用途,我们将营造一个创造性的环境,并鼓励我们的产品团队寻找创新的解决方案。一旦我们发现了我们认为不符合UX原则的实施,我们仍然可以以开放的,协作的方式接近团队。这是我们更多地了解他们的需求并教育他们为什么我们的原则存在的机会。这将使产品团队能够独立应用它们,并在未来构建更好的产品 - 反过来将我们放到设计而不是治理。

使用我们设计系统的产品越多,需要根据特定用例调整的组件越多。与简单的B2C应用程序相比,业务应用程序对表的要求可能大不相同。为了解决这个问题,可以为我们的设计系统创建插件

img

我们将设计系统分解为子包。我们的产品团队现在可以选择所需的插件来创建量身定制的设计系统。

最后的笔记

虽然设计系统的最初创建可以按时间顺序通过这些支柱流动,但一旦我们生活,我们经常发现自己同时在所有五个方面都在工作。当我们的设计师研究和设计新组件以及我们的开发人员代码并维护其他组件时,产品所有者可能会获得更多资金。

分享
点赞1
打赏
上一篇:代理工具Fiddler -调试与替换接口状态
下一篇:小程序采坑总结