emengweb
分离文件
设计系统中的文档被拆分和组织的方式是事物将如何在其中的第一个迹象。无论如何，以直观和模块化的组织为目标总是很方便的，因此只需快速浏览一下，我们就可以知道每个文档的内容以及它们之间的关系。
在设计系统
设计系统本质上是模块化的。其文件应具有一定的独立性，并利用可能组合的灵活性。
样式指南或基础：包含我们可以称为标记的所有内容：颜色样式、阴影、间距、大小、类型比例等。
UI Kit：包含输入框、对话框窗口、按钮等组件。这里的组件使用“样式指南”文档中的样式，没有其他孤立的样式。
模式：模式是完成任务的屏幕或流程的表示，可以在项目中重复。模式可以是单独的，例如带有表单的屏幕（然后您可以看到字段分隔，提交按钮的位置）；或者更长的时间，例如涉及多个步骤的搜索过程。模式大多是参考性的，不一定也应该是 Figma 或 Sketch 中的组件或符号。
在项目或功能中
每个项目或功能都可能需要一个或多个文档，具体取决于其复杂性以及它是使用自己的组件还是来自设计系统的组件（或两者的组合）。您所针对的不同屏幕尺寸也会影响排列和文件的分离。
考虑一个相对简单的案例，项目是为移动和桌面设计的，组件来自一个单独的库，结构可能如下所示：
Project ↳ Project (Desktop) ↳ Project (Mobile) ↳ Library
在单独的文档中拆分屏幕大小为您在内部组织这些文档提供了更多的自由和空间，我们将在后面看到。另一方面，如果项目使用自己的组件，而不是设计系统的一部分，则这些组件将包含在同一项目文件夹内的“库”文档中。
页面
页面用于分隔同一产品的不同部分，遵循以某种方式反映主导航或级别的结构。让我们假设我们有一个带有导航栏的应用程序。
文档中的页面将匹配相同的结构：
Home Search Profile Account Settings
在库和 UI 套件中
当文档具有组件（例如库或 UI 套件）时，还会有一个页面，其中将放置所有可编辑的组件和符号。这个想法是将它们分开，而不是分散在界面的不同屏幕和页面上。让我们看以下示例，它表示设计系统中的 UI Kit 文档：
Elements Components Patterns Editable components
框架和画板
如果页面和页面之间以一致的方式使用，页面内的框架和画板排列可以提供屏幕之间关系的概念。屏幕的放置（行和列）和分隔（垂直和水平）有助于建立组织系统。
垂直
垂直放置屏幕的不同状态。状态是指屏幕经过的临时时刻，并且通常是相同的。
- 最终状态：所有信息都已完成。这是理想的情况，其中信息的数量和复杂性是我们大部分时间所期望的。
- 部分状态：缺少需要完成的信息。发生这种情况的原因可能是用户没有上传所有必要的信息，或者目前无法显示某些信息。
- 空状态：没有信息可显示。这可能是当屏幕是最喜欢的项目列表，但用户尚未标记任何项目时。
- 加载状态：在加载过程中将显示的信息设计。一种习惯做法是使用一个“骨架”，它的基础结构可以提前展示。
- 错误状态：出现问题，因此无法显示信息。例如，想想当用户没有互联网连接时会发生什么。
并非所有屏幕都具有所有状态；这可以根据具体情况进行调整。即便如此，垂直分离屏幕我们可以从最终状态开始，然后包括下面的其他状态，在它们之间保持相同的分离。
水平
屏幕的水平排列方式代表从左到右的流动。例如，它们中的第一个可以是主屏幕（或第一级），然后是次要屏幕（或第二级）。它也可以是一个临时元素，如模态窗口。
框架或画板之间的分隔也会表明屏幕之间的关系：如果它们靠近，那么它们之间的概念联系也会更大。
图层
层的排列遵循允许匹配界面中元素顺序的组织。上层将用于也位于其他元素之上的元素。下一个，就在它的下方，用于设计中也位于下方的元素。依此类推，其余的垂直和顺序与从上到下的感觉相匹配。
当设计中的元素水平相邻时，最上层将对应最左边的元素，按照从左到右的阅读顺序。
例外
图层的排序方式也将决定一个元素在画布中显示在另一个元素的顶部。例如，如果您有一个对话框或模态窗口，则它必须位于图层列表中的第一个，因此它将覆盖界面的其余部分。这也是需要考虑的事情，当然，在遵循之前提到的订购系统时，这将是一个豁免。
组件
理想情况下，组件必须遵循在它们外部使用的相同配置和层顺序。当它们包含其他组件的嵌套实例时，这也适用。
灵活性
为了让组件的维护更容易管理，我们必须尽量减少我们拥有的组件总数。这就是为什么以灵活的方式构思组件的原因，例如，您可以通过隐藏或显示层来获得不同的结果。
让我们看一个实际的例子。“item”组件的左侧有一个头像。这个头像还包括一个图层，在图标上有一个透明的图像，所以当没有图像时可以看到这个图标。这有双重目的：模拟真实行为，并使组件更加通用。
基础组件
尝试最小化组件数量的策略是考虑其中几个将共享的基本结构，这意味着它们将具有共同点。从那里，创建了一个“基础”组件，它将用作公共基础。其他具有细微差异或变化的组件可以使用此组件作为基础，具有其嵌套实例，然后添加它们可能需要的附加层。
让我们看一个我们之前见过的“Item”组件的例子。如果我们想要一个没有填充的变体，而另一个有填充，最合乎逻辑的做法是首先创建没有填充的选项。
然后，您可以将其作为一个实例包含在将具有填充的组件内。这个带有填充的新组件将隐藏实例中的分隔线，然后将添加一个图层，这样它就可以左右移动。
像这样工作是优化维护的关键。只需更新基础组件，更改就会传播到使用此基础的其他变体。
什么应该是组件？
就设计而言，我们的想法始终是在设计文件中使用最少的不同组件。这将有助于减少我们为他们投入的维护时间；这就是为什么尽可能（并且有意义）使用嵌套符号等良好实践也会使我们受益的原因。
在任何情况下，减少维护都不会影响我们日常工作流程中所需组件的易用性和可发现性。然后，我们需要问自己：这应该是一个（Sketch 或 Figma）组件，还是我们可以只使用一个组？为了能够回答这个问题，我们需要问两个更基本的问题：
组件多久使用一次？如果仅在某些孤立的情况下使用它，则可能不需要从中创建组件。创建组件的最大好处是即时更改和更新传播，因此，组件使用得越多，就越有理由将其作为 Sketch 符号或 Figma 组件。
这只是为了文档吗？一个组件可能有不同的情况和状态。这些应该记录在某个地方，但并不总是它们应该是我们设计文档中的一个组件或符号。对于那些仅具有参考意义的案例（意思是，出于文档目的），一个组就足够了。对于“按下”状态的按钮，这可能是大多数情况下您不需要作为设计的一部分重复使用的情况。
解剖和特性
当组件从设计到代码时，它们通常具有可选属性和一些其他必需属性。然后前端人员将使用它在界面中呈现组件。这些属性可以决定组件是否有（或没有）图标、头像、宽度和高度，以及所有决定在代码级别提供的可配置选项。
如果我们想使用带有头像的“Item”组件，但有意使用带有填充和隐藏分隔线的变体，代码将如下所示：
<item padding no-divider>
<avatar type="icon" icon-name="user"></avatar>
<content title="Jane Copper"></content>
<content text="Berlin"></content>
<action icon-name="trash"></action>
</item>组件将提供的这些属性或属性应在设计阶段决定，涉及程序员并作为一个团队达成一致。这些定义也是对设计者的承诺，即不使用组件的变体，这些变体以后将无法通过开箱即用的组件获得。