设计组件是具有欺骗性的。在前端，它们需要具备灵活性和易用性。但在后端，这可能导致一团复杂的混乱：系统设计师需要考虑产品使用情况中的每一个可预见的变体，同时又不能构建过于宽泛以至于不再直观的东西。那么，当你为一个组件拥有约一千个不同的变体时会发生什么呢？
这就是我们在构建Faire的模态组件时所面临的挑战。对于那些不熟悉的人来说，模态是一种在网页上显示的浮动窗口，通常用于显示额外的信息或需要用户输入的内容。模态组件在我们的产品中的使用非常广泛，因此我们需要一种能够灵活适应各种情况的解决方案。
在开始之前，我们首先考虑了模态组件的一些关键要素。我们想要一个通用的组件，可以用于各种用例，包括显示内容、收集用户输入、提供反馈等。同时，我们希望组件能够具备良好的可访问性，并且在不同设备和屏幕尺寸上都能够正常工作。
为了实现这些目标，我们采用了一种基于React的设计系统，它允许我们创建可重用的组件。我们将模态组件拆分为多个子组件，每个子组件负责处理特定的功能，如标题、内容、按钮等。这样的模块化设计使得组件的开发和维护更加容易。
然而，随着组件的不断发展和应用范围的扩大，我们开始面临更多的挑战。我们发现，每个用例都需要一些定制化的样式和行为，这使得组件变得越来越复杂。为了解决这个问题，我们引入了一种叫做"Variant"的概念。
Variant是一种用于定义组件外观和行为的配置对象。它可以包含诸如背景颜色、字体大小、动画效果等属性。通过为每个用例定义不同的Variant，我们可以轻松地创建各种样式和行为的模态组件。
然而，随着Variant的增加，我们开始遇到了一些性能问题。每个Variant都需要在组件加载时进行计算和处理，这导致了一些延迟。为了解决这个问题，我们采用了懒加载的策略，只在需要时才计算和渲染相应的Variant。
在最终的实现中，我们创建了一个高度灵活和可扩展的模态组件，它可以应对各种复杂的用例。我们通过合理的拆分和模块化设计，以及引入Variant的概念，成功地解决了组件的复杂性和性能问题。
总的来说，构建Faire的模态组件是一个具有挑战性的任务。通过合理的设计和创新的解决方案，我们成功地创建了一个灵活且易于使用的组件，为我们的产品提供了强大的功能和良好的用户体验。 端用户界面（UI）中的模态框是位于主内容上方的临时窗口。它通常包含上下文信息，允许快速操作，或呈现简短且可控的工作流程。你可能期望模态框能够转换为一个简单的组件，对吗？事实上，确实可以——但只是从前端开发者的角度来看。
设计师希望在前端拥有一个简单、直观和灵活的产品，即使这意味着后端更加复杂。
在Faire，设计系统团队负责构建可扩展的解决方案，使独立品牌在批发领域蓬勃发展。我们通过定义质量、改进流程、创建工具、建立信任和为所有人构建包容性的产品解决方案，帮助设计组织扩展规模。
模态框组件是我们工作的一个关键示例。作为Faire所有产品中最广泛使用的组件之一，模态框为我们提供了一个很好的机会来测试如何在直观和无限灵活的前端环境中平衡各方面的需求。 认识你的用户
首先，在构建设计组件时，了解你为谁设计以及他们在使用你所使用的工具和系统时的需求非常重要。
在Faire，我们使用Figma来设计我们的产品。虽然它是一个很好的协作工具，但Figma对于我们的行业来说仍然相对较新，对于不熟悉它的设计师来说可能是一个障碍。还有其他要考虑的因素，比如Figma的设计师如何组织他们的组件和屏幕设计，设计师是使用图层还是变体面板来控制组件变体，以及设计师对Figma组件结构的整体理解。
由于我们有来自不同背景和不同经验水平的设计师，因此构建设计系统工具和流程非常重要。 为了让所有设计师都能轻松使用和使用，我们致力于构建产品，使其在没有或只需很少的说明的情况下具有直观性。
在我们的审计中，我们发现了大约80个模态变体中的一小部分。
了解情况 #
为了更好地了解我们在Faire上使用模态的情况，我从一项广泛的审计开始。我审查了Faire在桌面网页、移动网页、原生Android和原生iOS上的模态，并研究了它们在我们的代码库中的呈现方式。
最终，我发现了80多种不同的模态变体 —— 哎呀！这些主要是在排版、内容层次结构、操作组织和模态主体中放置的内容方面的差异。我们很快确定了四个主要需求：
- 标准化标题和操作页脚
- 灵活性的模态主体内容
- 区分模态和非模态的指南
- 限制使用情况（即变体）
我还进行了用户访谈，其中 我们的研究帮助我们确定了两种不同的模态变体的需求：标准（满足了分享传统信息内容（如指令或详细信息）以及更丰富的内容（如表格）的需求）和营销（提供了适用于营销沟通的灵活内容和更丰富的图像）。
我们通过前置图像和易于访问的导航层来区分营销模态。其余的标题包括一个可选的图标和副标题，正文包含灵活的示例内容，页脚包含按钮和法律条款。
我们现在已经组装好了模态的框架，但我们知道需要许多不同的组合变体：标题、页脚、标题、图标、操作等的放置选项。为了确保设计师在他们的项目中拥有所有不同的变体，我们开始探索如何在Figma中展示这些变体。
保持前端简单
在研究不同的预处理方式时，我们决定保持前端简单。 通过Figma发送组件后，我们确定了两种不同的解决方案。第一种是利用图层来切换单个元素的开关。这对设计师来说过于嵌套和隐藏，并且由于间距问题与自动布局不太匹配。
第二种解决方案是通过Figma变体面板切换组件的元素，本质上为每个组件的每个排列组合创建变体。这个选项提供了更清晰的控制和更大的灵活性，但最终需要一个更复杂的后台。我们决定采用这个解决方案，因为它能为设计师提供最多的实用性，即使它需要更复杂的工作。
在Figma变体面板中切换元素的开关。
我开始构建模态组件的第一个版本：两个变体（标准和营销），可以在三种形态（原生iOS、原生Android/移动Web和桌面/平板）之间进行选择。 ## 大并非总是更好
在推出了一个“游乐场”文件，向设计师们介绍如何使用它之后，我收集了反馈并开始在我们的核心组件库的一个分支中构建该组件。这是找出你的组件有太多变体的绝佳时机。
我们发现，为一个组件创建大约一千个变体会显著减慢文件的加载速度。从资源面板拖动该组件时，加载组件需要花费近一分钟的时间。真是糟糕。
为了解决这个问题，我重新回到了绘图板上，并重新构建了该组件。 将以下的Markdown翻译成中文并删除第一级标题: e组件及其所有变体作为两个独立的组件:标准模态框及其所有变体，以及营销模态框及其所有变体。这将把变体分成两组，每组约500个 - 规模较大但更易管理。这意味着设计师仍然可以在顶层UI级别上切换页眉和页脚元素以及切换表单因素 - 他们只需从Figma资源面板中提取其中的两个组件。
发布我们的新模态框组件 #
我们看到设计师们立即开始在各种用例中部署该组件，拉伸其结构并测试其灵活性的程度。通过用户测试和初始使用反馈，我们发现设计师们非常欣赏该组件的灵活性。我们收到反馈称该组件使用起来很容易，并且表面级别的控制使人们容易理解该组件的灵活性。此外，两种模态框变体已经进入了数十个文件中。 构建一个自己的组件的建议
在构建模态组件的过程中，我们学到了很多。以下是我们的主要经验教训：
设计前端简洁性：设计师希望在前端拥有一个简单、直观和灵活的产品，即使这意味着在后端增加了更多的复杂性。就像一个家长购买一辆面包车一样，他们更关心的是安全性和空间性能，而不是后端的复杂性。
考虑可扩展性：在构建组件时，我们要考虑到将来的扩展需求。我们要设计灵活的组件，能够适应不同的需求和变化。
保持一致性：为了提高用户体验，我们要保持组件的一致性。这意味着在设计和实现组件时要遵循相同的规范和样式。
测试和迭代：构建组件是一个迭代的过程。我们要进行测试并不断优化组件，以确保其功能和性能的稳定性和可靠性。
文档和沟通：为了让其他人理解和使用我们的组件，我们要编写清晰的文档，并与团队成员进行良好的沟通。这有助于提高协作和效率。
最后，我们希望通过构建模态组件，能够为设计师提供一个简单易用的工具，帮助他们更好地完成工作。 车辆和引擎或拖车规格对用户来说不重要。不要让用户被无关的细节所困扰。
使选项易于访问：在确定如何设计一个组件时，设计师希望拥有最清晰的切换按钮。利用顶级的Figma变体面板是展示组件灵活性和选项的好方法。
限制是好事：有时，一个组件并不需要无尽的变体。有时，内容应该放在一个新页面而不是一个模态框中。将组件精简到最少的变体数量可以给设计师一个更清晰的决策点——基于使用案例而不是美学。
复杂性需要时间（很多时间）：有时，直到你深入其中，才能理解某个事物的真正复杂性。在规划和设计一个新组件时要花费足够的时间：明确定义初始发布，但愿意调整时间表，以确保发布的是高质量的产品。 产品。总会有一些你无法预料到的事情。
并非所有内容都需要在MVP中: 我发现这个项目是一个重要的提醒，不是所有的内容都需要在一个版本中集中。确定基本用例可以让你朝着核心用户需求构建，同时确保版本是迭代的，并且可以根据使用和学习进行更新。
为下一次做计划: 构建具有子组件灵活性。由于这个组件的规模，考虑到将来的维护非常重要。你最不想做的事情就是手动更新所有的1,000个组件变体。为了尽量减少工作量，我为页眉和页脚构建了子组件。这样我们可以在较小的规模（约20个变体）上进行更复杂和有影响力的更新，然后将这些变化传递到更大的组件变体集合（约1,000个）中，因为这些组件和变体会使用子组件。这是一个多米诺效应，将节省我们的时间。 想要帮助我们在Faire建立用户友好的以人为本的设计系统吗？请查看我们的招聘职位 (opens new window)。