emengweb
简短介绍
记录设计的主要原因是让团队中的每个人保持一致，我的意思不仅仅是设计师。通过拥有一个主要参考站点，其中列出了所有设计规范、实践和工作流程，您可以将其用作核心咨询，避免重复概念或将它们分散在不同的地方。
文档超越了界面本身。围绕设计过程有很多事情也是交流所必需的：从决策背后的基本原理到行为，从日常实践到一般工作流程。目前，本出版物的范围将涵盖与产品视觉方面相关的所有内容。
在您的设计文件中记录
现在比以前更常见的是找到帮助将您的设计软件与文档可以存在的其他网站连接起来的工具。他们中的大多数通过插件工作，这些插件可以让您将设计保持在一个中心位置，然后通过第三方软件进行同步。我们稍后会讨论这个（或者你可以直接跳到文档工具部分。）
不幸的是，设计工具和文档工具的成熟度远远落后于我们现在想要的。出于这个原因，正如我们将在下面看到的，我仍然更喜欢将这些工具与文件内文档结合使用。这样做的好处是可以根据您想要的粒度级别对设计的通信进行微调，但需要一些手动工作以使其保持最新状态。
在接下来的几节中，我们将看到在记录设计的主要部分时要记住的内容。
颜色
为了记录颜色，我们需要遵循一系列步骤： 说明它们的解剖结构（意味着形成颜色资产的不同部分）；定义它们将如何分类或划分；最后，它们之间的关系是什么，请记住，相同的颜色值可以在界面中具有不同的应用程序。
解剖学
颜色非常简单，因此要定义它，我们只需要一个名称和一个值，以及两者的视觉表示。要在我们的文档文件中执行此操作，创建一个具有通用结构的符号或组件以稍后基于该结构记录调色板是有用的。
这是一个非常简单的示例，但将复制此通用结构以记录界面中的每种颜色。还有一点要记住：颜色通常是比例尺的一部分，它们在上面有一个位置。
只有一种原色是很少见的。相反，我们更有可能将它的一些变体应用于不同的情况，例如悬停在按钮上时。所有这些都需要定义和记录，我们将在接下来看到。
定义
为了直观地解释颜色结构或分类的工作原理，除了将它们创建为变量或样式之外，您还可以将它们排列在样式指南内的特定页面上。
我们刚刚看到的原色可能是“主要”类别的一部分，在那里我们将有原色和副色。除此之外，一个项目通常会在调色板中包含一些其他的分区。
Main Neutrals Backgrounds Opacities Icons Texts
我们将使用 Neutral 类别来定义它包含的不同值的示例。
应用
正常的事情是在其他地方重用这些颜色中的一些，例如文本、图标或背景。出于与我们上面评论的相同的原因，我们将再次创建样式，即使它们重用该值，以使它们更容易在我们的样式列表中找到。
在设计文档时，我们可以澄清一些值不是不同的，而是重用一些已经定义的值。
Sketch和 Figma等工具允许将颜色存储在独立的样式和变量中（这意味着您可以单独保存颜色值，而无需其他视觉属性。）
理想情况下，我们应该能够在我们的设计工具中嵌套颜色定义，以便两种颜色可以共享相同的值，并在它在一个中心位置发生变化时进行更新。这种行为类似于我们在代码中所做的行为。
$colour-neutral-20: #cdcdcd; $colour-neutral-60: #686868; $colour-neutral-80: #282828; $colour-icon-soft: $colour-neutral-20; $colour-icon-medium: $colour-neutral-60; $colour-icon-strong: $colour-neutral-80;
目前，这种级别的嵌套在我们的设计工具中是不可能的，我们将不得不依靠文档来清楚地传达如何在我们的产品中使用颜色。
文本
定义文本样式可能很复杂，因为它涉及共同作用的属性组合，例如大小、颜色、系列或重量。这里的挑战是以模块化方式记录这一点，因此您可以在一页中获得清晰的地图和这些组合如何协同工作的概述。
尺寸
大小通常基于类型比例。将所有东西放在一个地方将帮助我们了解我们拥有的不同尺寸，以保持它们整洁并减少选择的总量。我们将牢记在整个项目中用于大小的命名约定，我们还将包括诸如以像素和 REM 为单位的度量等值。
重量
根据我们选择的字体，我们可以使用不同的权重。遵循尽可能少的不同选项的相同原则，我们可以将它们放在一个页面中，以可视化我们将在我们的设计中使用的那些。
把所有东西放在一起
在我们选择的设计工具中，我们需要将大小、颜色、字体系列和粗细组合在一起，为界面中的每个主要和最常见的应用程序创建独特的样式。（如果使用 Sketch，最好不要创建几种具有不同对齐方式的样式，只创建最常见的一种——即通常左对齐。）
对于每种情况，我们都可以在样式下方添加一些信息，以更清楚地解释所使用的“令牌”，例如大小、重量、行高等。
文本样式通常也分为“桌面”和“移动”。如果我们只保留一个尺寸，标题在小屏幕上往往看起来非常大，因此需要调整它们。记住我们先前定义的大小规模相适应，我们可以用一个步骤的规模少手机和平板电脑。
除了某些点之外，没有必要拥有单独的样式，因此我们保留了一个跨平台共享的“通用”部分。这将帮助我们最大限度地减少不同风格的数量，拥有这么多风格几乎没有区别的风格并不值得。
还有更多的东西。还有我们用于链接的样式——这涉及不同的状态，例如当您悬停文本时，或者链接被禁用时。我们将在接下来的部分中看到其中的一些内容，但现在，您只需要知道，最好只创建有可能在界面中经常使用的样式，而不一定是所有样式。
组件
即使我们的 Sketch 符号或 Figma 组件相对简单，也有必要记录组件并记住它们可能具有的不同约束、行为和结果。
解剖学
我们将首先记录组件的解剖结构，它识别出它的不同部分——特别是那些稍后可以通过利用它们的属性进行定制的部分。
假设我们有一个非常常见的组件，即“卡片”，同时在其中包含一些其他较小的组件。组件文档的第一部分主要旨在可视化其一般结构的概述。
通用词汇表
根据上下文及其目的，组件可以具有不同的行为、内容和布局。这（您可能已经猜到）也必须记录在案。
像 Figma 这样的一些工具具有称为“变体”的功能，允许拆分一个组件并将其与其他几个视觉相关的组件组合在一起。在我们的例子中，我们将更进一步，我们将使用更高级别的粒度，这将允许我们记录定义其Types、Variants、Cases和States 的组件。我们将在一秒钟内看到每一个的含义。
尽管并非所有组件都具有所有定义，但对于所有组件都应保留此划分。例如，输入字段可能只有一种类型，而对话框没有变体。因此，如果不是完全必要，则无需强制执行此操作——这必须根据具体情况和组件来决定。
类型
类型是组件可以具有的最高级别差异。它通常是指布局的重大变化，以不同的方式呈现组件，同时仍然共享相同的核心概念和功能。保持我们上面使用的卡片的例子，我们可以说它有两种不同的类型：默认的一种，我们已经看到了，另一种看起来更像是信息较少的预览图像。
变体
接下来，我们将有变体：组件在视觉层面的小变化，而不是行为。布局基本保持不变，但会根据特定场景的需要进行调整。例如，我们可以使用大多数时候使用的默认 Card，但也可以使用Variant来保留主要结构并删除页脚，如下图所示。
案例
案例是指组件可能存在的不同场景。到目前为止，我们已经使用了一个充满内容的卡片，但我们还需要定义它在没有图像的情况下的外观，例如。所以，沿着一个内容丰富的理想场景，我们也应该设计缺失部分的组件，并像一个案例一样呈现它。
状态
最后，各国通常由用户交互触发的，他们通常是相同的：向上，悬停，重点和向下。但是，可能会发生其中一些可能因组件而异。
就设计文件而言，没有必要将那些在我们日常工作中不会经常使用的状态（例如悬停状态）创建为符号或组件。这些确实需要在某处记录，但它们不需要作为 Sketch 符号或 Figma 组件作为我们文件的一部分。
在完成本节之前，您必须意识到这不是一个严格的分类。例如，有时决定设计定义应该是一个案例还是一个变体可能会很棘手。理想情况下，您必须在某处记录此设计决策，而不必过多关心它属于哪个类别。
记录属性
组件由属性构成，在代码中使用它们时可以更改，也不能更改。例如，一个对话框可以有一个标题、一个正文和一个动作按钮，其中的文本值会根据情况而改变。其他所有内容（背景颜色、边距和分色）都将保持不变。
那么，每次我们有一个对话时，设计一个实现对话是否有意义？我说不，它没有。有一种方法可以避免对具有可以修改的预定义属性的组件进行重复设计，并且正在记录它们。
使用我们产品文档中的一个简单表格，我们可以为每个对话框指明它支持的预定义属性的值。这样，我们就可以避免每次需要时都必须设计对话框。相反，我们可以使用表格，它更易于维护，特别适合像我这样的懒惰设计师。
对于可以动态变化的文本内容，您可以同意如何表示变量，因此您可以在文本的不同部分使用它们。例如，您可以定义如何包含用户名，如下例所示。
文档工具
我相信用于设计的文档工具仍处于早期阶段。可能随着设计系统的兴起以及随之而来的 DesignOps 和设计开发协作的改进，我们会发现更多旨在缩短这两个部分之间差距的工具。
您之前可能听说过Zeplin，这是一个特别适用于设计移交（例如共享间距、大小、颜色和资源下载）的工具。我不得不提一下，Sketch 和 Figma 都具有与此工具重叠的检查和评论功能，因此您只需单独使用您的设计软件即可。
一个有趣的文档选项是Zeroheight。它允许您从 Sketch 或 Figma 同步您的设计，并且非常容易地提取样式，因此您可以使用它们来记录您的样式指南。不仅如此，您还可以上传任何画板或框架，以及符号和组件来记录它们。您甚至可以添加静态页面以获得更完整的 wiki。它还具有集成（如与Storybook 的集成），允许在同一位置拥有设计和代码示例。
最后，Specify在成为一个设计 API 的过程中取得了有趣的进展，该 API 将帮助您保持设计和代码同步，拥有一个中央枢纽，可以存储设计资产和令牌。值得关注其路线图。
最后一句话：有很多工具，你使用哪一个都没有关系。它甚至可以是 Notion、Google Docs 或任何您喜欢的东西。这里的重要部分是使文档对所有团队成员（甚至非设计人员）都是可访问的、最新的和友好的。