弥合设计师和开发人员之间的鸿沟

本文由我们在 UXPin 的朋友提供支持，这是一个UI 设计和原型制作工具，可为您的原型提供应有的超能力：状态、JS 表达式、变量、条件交互、Git 同步。 但本文不受UXPin的任何影响，仅代表作者的独立意见。 谢谢！

在过去的几年里，我们的设计工具呈指数级发展已经不是什么秘密了。 许多人拥有出色的组件管理和原型设计，您可能想知道下一步可能会发生什么重大飞跃？

让我们看一个典型的困境：

假设您是设计系统团队的设计师，您正在创建组件、变体并花费大量时间来记录所有可能会或可能不会更改的用例和属性。 您最终完成了一个大型复杂组件并将其交付给开发人员。

我们怎么知道代码是同一个 UI？ 我们真的需要审核每一个组件吗？ 我们如何在没有不断进行审查的开销的情况下弥合设计与开发之间的差距？

所有这一切，你必须帮助教人们使用组件的不同方法、适当的间距和响应式 Web 的设计，当然，组件需要针对未来的用例进行更新。

有很多接触点，涉及的人很多。 几乎感觉我们越深入设计系统，每个人的开销就越大！ 现在，隧道尽头的一盏灯似乎在闪闪发光，下一件大事即将来临。

所有混乱中的隐藏宝石

我最近有机会重温了一个很久没用过的工具——一个旨在弥合这一差距并最大限度地减少所有开销的工具：UXPin。 一项名为“合并”的新功能已经推出，以帮助突破设计和开发的鸿沟，同时提高我们团队所期望的敏捷性和质量。 这项新技术可能会让一些人重新思考整个设计和工程团队如何通过用例和构建组件进行协作和工作。

淘汰旧流程

如果我们看看当今大多数公司采用的当前流程，它可能会非常乏味，并存在一些明显的缺陷。 当我们从头开始创建新组件时，我们将设计组件的基础级别、添加变体、编写文档、发布到库并将其交付给开发人员。 列出这个过程是冗长的，但幸运的是它只需要完成一次（我们希望）：

现在，当我们需要更新组件时会发生什么？ 一个新的用例出现了，或者我们决定将我们的边界从圆形更改为锐利？ 我们现在需要将变体添加到库中，（可能）再次更新文档，发布并交付给我们的开发人员。 呸！ 让我们希望我们的设计师在组件重组的过程中没有任何问题。

我差点忘了，我们还需要将更新发布到开发库！ 让我们希望他们能够在产品团队按照自己的方式按时完成之前完成。

加入新流程

因此，您可能想知道，UXPin Merge 的技术如何帮助我们今天都采用的这种顶级流程？ 好吧，看看下面的图表。 您可能会注意到不需要创建组件和变体（在大多数情况下）。 这个新流程减少了对自动布局工具的摆弄，因为我们现在与开发人员建立了协同关系：

我们只需要设计文档和实现所需的详细程度。 可能不需要设计简单的组件，例如按钮或其他原子级组件。 当开发可以立即开始而几乎没有开销时，为什么还要浪费时间做双倍的工作呢？ 在某种程度上，我们绕了一圈； 当静态组件在文档中只显示一些交互时，我们正在回到旧的方式。

请注意，发布到库现在处于流程的末尾。 这是因为，一旦开发人员完成了组件，它现在可以利用 Merge 将其提供给 UXPin 中的设计人员，当然，您所有的产品开发人员都可以同时拥有它！

更新组件时，它与新组件基本相同，除了根据场景甚至可以跳过第一步。 例如，假设您要添加一个选项以将图标添加到按钮； 这不是需要设计的东西，而是需要与开发中的新朋友进行沟通。

虽然与您的开发人员形成了这种新的关系，但正式向设计人员发布组件的新方式可能只有在开发人员发布时才会发布。 产品设计师询问他们的产品开发人员是否可以使用某个组件的日子已经一去不复返了。 如果它在库中，那么它就可以在开发中使用，并且可供设计人员立即使用。

但是关于这个过程就足够了。 让我们来看看 UXPin Merge 是如何工作的。

管理图书馆

最好的部分是库可以直接从您的代码存储库中导入，例如 GitHub、Bitbucket、GitLab（仅适用于 React 组件），甚至可以从 Storybook 中导入。 创建库后，您可以选择命名库。

使用 Storybook 导入时，过程非常简单。 只需获取库 URL，UXPin 将为您完成剩下的工作。 使用 React 组件，使用 CLI，您可以通过指定 UXPin 库的唯一令牌来控制发布的组件。

版本控制和测试

设计师和设计系统团队最关心的问题之一是版本控制。 大多数问题都可以通过这个 UXPin 的合并功能来解决。 让我们快速绘制一张图片：

今天，当我们着手升级组件时，总是担心会破坏可能被重命名和清理的组件或层。 组件的整体结构甚至可能发生，这通常会导致（在设计师方面）他们是否应该升级组件或坚持使用旧组件的焦虑。

但是，在开发组件时，只要属性保持不变，组件布局如何更改或组件的实际标记都无关紧要。 这反过来又使设计人员可以放心地将其组件升级到最新版本。

当然，在组件完全搞砸的极少数情况下，就像任何编码项目一样，它可以很容易地回滚并重新发布组件的旧版本。

测试更新

在测试新组件或更新时，今天并不是那么容易。 我们显然不能编辑现有的设计库进行测试，因为这可能会意外发布，并阻止任何其他准备就绪的更新。 在新文件中创建组件，对其进行测试，然后尝试在不破坏层的情况下处理合并回当前库，这也是非常麻烦的。

对我们来说幸运的是，开发人员很久以前就发现了这个问题，并且它正好适合 UXPin 的 Merge 技术。 在测试新组件时，最好的做法是 fork 或分支代码，并且这个新分支可能会发布到 UXPin 内的测试环境中。 您的团队可以对其进行测试，或者您可以授予您公司中的一小部分 Beta 测试人员的访问权限。 一旦组件经过测试和试用，就可以快速引入组件并将其发布到主设计库，无需缝合。

用代码设计

那么，我们的地面团队成员是如何设计的，这项技术对他们意味着什么？ 好吧，我很高兴你问！ 从产品设计师的角度来看——没有太大区别。 当设计人员使用 Merge 开发库中的组件时，每个组件都会用橙色六边形标记。 任何新的东西都将保持与开发人员库完全相同的行为。

开发人员的组件可以定义限制，但方式很好。 一个常见问题通常是将图标用作链接，而不是将图标包装在按钮组件中。 如果我们只使用库中的一个图标，它会被锁定，用户可能无法添加交互：

或者，下面的图标按钮允许交互。 这使我们能够真正细化和控制哪些组件应该与哪些组件交互，哪些不应该； 从标准和可访问性的角度来看。

有了这些类型的限制，设计系统团队就可以轻松地以正确的方式使用组件，如果它被覆盖，从图层面板中可以明显看出某些东西是定制的。

不可触摸

当您准备好移交给开发人员时，完成的原型可以显示每个组件及其配置，以便复制并粘贴到开发人员的工具中并快速构建项目。 如果您的团队还没有组件库，则 UXPin 带有一个默认库，或者您可以轻松地导入一些直接在 UXPin 中可用的公共库。

可访问性

说到可访问性，它经常被忽略或者没有足够的时间来创建关于所有meta标签、 aria标签等的文档。 设计人员不知道他们需要输入什么标签，开发人员也不想经历这些麻烦。

使用 UXPin，我们可以公开多个属性，甚至是界面可能永远不可见的元级数据，例如 ARIA 标签。 然后设计师可以输入所有需要的信息（或者如果你有幸在你的团队中有一个文案），产品开发人员实施的开销很少甚至没有。

布局、模板和网格

只需阅读标题，您就知道接下来会发生什么，而且我敢肯定您现在正在椅子上弹跳——我知道我是。 网格、布局甚至页面模板都可以作为“组件”拉入库中，它允许用户将组件带入页面的活动区域，并允许开发库处理所有间距。

通用模板（例如登录屏幕、完成页面、表单、个人资料页面等）也都可以用作拖放组件。 谈论加快流程并减少设计中的人为错误！

结束时

如果您准备好迈出这一步，那么尝试新软件和新流程来改善您的工作流程永远不会太晚。 毕竟，我们都希望变得敏捷并尽可能地采用。 让我们在团队之间建立更牢固的关系，减少工作量并提高工作效率。 使用像 UXPin Merge 这样的工具，我们更接近于一个更加无缝的工作环境。