这些年来，我与开发人员、产品经理、质量保证工程师及其他开发人员中的其他贡献者密切合作。这些经历让我对产品从开发到市场的全过程有了深入的了解。现在，我已经形成了一套关于产品开发周期应该如何进行的认识。
产品开发流程由Pelin Kenez，发布于Zeplin博客
如Zeplin的联合创始人兼CEO Pelin Kenez所说：
她这样说道：
它是设计构思的“无限潜力”与实现设计的“现实限制”相遇的地方。
这一开发周期中的每个步骤都充满挑战。在这篇文章中，我将讨论设计交付阶段，特别是在我所说的组件规范部分，如何打包所有必要的信息，形成一套连贯且全面的组件集，以供产品设计系统使用。
共同点:对于还不熟悉网页和原生应用开发中“物理规律”的初学者设计师来说，通常他们往往会设计出展示流程的界面。他们的成果通常是一系列屏幕，理想情况下，这些屏幕应该从开始到结束构成一个完整的流程。
典型的流程如下，XM Cyber来说。
大多数设计师并不考虑如何实现这些设计，这是至关重要的。在我看来，这种意识是初级和中级UX/UI设计师之间的分界。最终，并非设计师的所有愿望和梦想都能在开发中实现——不仅是因为现有工具可能无法实现，还因为常常忽视边缘情况和响应性。这可能导致可靠性问题和意外的交互情况，当这些页面或组件面对现实场景、与其他元素交互或遇到超过设计预期的内容时。
在网页和原生应用开发的结构和限制下创造有意义的界面设计，这是区分初级UX/UI设计师与中级设计师的关键。
稳定性和意想不到的行为你有没有遇到过网站、SaaS 平台或产品，它们有明显的视觉问题？我当然遇到过，常常会说：“这开发质量真不行！”不过，问题往往不在开发人员的决策上；相反，我认为问题主要出在设计和产品定义不够明确上。
An example of a bug in the UI. The containers aren’t reacting correctly to window size changes.
这些问题根本就不该出现；它们会阻碍产品实现其价值，并增加开发团队的人力成本。开发人员需要发现问题，修复相关代码，进行测试，并将修复部分合并到生产环境。大量时间会被浪费在修复这些问题上，尤其是当这些问题出现在可重用组件时。如果当初设计定义得当，这种情况本来是可以避免的。在大规模应用设计系统时，这些问题可以被大大减少，这有助于在整个产品中避免不良的用户体验和意外行为。
瑞典翻译通常不会改变Markdown标签的内容或形式，因此： 瑞典翻译通常不会改变Markdown标签的内容或形式，因此：信息的传达
在典型的設計系統中，你會找到給設計師的指示，說明何時以及如何在他們的設計中使用可用組件，通常會提供邊緣情況、不同變體和文案指南。設計師作為設計系統的使用者，會遇到一組規則和限制，這些規則和限制會幫助他們構建設計，這只是表面而已。開發人員又如何呢？他們同樣是設計系統的使用者。他們會根據這些指示來構建頁面和屏幕。設計文檔在創建新組件時是否提供了足夠的說明呢？
任何一个设计师在设计系统之旅中最先创建的组件，如果不是第一个，那就是——那个按钮。
按钮组件里的一些元素
我们必须在将该按钮作为设计系统中的共享组件之前使用它之前，确定一些属性。例如：大小、颜色、图标、圆角半径、字体样式、内间距、间距。甚至在我们讨论不同尺寸变体或实际按钮用法之前！
在过去，设计师通常提供一张静态图片来展示组件的布局和尺寸。你仍然可以在社交网络上的新手设计师社区找到这种详细的图片。不过，现在这远远不够作为开发UI组件的完整指导了。
一种定义按钮布局设计的简单而肤浅的方法
上述示例仅包含最基本的内容。当开发人员开始开发，比如一个按钮时，他们还需要定义许多其他参数。如果设计师没有定义这些参数，开发人员该怎么办？我于2024年写这篇文章，幸运的是，这对我们的开发人员来说是个好消息！Figma的开发模式可以帮上忙。
就像那个在宜家迷路的顾客可以打电话求助一样，开发者也可以查看开发模式的属性面板，从中找到他急需的大部分指导信息。
宜家的人打电话到店里了
开发模式不行吗？虽然 Figma 的 Dev 模式提供了很多关于组件的布局、位置、样式和排版的信息，但它会尽力展示相关的信息。也就是说，Dev 模式并不具备完全展示代码所需的全部工具、测量和能力。有经验的开发者会参考这些属性，但更喜欢以他们自己的方式编写代码。
未定义的后果设计师可能需要一个画布来尝试各种想法，头脑风暴，讨论，向利益相关者展示不同方案。
正如Erez Reznikov 所说，设计师在探索创意时，更喜欢在“画布”上自由发挥，而不是被DOM的“重力”束缚。
此外，大多数UI设计工具的特性允许设计师以一种可能使他们忽略其设计在网页和原生平台上的物理限制的方式创建屏幕。这些工具就是这样工作的。
从Erez的文章来看，关于超越创意工具的文章。
设计师有时可能会忽略他们的设计需要遵循网页和原生平台的物理规则。
这可能导致组件定义模糊，从而导致难以预测的边缘情况表现。例如，一个典型的按钮在一种状态下可能看起来很好，但在遇到动态内容时可能缺乏必要的灵活性。例如，当父容器变窄时，按钮两侧不再有足够的空间，导致会发生什么？应该怎么做？
- 换行但保留之前的行距吗？
- 调整行距以适应更多行数吗？
- 让文字超出边界吗？
UI组件的另一个意想不到的行为，当没有空间时会怎样。
为了解决这种意外情况，我建议实施一个规则，将按钮文本截断并加上省略号，并在鼠标悬停时显示包含完整文本的工具提示。
使用省略号和工具提示（如有需要）。
不过，这些定义不会在 Figma 中显示，除非由设计师明确写出。这些定义可能被忽视，因为组件是在画布上创建的，在这种情况下，布局约束可能不被强制。
检查按钮时，Figma 会提供有关其布局的信息。考虑到内边距和高度属性，Figma 告诉我们内边距设置为 padding: 0px 24px，这意味着按钮顶部没有内边距，而左右内边距为 24px。更推荐使用 padding-inline 属性，因为它可以更准确地控制内边距，而无需调整整个元素的高度，因为该组件的高度和内部元素的位置已经确定，。
The properties and values of a layout that Figma provides
**padding-inline**是一个 CSS 逻辑简写属性，它将padding-inline-start和padding-inline-end属性结合为一个声明，从而在内联（即左右）方向为元素内容周围预留空间。
— Joel Olawanle 在 css-tricks.com
此外，设计者可能无法完全利用实际开发中的所有属性和参数。例如，Figma 使用 Auto-layout，类似于 Flexbox 布局，允许子元素使用 px 固定，或者设置为填充或抱紧的方式。相比之下，设计者通常不接触实际开发，因此对其他选项的了解较为有限；CSS Grid 布局 允许用户输入 px、百分比或 fr 单位，从而更好地控制动态内容的结果。
尽管它们看起来一样，但它们允许动态内容有不同的结果。
这些单位都是相对单位，如 em、ex、rem、vw、vh、vmin、vmax、% 和 ch。我在之前的文章中提到过这些单位。
以下是编写更优质代码的例子，不仅限于 Figma，更强调开发人员在创建设计系统中的可重用组件时需要更好的指导。
团队共同制定规格回到那个对宜家感到困惑的男子，说明书有时会告诉你与朋友合作一起搭建SMÅSTAD衣柜。两个人合作往往比一个人做得更好；在我们的情况下，比如，设计师和开发人员合作，分享知识，将产生更好的设计系统组件。
宜家的这位男士得到了他人的帮助。
设计者应该向开发者学习他们的实践方法，并理解代码如何运作，从而能够设计更加健壮的组件。在创建共享语言时，传达设计系统组件定义的最佳方式是通过规范文档，这样可以更清晰地说明组件的功能和用法。在我担任XM Cyber唯一设计师以及后来的UX和设计主管期间，领导设计团队时，我制作了一个我喜欢称为组件规格书的文档模板。
一个基本按钮组件的示例，展示组件规范
zh: TL;DR: 如果你是第一次看到这一部分，这里有个快速回顾：组件规范汇集了创建一个完整且一致的产品设计系统组件集所需的所有必要细节。这包括各种变体、边缘情况和任何限制。通过详细定义组件，我们可以减少它因动态内容而导致的故障或行为不可预测的风险。
组件规范里包含哪些内容？ 定义与示例这一部分通常展示组件的各种状态和变种，并附有其用法的简要说明。目的是为开发人员提供必要的信息，以便他们理解组件应该如何使用，并鼓励他们如果有想法，可以提出相关修改建议。
介绍和定义号召性用语按钮（Call to action button）以及其在XM Cyber中的应用
解剖、规则和限制及动画解构 — 从最复杂的变体开始，设计师应详细描述组件的不同部分及其内部组件（如有）；这将作为限制、边界情况和标记部分的参考。
规则与限制 — 组件应在特定参数范围内运行，如前所述。本部分详细说明这些边界，包括处理边界情况、空态、错误和文本约束。它还涵盖了对齐、组或数组中的行为以及开发人员必须执行的任何其他功能规则，以确保组件在所有情况下都能保持一致性和可靠性。
动画 — 如有必要，定义。Aviad Shahar 写了一篇关于创建有意义的时间线的指南
明确展示如何给按钮设定界限
键盘可访问性这里应该描述组件的键盘操作，既要满足无障碍需求，也要为熟练用户提供快捷键组合。它应指定使用Tab键或箭头键时元素的导航顺序，确保键盘操作的顺序既合理又直观。
Tokens 和变体本节提供了组件测量和值的详细分解，理想情况下以设计令牌的形式呈现。从默认变体开始记录，记录所使用的所有属性。对于后续变体，仅记录变更或新增的属性，强调各变体之间的差异之处，同时保持内容简洁。这种方法确保清晰，同时避免在通常较为详尽的部分中不必要的重复。
所有的值都是设计值
这个例子充满了XMDS2的设计令牌（tokens），这是XM Cyber的设计系统。下方有更多关于它的信息。
用原子设计方法论构建强大的设计系统，包含设计令牌。medium.com下面的例子展示了 Figma 默认布局和我建议的布局之间的 CSS 属性差异。这样组织布局可以提高可读性。如前所述，某些属性可能与开发人员实际实现的方式有所不同：padding: 0px var(-a_commonPadding) vs padding-inline: var(-a_commonPadding)。当说到文本长度时，使用 fr 单位来衡量字符长度。
比较 Figma 和 Component Spec
故事集最后，该组件应在您的前端文档系统中详细记录，目前最常用的工具是 Storybook。建议创建一个交互式的关键变体展示，以便轻松地探索和测试其不同变体，这样用户可以轻松地探索和测试其功能。
在 Storybook 中把它展示出来
那么，我们学到了什么呢？在我们的设计系统中拥有一个稳固的组件规范是多么重要，因为它充当了设计团队和开发团队之间的重要纽带。它强调了我们需要考虑设计在实际应用中的运作方式，特别是在处理动态内容时。通过与开发人员紧密合作，我们可以制定清晰的文档来说明组件应该如何工作，并考虑到各种技术限制。这种团队协作有助于确保我们的组件不仅在视觉上吸引人，而且在各种用户交互中也兼具灵活性和可靠性，从而最终提升用户体验并减少开发难题。
主要要点（注：此处根据专家建议保留了“主要收获”之意，但更倾向于使用“主要要点”以更贴近英文原文的表达，并且在上下文中更自然。若有更偏向非正式或口语化文档，可以考虑使用“主要的收获”。）
（考虑到专家建议，这里翻译为“主要要点”，同时在上下文中的格式保持一致，前后空行以符合英文原文的排版，即通常在笔记或摘要中作为一个独立的段落。）
主要要点- 管理意外行为：一个定义明确的组件规范对于最小化组件中的意外行为至关重要，确保它们在处理动态内容时更加稳定可靠，并解决变体、边界情况和其他限制。
- 衔接设计与开发：设计师和开发者之间的有效合作至关重要，因为设计师需要理解技术限制，而开发者则依赖清晰的规范来构建组件。
- 定义组件参数：设计师需要明确所有相关参数——如大小、颜色和行为——以消除歧义并指导开发人员实现。
共同学习，写下你的评论
评论加载中...
作者其他优质文章
