从屏幕反向应用原子设计的范围优先方法

你不必总是从原子开始构建。有时候，你需要发现 它们。

Atomic Design 是现代设计系统的核心心智模型之一。它为我们提供了一种通用语言，将界面描述为一种层级结构：原子、分子、组织、模板和 页面。

Brad Frost 从一开始就指出，原子设计不是一个线性过程，而是一种允许我们同时兼顾整体与部分的心智模型。这五个层级并不是第一步到第五步的 顺序。

从模板到原子。

然而在实践中，大多数团队只朝一个方向应用该模型。当他们旨在构建组件库时尤其如此：他们定义最小的可复用部分，并从中组装更大的块。然后开始在 屏幕中使用它们。

这种习惯非常普遍，以至于许多人将其误认为是方法论本身。

产品工作通常从另一端开始——从用户体验出发。当我们查看一个屏幕时，第一个问题不是“这里使用了哪些组件”，而是“用户在这里需要做什么？”他们将如何搜索、过滤、比较、选择、编辑等等？

这是进入 Atomic Design 模型的另一个切入点。我们可以说这是一种“范围优先”的方法。

以组件为先的方法可能会掩盖实际的结构

“以组件为先”的方法通常始于清点：

• 这是一个 按钮
• 这是一个 输入框
• 这是一个 徽章
• 这是一个 表格

有两种众所周知的方法能很好地处理这一点：Brad Frost 的 Interface Inventory 和 Nathan Curtis 的 Component Cut-Up Workshop。两者对于其预期目的都非常出色：描述现有界面并启动组件库的工作。

• Interface Inventory
• The Component Cut-Up Workshop

但它们回答的是一个具体问题：“屏幕上有什么？”我们需要自己思考其余部分：“为什么某物在那里以及它与什么相关联”。

让我们以一个带有数据表的典型管理屏幕作为 示例。

这里的用户清单看起来相当 不错：

• 页面标题
• 主要操作
• 标签导航
• 搜索输入框
• 过滤输入框
• 排序按钮
• 分页
• 工具提示
• 等等。

幕后剩下的是所有这些是如何相互关联的：

• 状态徽章与单个 行相关联。
• 排序会重新排列数据集中的所有行。即使控件本身位于单个列 标题内。
• 搜索和过滤器改变屏幕上显示的记录 全部。
• 像 Add people 这样的主要操作影响整个 页面。
• 标签可以完全替换内容区域的内容。

元素彼此之间的邻近性在所有这些中都是一个糟糕的指导。排序按钮是最明显的例子：它位于列标题中但影响整个表格。元素不是通过位置链接，而是通过其行为范围链接。

按范围 思考

当分解屏幕时，我们可以从每个操作的范围开始——即当用户触发该操作时会发生变化的数据集或界面部分。

对于上面的管理 屏幕：

这不是一个完整的分解，但它已经突出了几个重要的点。

第一：左列中的每一行都回答了同一个问题——什么在变化？

你可能会忍不住添加诸如“导航”或“表格标题”之类的类别，但这些描述的是控件是什么或其位置。这是另一个维度，混合这两个维度正是导致该练习悄悄退化为清单式分解的原因。

第二：工具提示和徽章完全没有作用域。它们不会改变任何东西。将它们包含在表格中是为了表明某些东西不是控件——只是为了完善整体图景。

这种分解并非普遍适用。在不同的屏幕或不同的产品中，作用域会有所不同。

被沿用的不是列表，而是过程：

• 从用户可以做什么以及他们可以与之交互的内容开始。
• 确定每个具体的用户操作会影响什么。
• 决定哪一层级应该拥有逻辑。

这样，即使在我们开始创建组件之前，也能获得屏幕的结构模型。

逻辑所在之处

当我们设计组件时，我们会考虑库：它的多功能性、独立性以及在无法预测的上下文中的适用性。

当我们设计产品时，我们会考虑业务逻辑——各部分必须结合在一起以形成连贯的用户体验。

搜索、过滤和分页清晰地展示了这种张力。作为库组件，它们可以以不同的组合出现在不同的屏幕上，因此保持它们的独立性是有意义的。

但在这个管理界面中，它们管理着一个共享数据集：

• 更改过滤器可能会将分页重置为第一页。
• 没有匹配结果的搜索查询会清空表格，从而使分页变得不必要。

在为单个组件编写文档时，不可能列出所有此类场景，而且组件本身也不应知晓这些场景。一旦过滤器组件感知到分页组件的存在，它就失去了可复用性，并开始承载单一特定用例的业务逻辑。

但必须有某种东西来管理这些连接。根据我的经验，在模板层级处理这一点最为方便。

关于模板角色的略微不同的观点

在 Atomic Design 中，模板是页面级对象，它们在布局中定位组件并定义内容结构：它们关乎结构，而非状态。

简单来说，模板充当一个“笨”（展示型）组件，它只知道自己的外观以及如何接收来自外部的数据。

“智能组件”（容器组件）能够管理数据、状态和行为。它们通常构建为围绕“笨”（展示型）组件的包装器。

这大致就是我对模板的建议做法。各个组件保持“展示型”：表格知道如何渲染行，过滤器知道如何返回值，分页知道如何显示页码——并且它们都是独立的且互不知晓。模板是将它们统一起来并持有它们协同工作逻辑的包装器。

对于数据密集型的产品屏幕，模板层级不仅是布局的自然归属地，也是以下内容的自然归属地：

• 屏幕上有哪些区域以及它们位于何处。
• 区域之间如何连接。
• 在它们之间流动的共享状态。
• 属于屏幕上下文而非任何特定组件的规则。

我经常看到产品团队中的开发人员，在需要复用同一组功能（如筛选器、搜索、表格和分页）并将它们作为一个整体单元时，会围绕多个库组件创建封装层。

当然，这类逻辑可以在 Storybook 中作为故事进行文档化，但开发人员通常更倾向于将其保留为现成的模块，而不是每次从头重建。

有时这些封装层会自发出现，最终与按钮和其他“展示型”组件一起放在 /components 目录中。然而，最好还是将此类模板分开保存。

我需要澄清一点：我并不是说每个模板都必须包含逻辑，也不是说任何逻辑都应被拖入模板。判断标准与关于范围的问题相同：

• 如果一条规则描述了区域之间的关系，并且在各个屏幕间重复出现（例如，“更改筛选条件会将分页重置为第一页”），那么它属于模板。
• 如果一条规则仅适用于特定屏幕和特定数据（例如，“禁用的用户无法更改其角色”），那它属于页面级别，不应触及模板。

一个知道太多的模板就不再可复用了。

我认为这更多是对 Atomic Design 模板逻辑的延伸，而非矛盾。这也是该方法与 Component Cut-Up 之间最清晰的区别：

• Cut-up 帮助团队识别反复出现的视觉元素，并将其转化为潜在组件列表。
• Scope-first 分析有助于理解“用户在屏幕上可以做什么，他们的操作影响什么，以及哪个层级应为此负责”。

相同的模板，不同的现实

一个好的模板是一种可在不同产品上下文中工作的可复用结构。例如，同一个模板可用于管理成员、项目、发票及其他页面。

区域保持不变：

• 页面标题
• 主要操作区域
• 导航
• 工具栏
• 内容区域

变化的是其中的元素：结构相同，内容和行为不同。

正是在这一刻，设计系统不再仅仅是一组组件，而开始描述产品模式。这正是大多数产品团队所需要的。

使用真实内容检查拆分

在页面级别，我们用实际内容填充模板。在此阶段，我们需要对系统和布局进行压力测试，以确保结构能够处理可能未为其设计的内容。不仅针对“正常路径”，还要考虑以下情况：

• 没有数据时。例如，搜索查询返回零结果时。
• 数据加载期间。
• 在小屏幕上打开页面时。
• 文本长度远超布局预期时。

这只是某个特定屏幕的几个场景。其中一些是典型的，例如空状态；另一些可能是特定的。这与 QA 处理边缘案例的方式类似：找出问题在哪里崩溃。

区别在于“崩溃”的含义。它并不总是设计问题。通常，这表明拆分不完整：某种状态或其部分没有负责人，或者未为该区域定义其在为空时的规则。

这种方法何时有用？

首先，当你需要为现有产品设计设计系统时。当产品已经存在时，问题不是“我们如何从零开始创建组件？”而是“我们如何理解并系统化已有的 内容？”

其次，当关于组件边界的讨论出现分歧时。范围优先的拆解方式为双方提供了一种更中立的讨论所有权的方式。团队可以讨论某个元素影响什么以及哪个层级应拥有该行为，而不是争论它是否“看起来像”一个组件。

第三，当产品中有许多相似的屏幕时。管理面板、仪表板、CRM 工具、设置页面、市场平台、金融工具和内部平台通常以不同的数据重复相同的模式。范围优先方法有助于澄清哪些部分是真正可复用的，哪些只是视觉上 相似。

最后——文档。用它们的范围来描述产品模式要容易得多——页面操作、对象操作、状态。而不是通过扁平的组件列表。这更接近用户感知 屏幕的方式。

这种方法什么时候不起 作用？

这种方法并非万能，根据我的经验，我可以指出至少两种搞砸它的 方式。

第一种是调整逻辑和组件以适应单个屏幕。这种诱惑是可以理解的：如果范围模型完美契合，你可能想围绕它构建一个库。但屏幕是一个特定的用例，而组件应该存活得更久。范围指示了逻辑应驻留的层级。它对组件本身的通用性只字未提。我在产品团队在压力下工作时经常遇到这种情况，设计师和开发人员试图将每个新模式保存为组件或设计系统模板。

第二种是拆解已经清晰的内容。在着陆页、设置表单或登录屏幕上，范围映射只占一行，但分析起来仍然可能耗时很长。整个方法基于两点：屏幕密度和区域之间的整体流程。如果两者都不存在，传统的清单拆分将更快，并产生完全相同的 结果。

结论

Atomic Design（原子设计）是一种多功能模型，使得构建组件库相当容易。然而，团队经常试图用它从小部件构建界面，过于字面地理解该方法的“原子性”。

日常产品工作往往从另一端开始：复杂的屏幕已经存在，需要被理解。本文表明 Atomic Design 在这方面也有帮助。此外，结果不仅是更精确的组件分解，也是对屏幕背后产品模式的更清晰 理解。

对于产品团队来说，这通常是最重要 的。

感谢阅读！在评论中写下你对这个主题的看法。

让我们保持联系！在 LinkedIn 上与我建立联系，并在 Medium 上关注我以获取更多与设计相关的内容。