使用代码进行设计：一种现代设计方法（开发挑战）

这篇文章得到了我们在 UXPin 的亲爱的朋友的大力支持，他们的使命是通过将设计和工程融合到一个更好、更快的产品开发世界中来实现最佳的用户体验。 谢谢！

设计师和开发人员之间的合作摩擦正在推动与行业本身一样古老的不断发展的讨论。 我们走了很长一段路才走到今天。 我们的工具发生了变化。 我们的流程和方法已经改变。 但潜在的问题往往保持不变。

无论团队的类型和规模如何，我经常会看到的一个反复出现的问题是保持可靠的事实来源。 即使雇用最优秀的人才并使用经过验证的行业标准解决方案，也常常让我们感到厌恶，认为某些事情肯定可以做得更好。 臭名昭著的“最终版本”通常散布在技术文档、设计文件、电子表格和其他地方。 使它们保持同步通常是一项乏味而艰巨的任务。

注意：本文是与 UXPin 团队合作编写的。 本文中介绍的示例是在 UXPin 应用程序中创建的。 某些功能仅适用于付费计划。 可以在此处找到UXPin 定价的完整概述。

设计工具的问题

谈到维护事实来源，设计工具的低效率通常被认为是最令人痛苦的痛点之一。 现代设计工具正在不断发展，并且通过巨大的努力正在快速发展。 但是，当谈到在设计和开发之间架起一座桥梁时，人们常常会觉得其中许多努力都是建立在有缺陷的假设之上的。

大多数现代设计工具都基于不同的模型，而不是后来用于实现设计的技术。 它们是作为图形编辑器构建的，并且行为如此。 在设计工具中构建和处理布局的方式最终不同于 CSS、JavaScript 和其他编程语言必须提供的任何方式。 使用矢量（甚至光栅）图形构建用户界面是对如何以及是否应该稍后将其转换为代码的不断猜测。

设计师最终常常会抱怨他们的创作没有按预期实现。 即使是最勇敢的像素完美设计也不能解决所有问题。 在设计工具中，几乎不可能想象并涵盖所有可能的情况。 支持不同的状态，改变副本，各种视口大小，屏幕分辨率等等，只是提供了太多的变化变量来覆盖它们。

除此之外，还有一些技术限制和限制。 作为一个没有开发经验的设计师，很难考虑所有的技术因素。 记住所有可能的输入状态。 了解浏览器支持的限制。 预测您的工作对绩效的影响。 设计可访问性，至少在某种意义上比颜色对比度和字体大小更广泛。 意识到这些挑战，我们接受一些猜测作为必要的邪恶。

但开发人员也经常不得不依靠猜测。 用图形编辑器模拟的用户界面很少能回答他们所有的问题。 它与我们已经拥有的组件是否相同？ 我应该将其视为不同的州还是单独的实体？ 当 X、Y 或 Z 时，此设计应如何表现？ 我们可以让它变得更快更便宜吗？ 具有讽刺意味的是，询问最初设计的人并不总是有帮助的。 并不罕见，他们也不知道。

通常，这不是越来越多的挫败感结束的地方。 因为那时，还有其他人。 经理、利益相关者、团队领导、销售人员。 由于他们的注意力和心智能力在产品的各个部分所在的所有工具和地方变得稀薄，他们比任何人都更努力地掌握它。

浏览原型，了解设计中缺少某些功能和状态的原因，以及区分缺少的内容、正在进行的工作以及有意识地排除在范围之外的内容几乎是不可能的。 快速迭代已经完成的工作、可视化您的反馈以及展示您自己的想法也几乎是不可能的。 具有讽刺意味的是，越来越多的复杂工具和流程旨在让设计人员和开发人员更好地协同工作； 他们设定了更高的标准，并且更难积极参与其他人的流程。

解决方案

我们行业的无数负责人致力于解决这些问题，从而产生了新的范式、工具和概念。 事实上，很多事情都变得更好了。 让我们快速浏览一下应对上述挑战的一些最常见的方法。

编码设计师

“设计师应该编码吗？” 是一个陈词滥调的问题，通过文章、会议演讲和所有其他媒体进行了无数次讨论，讨论中的新声音不时出现稳定的规律性。 有一个普遍的假设是，如果设计师“知道如何编码”（我们甚至不要一开始就开始纠缠于如何定义“知道如何编码”），他们将更容易制作出采用技术的设计考虑到约束并且更容易实现。

有些人会走得更远，说他们应该在实施中发挥积极作用。 在那个阶段，很容易得出结论，完全跳过使用设计工具而只是“在代码中设计”并不是没有意义的。

这个想法听起来很诱人，但它很少在现实中证明自己。 我认识的所有最好的编码设计师仍在使用设计工具。 这绝对不是因为缺乏技术技能。 解释为什么重要的是要突出构思、草图和构建实际事物之间的区别。

只要有许多“代码设计”的有效用例，例如使用预定义的样式和组件来快速构建功能齐全的界面，而无需使用设计工具，那么设计工具就可以提供不受约束的视觉自由的承诺仍然具有不可否认的价值。 许多人发现以设计工具提供的格式草绘新想法更容易，更适合创作过程的本质。 这不会很快改变。 设计工具将永远存在并永远存在。

设计系统

设计系统的伟大使命，作为过去几年数字化设计界最伟大的流行语之一，始终是：限制猜测和重复，提高效率和可维护性，统一事实来源。 Fluent 或 Material Design 等企业系统在宣传这一想法方面做了很多工作，并为大小参与者采用该概念带来了动力。 确实，设计系统帮助改变了很多，变得更好。 一种更结构化的方法来开发定义的设计原则、模式和组件集合，帮助无数公司构建更好、更易于维护的产品。

然而，一些挑战并没有立即得到解决。 使用流行的设计工具设计设计系统阻碍了许多人实现单一事实来源的努力。 取而代之的是，已经创建了过多的系统，尽管它们是统一的，但仍然存在于两个独立的、不兼容的源中：设计源和开发源。 保持两者之间的相互平等通常被证明是一件痛苦的苦差事，重复设计系统最初试图解决的所有最讨厌的痛点。

设计和代码集成

为了解决设计系统的可维护性难题，另一波解决方案很快到来了。 设计代币等概念已经开始受到关注。 有些旨在将代码状态与设计同步，例如允许直接从设计文件中获取某些值的开放 API。 其他的旨在将设计与代码同步，例如通过在设计工具中从代码生成组件。

这些想法很少被广泛采用。 这很可能是由于可能的好处相对于仍然高度不完善的解决方案的必要进入成本的可疑优势。 对于大多数专业用例来说，将设计自动转换为代码仍然是巨大的挑战。 允许您将现有代码与设计合并的解决方案也受到严重限制。

例如，任何允许您将编码组件导入设计工具的解决方案，即使在视觉上与源代码相同，也无法完全复制此类组件的行为。 直到现在都没有。

将设计和代码与 UXPin 合并

UXPin 作为一个成熟且功能齐全的设计应用程序，在设计工具舞台上并不是一个新玩家。 但它最近的进步，例如合并技术，可以改变我们对设计和开发工具的看法。

使用 Merge 技术的 UXPin 允许我们通过保留其视觉效果和功能，将真实、实时的组件带入设计中——所有这些都无需编写任何代码。 即使嵌入在设计文件中的组件，其行为也应与其真正的对应物完全相同——因为它们是它们真正的对应物。 这使我们不仅可以实现代码和设计之间的无缝奇偶校验，还可以使两者保持不间断的同步。

UXPin 支持存储在 git 存储库中的 React 组件的设计库，以及与 Storybook 的强大集成，允许使用来自几乎任何流行的前端框架的组件。 如果您想自己尝试一下，可以在 UXPin 网站上请求访问它：

• 请求使用 Merge 技术访问 UXPin →

在 UXPin 中将活动组件与设计合并只需要很少的步骤。 找到正确的组件后，您可以通过单击将其放置在设计画布上。 它的行为与您设计中的任何其他对象一样。 它的特别之处在于，即使是设计的一个组成部分，您现在也可以像在代码中一样使用和自定义它。

UXPin 使您可以访问组件的属性，允许您更改其值和变量，并用您自己的数据填充它。 一旦启动原型，组件的行为将完全符合预期，并保持所有行为和交互。

在您的设计中，您可以混合和匹配无限数量的库和设计系统。 除了添加您自己的库之外，您还可以在各种开箱即用的开源库中进行选择，例如 Material Design、Fluent UI 或 Carbon。

“按原样”使用组件也意味着它应该根据上下文的变化来表现，例如视口的宽度。 换句话说，这些组件是完全响应和适应性强的。

注意：如果您想了解有关使用 UXPin 构建真正响应式设计的更多信息，我强烈建议您查看这篇文章。

上下文也可能意味着主题。 无论谁试图在设计工具中构建（并维护！）一个主题化的设计系统，或者至少创建一个允许您在浅色和深色主题之间轻松切换的系统，都知道这项任务有多么棘手，以及它有多么不完美。结果通常是。 没有一种设计工具针对开箱即用的主题进行了很好的优化，旨在解决该问题的可用插件远未完全解决。

由于具有 Merge 技术的 UXPin 使用真实的活动组件，您还可以将它们主题化为真实的活动组件。 您不仅可以根据需要创建尽可能多的主题，而且切换它们可以像从下拉列表中选择正确的主题一样快。 （您可以在此处阅读有关使用 UXPin 进行主题切换的更多信息。）

优点

具有 Merge 技术的 UXPin 允许在设计和代码之间实现前所未有的同等水平。 在设计过程中忠实于源头为过程的各个方面带来了无可挑剔的优势。 设计师可以放心地进行设计，因为他们知道他们所做的不会被误解或错误地开发。 开发人员不必将设计转换为代码，也不必纠结于不明确的边缘情况和未发现的场景。 最重要的是，每个人都可以参与工作并使用实时组件快速原型化他们的想法，而无需了解底层代码。 实现更民主、更参与的过程更触手可及。

将您的设计与代码合并不仅可以改善设计人员与团队其他成员的合作方式，还可以改进他们的内部流程和实践。 对于那些专注于大规模优化设计工作（有时称为 DesignOps）的人来说，采用 Merge 技术的 UXPin 可以改变游戏规则。

使用正确的事实来源可以莫名其妙地更容易保持团队中不同人员制作的作品之间的一致性，帮助他们保持一致，并使用一套联合工具解决正确的问题。 不再有带有少量不请自来的变体的“分离符号”。

归根结底，我们得到的是巨大的时间节省。 设计人员可以放心地使用组件及其开箱即用的功能，从而节省时间。 他们不必在组件更改时更新设计文件，也不必记录他们的工作并“挥手”向团队其他成员解释他们的愿景。 开发人员通过以一种无需猜测和额外修补的即刻可理解的方式从设计师那里获取组件来节省时间。

负责测试和 QA 的人员可以节省时间来寻找设计和代码之间的不一致并确定植入是否按预期进行。 利益相关者和其他团队成员通过更有效的管理和更轻松的团队导航来节省时间。 更少的摩擦和无缝的流程限制了团队成员之间的挫败感。

缺点

不过，利用这些好处需要付出一些入门成本。 要在您的流程中有效地使用诸如 UXPin 之类的工具，您需要有一个现有的设计系统或组件库。 或者，您可以将您的工作基于始终提供某种程度限制的开源系统之一。

但是，如果您首先致力于构建一个设计系统，那么在您的流程中使用带有 Merge 技术的 UXPin 几乎不会产生额外成本。 有了一个完善的设计系统，采用 UXPin 应该不会是一件困难的事，而这种转变的好处可能会被证明是巨大的。

概括

设计系统的广泛采用解决了媒体开发人员和设计师工作的问题。 目前，我们可以观察到向更统一的流程转变，这些流程不仅改变了媒体，还改变了我们创造它的方式。 使用正确的工具对于这种变化至关重要。 采用 Merge 技术的 UXPin 是一种设计工具，它允许将设计与实时代码组件相结合，并大大缩小了设计和开发操作领域之间的差距。

下一步在哪里？

• UXPin 合并：故事书集成
  了解 Storybook 集成如何帮助您的产品团队并尝试一下！
• UXPin 合并：Git 集成
  请求访问以查看与 Git 存储库的集成如何工作。
• UXPin Merge 短视频讲解
  作为“交互式设计系统：强生网络研讨会”的一部分。
• 代码设计：UXPin 合并教程
  使用 Merge 技术的 UXPin 介绍性教程。
• 使用 UXPin 合并的响应式设计
  使用合并技术使用 UXPin 制作完全响应式体验的原型指南。