自第一代Adobe Photoshop以来，UI设计工具已经走过了漫长的道路, 用于编辑照片的程序, 没有创建动态用户界面. 当前这一代的工具，如 Adobe XD, Figma, and Sketch，使我们的工作更容易、更快捷.

然而，我们日常工作流程中的低效现象比比皆是, 当我们可以设计人们想要使用的产品时，我们正在浪费宝贵的时间和资源. 今天可用的设计程序比我们开始时的要好, 但他们没能充分利用现有的技术和 prevent us 从实现我们的全部潜能 UI designers.

现在是UI工具走向未来的时候了.

集成设计和代码

未来的UI设计工具将把设计和代码结合在一起，以提供一个更加 为设计人员和开发人员提供无缝体验. Our current tools aren’t helping us design web UIs; they’re helping us design 抽象表示 of web UIs. 在Figma和Sketch中制作的模型与源代码断开连接.

今天，许多设计师都知道HTML和CSS的基础知识. 一些强硬派用代码进行设计, but that isn’t effective for complex projects; designers need the ability to explore a proof of concept quickly before committing to it.

软件开发人员有Visual Studio Code这个工具 unites 代码编辑和开发, 并允许工程师建造, test, 并在同一环境中调试代码. Similarly, 设计人员需要一个可视化开发环境，它既能提供完整的设计功能，又能生成生产就绪的代码.

以下是UI设计的未来.

并行创建将取代设计人员和开发人员之间的交接

太多了 back-and-forth 在设计人员和开发人员之间，特别是在交接阶段. 在某些情况下，交接是如此耗时和累人，以至于工作质量受到影响. 使用下一代设计工具与源代码接口, 开发者将不再单独负责创建新的ui. 相反，他们将能够专注于发展 逻辑架构 将产品的UI连接到后端，并使其正常运行.

设计师将在编写代码时奠定ui的基础, 开发人员将在此代码的基础上为产品注入生命. 设计师不再需要用“请添加16像素而不是8像素的填充”之类的请求来唠叨开发者, 如模型所示.开发商无需停下来 问设计问题 比如“这个组件应该如何在平板电脑和台式机之间扩展。 breakpoints?”

Instead, 设计师和开发人员将在更重要的问题上合作，比如设计方法在给定时间和预算的情况下是否可行，或者是否解决了所有UI设计和开发组件.

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

当前的工具依赖于定制的编程模型来生成设计组件. 这些模型通常不如CSS健壮，并且不允许设计人员看到设计文件底层的自动生成代码——这些代码最终必须导出为HTML, CSS, or JavaScript. 如果我们的工具本地使用HTML和CSS，那就简单多了.

例如，CSS使用 box model, 它要求将HTML元素放置在每个页面上的一个编码来定义其高度的框内, width, border, and padding. Figma通过它的 auto-layout feature. 但是如果Figma使用的是已经支持大多数web ui的盒子模式, 开发者将需要更少的翻译和输出.

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

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

实物模型将会过时

而不是一次性的 mock-ups我们把实物模型扔出去吧.

实物模型留下了太多未解之谜. 为每个数字环境设计一个是不可行的. Today, 设计师为屏幕宽度320像素构建布局, 834 px, and 1440 px; but what happens if part of the layout breaks on a 1220 px viewport? 为什么不优化为375像素，这是当今大屏手机的常见尺寸?

为每个场景创建画板是不切实际的, 尤其是在考虑所有断点和视图时，更不用说黑暗主题了. Designing 因为所有这些变量都导致画板数量的增加.

模型也是一种资源浪费. 它们的构建非常耗时，并且在数字产品设计中已经变得不那么突出. Webflow 已经放弃了实物模型，取而代之的是 advocates for 响应式、交互式原型. (不幸的是，Webflow仅限于基于web的解决方案，适合简单的网站). 虽然一次性交付的成果在构思过程中可能是有意义的, 它们在溶液阶段是一种浪费.

所有的系统状态将被解释

所有的数码产品 states 例如，这与他们在特定时刻正在做的事情相对应, 加载过程中出现失速或显示错误信息.

每个州都必须考虑, 但是现在的UI工具把这个任务留给了设计师, 迫使他们为单个组件创建多个变体. 开发工具 React and Vue.js 允许开发人员轻松地调整组件的所有可能状态. 设计工具必须跟随设计师的脚步，鼓励他们, 甚至-确保所有组件状态都是设计的.

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

正如设计人员为多个状态创建组件一样，他们也为各种各样的数据进行设计. UI设计师需要能够 测试它们的组件 使用实际输入-副本, images, dates, names, titles, 还有更多的东西最终会填充到他们设计的组件中. Currently, 设计人员只能通过手动复制并粘贴到画板中来模拟数据, 极其乏味的工作. There are plugins 这可以帮助自动化这个过程，但它们很麻烦.

要求开发人员评估组件如何处理数据也不是答案. 当组件进行测试时，重新设计它们太耗时了. 如果设计师不能用真实的数据测试和迭代组件, 他们怎么知道一张卡片是有长标题还是没有标题? 他们如何发现字体不支持阿拉伯字符，或者网站不支持从右向左阅读的语言?

边缘情况测试将变得更容易

当未来的UI工具最终满足所有状态并支持真实的数据测试时, 设计师将能够更好地预测边缘情况. 一旦创建了组件, 设计师将对其各种状态进行压力测试, 用不同的数据分析它，看看它在不同场景下的表现. In this way, UI将成为设计人员的领域，使开发人员能够专注于修复JavaScript或测试api等任务.

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

一旦我们的工作依赖于HTML和CSS，整个生态系统 extensions 是否会在设计阶段变得可用，就像不可或缺一样 Lighthouse for performance, SEO, 可访问性审核, 或者各种浏览器开发人员工具，模拟设备断点和低网络速度. 对于创建和测试生产就绪的ui，浏览器工具集比Figma中的任何插件都更有价值, Sketch, or Adobe XD.

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

我把目前的产品开发状态比作一个厨房，一个厨师试图通过向另一个厨师口授该怎么做来做一道菜:这可能行得通, 但它需要的时间要长得多，效率也要低得多. 有些公司正在开发基于代码的设计工具Hadron, Modulz, and Relate 产品处于测试阶段. 这些工具的广泛采用将标志着数字产品创造革命的开始.

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