用代码设计。设计的现代方法（开发挑战-一一网

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

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

注意：_本文是与UXPin团队合作撰写的。本文介绍的例子都是在UXPin应用程序中创建的。其中一些功能仅在付费计划中提供。关于UXPin的定价的完整概述可以在这里_找到。

设计工具的问题

谈到维护真理之源，设计工具的低效率经常被指出是最致命的痛点之一。现代设计工具在不断发展，并且在巨大的努力下快速发展。但是，当涉及到在设计和开发之间建立桥梁的时候，我们不难感觉到这些努力很多都是基于有缺陷的假设。

大多数的现代设计工具都是基于与后来用于实现设计的技术不同的模型。它们是作为图形编辑器来构建的，并以这种方式行事。在设计工具中构建和处理布局的方式最终与CSS、JavaScript和其他编程语言所能提供的不同。使用矢量（甚至是栅格）图形来构建用户界面，需要不断地猜测如何以及是否应该在以后把你做的东西变成代码。

_设计师们_经常为他们的创作没有按预期实现而叹息。即使对像素完美的设计作出最勇敢的努力也不能解决所有的问题。在设计工具中，几乎不可能想象和涵盖所有可能的情况。支持不同的状态、不断变化的文案、各种视口尺寸、屏幕分辨率等等，只是提供了太多的变化变量，无法涵盖所有这些。

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

但是，_开发人员_也经常不得不依赖猜测。用图形编辑器模拟出来的用户界面很少能回答他们所有的问题。它和我们已经有的那个组件是一样的吗？我应该把它作为一个不同的状态，还是作为一个独立的实体？这个设计在X、Y或Z时应该如何表现？我们能不能把它做得有点不同，因为这样做会更快、更便宜？具有讽刺意味的是，问一开始创造设计的人并不总是有帮助。他们也不例外，他们也不知道。

而且，通常情况下，这还不是增长的挫折感的范围的终点。因为，还有_其他所有人_。经理、利益相关者、团队领导、销售人员。他们的注意力和心理承受力在所有的工具和产品的各个部分所处的位置之间被拉得很细，他们比其他人更努力地去掌握它。

浏览原型，理解为什么某些功能和状态在设计中缺失，区分哪些是缺失的，哪些是正在进行的，哪些是被有意识地从范围中排除的，感觉几乎是不可能的。快速迭代已经完成的工作，将你的反馈可视化，并提出你自己的想法，感觉也几乎不可能。具有讽刺意味的是，越来越复杂的工具和流程是为了让设计师和开发人员更好地合作；它们把门槛定得更高，而其他人积极参与流程则更难。

解决方案

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

设计师编码

“设计师应该编码吗？”这是一个老生常谈的问题，通过文章、会议演讲和所有其他媒体讨论了无数次，讨论中不时有新的声音冒出来。有一个普遍的假设是，如果设计师 “知道如何编码”（我们甚至不要开始纠结如何定义 “知道如何编码”），他们就会更容易制作出考虑到技术限制并更容易实现的设计。

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

尽管这个想法听起来很诱人，但在现实中很少被证明。我认识的所有最好的编码设计师都还在使用设计工具。而这绝对不是因为缺乏技术能力。解释一下_原因_是很重要的，要强调构思、草图和建造实际事物之间的区别。

只要**”在代码中设计 “有许多有效的使用案例**，比如利用预定义的样式和组件来快速建立一个功能齐全的界面，而不需要麻烦你们使用设计工具，那么设计工具所提供的不受约束的视觉自由的承诺仍然具有不可否认的价值。许多人发现用设计工具提供的格式来勾画新的想法更容易，也更适合创作过程的性质。而这一点不会很快改变。设计工具将继续存在，并将永远存在。

设计系统

设计系统的伟大使命，也是过去几年数字设计界最伟大的流行语之一，一直都是这样：限制猜测和重复，提高效率和可维护性，并统一真理的来源。像Fluent或Material Design这样的企业系统在宣传这一理念方面做了大量的工作，并为大大小小的企业采用这一概念带来了动力。而事实上，设计系统帮助改变了很多，使之变得更好。一个更加结构化的方法来开发一个明确的设计原则、模式和组件的集合，帮助无数的公司建立更好、更可维护的产品。

但有些挑战并没有直接解决。在流行的设计工具中设计设计系统，阻碍了许多人实现单一真理来源的努力。相反，大量的系统被创造出来，尽管是统一的，但仍然存在于两个独立的、不兼容的来源中：一个是设计源，一个是开发源。维持这两个系统之间的平等通常被证明是一件痛苦的工作，重复着设计系统首先要解决的所有最讨厌的痛点。

设计与代码的整合

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

这些想法中很少有得到广泛采用的。这很可能是由于可能的好处比仍然非常不完善的解决方案的必要入门成本更值得怀疑的优势。对于大多数专业用例来说，将设计自动转化为代码仍然是一个巨大的挑战。允许你将现有代码与设计合并的解决方案也受到了严重的限制。

例如，没有一个允许你将编码的组件导入设计工具的解决方案，即使在视觉上与源文件一致，也不能完全复制这些组件的行为。直到现在都没有。

用UXPin合并设计和代码

UXPin，作为一个成熟的、功能全面的设计应用，在设计工具的舞台上并不是一个新的参与者。但它最近的进步，如合并技术，却能改变我们对设计和开发工具的看法。

采用Merge技术的UXPin允许我们将真正的、活的组件带入设计中，同时保留其视觉效果和功能–所有这些都不需要写一行代码。这些组件即使被嵌入到设计文件中，其行为也将与它们的真实对应物一模一样&mdah; 因为它们就是它们的真实对应物。这使我们不仅能够实现代码和设计之间的无缝对等，还能使两者保持不间断的同步。

UXPin支持存储在git仓库中的React组件设计库，以及与Storybook的强大集成，允许使用几乎所有流行的前端框架中的组件。如果你想亲自试一试，你可以在UXPin网站上申请访问它。

申请访问 UXPin 与合并技术 →

在UXPin中合并实时组件和设计，只需令人惊讶的几个步骤。找到合适的组件后，您可以通过点击将其放置在设计画布上。它的行为与你设计中的任何其他对象一样。最特别的是，尽管它是设计的一个组成部分，但你现在可以像在代码中一样使用和定制它。

UXPin让你可以访问组件的属性，让你改变它的值和变量，并且用你自己的数据来填充它。一旦开始使用原型，该组件将完全按照预期的方式运行，保持所有的行为和交互。

以 “原样 “使用一个组件也意味着它应该根据上下文的变化而表现，比如视口的宽度。换句话说，这种组件是完全响应和适应的。

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

语境也可能意味着主题化。不管是谁试图在设计工具中构建（和维护！）一个可供主题的设计系统，或者至少创建一个允许你在浅色和深色主题之间轻松切换的系统，都知道这是一个多么棘手的任务，而且结果通常是不完美的。没有一个设计工具在开箱时就对主题进行了很好的优化，而旨在解决这个问题的现有插件也远远没有完全解决这个问题。

由于带有Merge技术的UXPin使用的是真实的、活的组件，你也可以把它们作为真实的、活的组件来做主题。你不仅可以根据需要创建任意多的主题，而且切换它们就像从下拉菜单中选择正确的主题一样快速。你可以在这里阅读更多关于UXPin主题切换的信息）。

优势

UXPin的Merge技术使设计和代码之间达到了前所未有的一致水平。在设计过程中忠实于源码，为过程中的所有方面带来了无可挑剔的优势。设计师可以放心地设计，知道他们所做的东西不会被误解或错误地开发。开发人员不必将设计转化为代码，也不必在不明确的边缘情况和未发现的情况下糊弄。最重要的是，每个人都可以参与到工作中来，在完全不了解底层代码的情况下，使用实时组件快速制作他们的想法原型。实现更民主的、参与性的过程是可以做到的。

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

使用正确的真理之源，可以莫名其妙地更容易在团队中不同人产生的作品之间保持一致性，帮助他们保持一致，并通过一套联合工具一起解决正确的问题。不再有 “脱离实际的符号 “和少数不请自来的变化。

在底线上，我们得到的是巨大的时间节省。设计师们通过使用有信心的组件和其开箱即用的功能来节省他们的时间。他们不需要随着组件的变化而更新设计文件，也不需要记录他们的工作和 “挥手 “向团队其他成员解释他们的设想。开发人员通过从设计者那里得到的组件，以一种即时可消化的方式，不需要猜测和额外的修补，从而节省时间。

负责测试和QA的人节省了寻找设计和代码之间不一致的时间，并弄清楚植入是否按预期进行。利益相关者和其他团队成员通过更有效的管理和更容易的浏览这些团队来节省时间。更少的摩擦和无缝的过程限制了团队成员之间的挫折感。

缺点

虽然利用这些好处需要一些入门成本。为了在你的流程中有效地使用UXPin这样的工具，你需要有一个现有的设计系统或组件库。或者，你可以把你的工作建立在一个开源系统上，这总是会提供一定程度的限制。

然而，如果你致力于首先建立一个设计系统，那么在你的过程中使用UXPin与Merge技术将几乎不需要任何额外的成本。有了一个完善的设计系统，采用UXPin不应该是一件困难的事情，而这种转变的好处可能会被证明是巨大的。

总结

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