用户界面设计的未来：下一代 UI 工具

自第一代 Adob​​e Photoshop 以来，UI 设计工具已经走过了漫长的道路，这是一个旨在编辑照片而不是创建动态用户界面的程序。 当前一代的工具，例如 Adob​​e XD、Figma 和 Sketch，让我们的工作变得更轻松、更快捷。

然而，我们日常工作流程的低效率比比皆是，当我们可以设计人们想要使用的产品时，我们正在浪费宝贵的时间和资源。 今天可用的设计程序比我们开始使用的程序要好，但它们未能利用当前的技术，并阻止我们充分发挥作为 UI 设计师的潜力。

是时候使用新一代的 UI 工具了。

集成设计和代码

未来的用户界面工具将设计和代码结合在一起，为设计人员和开发人员提供更加无缝的体验。 我们当前的工具并不能帮助我们设计 Web UI； 他们正在帮助我们设计 Web UI 的抽象表示。 Figma 和 Sketch 制作的模型与源代码断开连接。

今天，许多设计师都知道 HTML 和 CSS 的基础知识。 一些强硬派在代码中进行设计，但这对复杂的项目无效； 设计师需要能够在承诺之前快速探索概念验证。

软件开发人员拥有 Visual Studio Code，这是一种将代码编辑和开发结合起来的工具，允许工程师在同一环境中构建、测试和调试代码。 同样，设计人员需要一个可视化开发环境，该环境既能提供完整的设计功能，又能生成可用于生产的代码。

这就是未来的发展方向。

并行创建将取代设计/开发人员交接

设计师和开发人员之间有太多的来回，尤其是在交接阶段。 在某些情况下，交接非常耗时且令人筋疲力尽，以至于工作质量受到影响。 随着下一代设计工具与源代码交互，开发人员将不再单独负责构建 UI。 相反，他们将能够专注于开发将产品的 UI 连接到其后端并使其正常运行的逻辑架构。

设计师将使用嵌入的代码奠定 UI 的基础，开发人员将在此代码的基础上为产品注入活力。 设计师不再需要用诸如“请添加 16 像素而不是 8 像素的填充，如模型中所示”之类的请求来唠叨开发人员。 开发人员不必停下来提出设计问题，例如“该组件应如何在平板电脑和台式机断点之间扩展？”

相反，设计人员和开发人员将在更重要的问题上合作，例如设计方法在给定时间和预算的情况下是否可行，或者是否所有 UI 组件的状态都已得到解决。

设计 UI 工具和开发人员软件将保持一致

当前的工具依赖于定制的编程模型来生成设计组件。 这些模型通常不如 CSS 强大，并且不允许设计人员查看其设计文件下的自动生成代码——这些代码最终必须导出为 HTML、CSS 或 JavaScript。 如果我们的工具原生使用 HTML 和 CSS 会简单得多。

例如，CSS 使用盒子模型，它要求将每个页面上的 HTML 元素放置在一个盒子内，该盒子被编码以定义其高度、宽度、边框和填充。 Figma 通过其自动布局功能接近提供此功能。 但如果 Figma 使用已经为大多数 Web UI 提供支持的盒子模型，开发人员将需要更少的翻译和导出。

样式继承也是如此，它控制在没有为特定元素指定样式时发生的情况——类似于默认值。 CSS 使用它，但大多数不是为特定于 Web 而创建的设计工具都没有。

我们需要我们的工具来输出 Web 视图，而不是静态画板或模型。 我们不需要 HTML 和 CSS 模拟器。 我们需要 HTML 和 CSS。

模型将过时

与其扔掉模型，不如把模型扔到门外。

模型留下了太多没有答案的问题。 为每个数字环境设计一个是不可行的。 今天，设计师为 320 像素、834 像素和 1440 像素的屏幕宽度构建布局； 但是如果部分布局在 1220 px 视口上中断会发生什么？ 为什么不针对 375 像素进行优化，这是当今较大手机的常见尺寸？

为每个场景创建一个画板是不切实际的，尤其是在考虑所有断点和视图时——更不用说黑暗主题了。 为所有这些变量进行设计会使画板的数量超出合理范围。

模型也是一种资源浪费。 它们的构建非常耗时，并且在数字产品设计中变得不那么突出。 Webflow 已经取消了模型，而是提倡响应式、交互式原型。 （不幸的是，Webflow 仅限于基于 Web 的解决方案并迎合简单的网站）。 虽然一次性交付物在构思过程中可能有意义，但在解决方案阶段它们是一种浪费。

将考虑所有系统状态

所有数字产品的状态都与它们在给定时刻所做的事情相对应——例如，在加载过程中停止或显示错误消息。

必须考虑每种状态，但当前的 UI 工具将这项任务留给了设计人员，迫使他们创建单个组件的多个变体。 开发工具 React 和 Vue.js 允许开发人员轻松调整组件的所有可能状态。 设计工具必须效仿并鼓励设计师——甚至是唠叨他们——以确保所有组件状态都是针对其设计的。

真实数据将取代占位符内容

正如设计师为多种状态创建组件一样，他们也为各种各样的数据进行设计。 UI 设计师需要能够使用实际输入（副本、图像、日期、名称、标题等）来测试他们的组件，这些输入最终将填充到他们的设计中的组件。 目前，设计师只能通过手动将数据复制粘贴到画板上来模拟数据，这是一项极其繁琐的任务。 有一些插件可以帮助自动化这个过程，但它们很麻烦。

要求开发人员评估组件如何处理数据也不是答案。 当组件开始测试时，重新设计它们太费时间了。 如果设计人员无法使用真实数据测试和迭代组件，他们如何知道卡片是否可以使用长标题或根本没有标题？ 他们将如何发现字体不支持阿拉伯字符或网站不支持从右到左阅读的语言？

边缘案例测试将变得更容易

当 UI 工具最终满足所有状态并启用真实数据测试时，设计师将能够更好地预测边缘情况。 创建组件后，设计人员将对它的各种状态进行压力测试，用不同的数据对其进行爆破，以查看它在不同场景中的表现。 这样，UI 将成为设计人员的领域——让开发人员能够专注于修复 JavaScript 或测试 API 等任务。

开发者工具和第三方浏览器扩展的世界将打开

一旦我们的工作采用 HTML 和 CSS，整个扩展生态系统将在设计阶段变得可用，例如用于性能、SEO 和可访问性审计的不可或缺的 Lighthouse，或者模拟设备断点和低网络速度的各种浏览器开发工具。 浏览器工具集在创建和测试生产就绪 UI 方面比 Figma、Sketch 或 Adob​​e XD 中的任何插件更有价值。

设计师和开发人员将并行工作

我将产品开发的当前状态比作厨房，一名厨师试图通过指示另一名厨师做什么来烹饪一道菜：它可能会起作用，但它需要更长的时间并且效率要低得多。 有些公司正在开发基于代码的设计工具——Hadron、Modulz 和 Relate 的产品处于测试阶段。 这些工具的广泛采用将标志着数字产品创造革命的开始。

这也将标志着设计师与开发商关系的根本转变。 随着双方并行工作，产品团队的效率将成倍提高。 开发人员将可以自由地处理 UI 架构的复杂逻辑，而不是浪费时间解释模型或被设计师要求他们将像素微调到完美而陷入困境。 随着设计师成为成功的数字产品的共同构建者，他们对他们的团队和公司将更有价值。