在数字产品设计与开发领域，开发与设计之间的不匹配问题一直是行业内的痛点。设计师使用自由度极高的画布工具进行创作，而开发人员则需要在规则严格的开发环境中实现这些设计。这种差异不仅导致了交接过程中的摩擦和错误，还浪费了大量时间和精力。本文将深入探讨开发与设计不匹配的根本原因，并分析现有的解决方案及其局限性。同时，作者将分享对未来设计工具的展望，探讨如何通过工具的改进来更好地支持协作，提升设计与开发的效率和质量。

用户界面设计师使用没有约束的画布工具，设计那些基于规则的交互系统，然而，期望开发人员在研发环节中完善所有内容。这往往导致设计师和开发人员之间产生隔阂。

数字产品设计和开发领域一直存在 2 个问题。第 1 个问题还比较显而易见，因此，不出意外，受到了大量的关注，并且，也衍生出很多还算合理的阶段性解决方案。然而，第 2 个问题就显得更为深层、微妙，因此，也更容易被忽视。

我们先从第 1 个问题说起：交接问题

实际上，交接过程之所以是一个主要问题，有好几个原因：

在交接过程中的摩擦以及可能会出现的错误。这一点导致实际编码的产品与设计师在设计工具中所表达的意图产生偏差。唯一重要的是真实用户对实际产品的体验。如果在最终的产品中无法将设计完美呈现，那么，这将会使整个过程变得低效且令人沮丧。

交接过程浪费了设计师和开发人员大量的时间。为了正确构建界面，编码和解码所有相关信息，这需要耗费大量的精力。设计师必须通过规格说明、示例、注释和文档过度沟通（这些看似必要，但确实很冗余），同时，开发人员则必须以一种偏执的、近乎侦探级别的警觉来查看设计文档，有时候，甚至还需要眯起眼睛，以免遗漏任何一个设计细节。

将设计文档交给开发人员从头开始构建，会创造一个萎缩的产物。一旦代码上线，它就会与设计文件产生偏差，从而引发一场永无止境的对齐竞赛，以确保设计文件与“现实”保持一致。这种对齐过程不可避免会被打破，不信任就此产生。开发人员看到旧版本的设计文档的时候，下意识就会认为忽略这些似乎与“现实”脱节的部分是理所当然的。结果，设计师变得高度警惕，不断寻找设计与“现实”之间不一致的地方。当开发人员选定某个组件库作为基础的时候，虽然加速了研发的效率，与此同时，与设计文档不一致的情况也就会经常发生。

交接设计迫使设计师在他们通常不太喜欢或不太重视的事情上浪费他们的时间。详细说明并记录文本字段，明确标注在产品中应该如何呈现的所有方式，这些事情往往让设计师觉得很细碎、很繁琐。尤其，当他们知道这事项并非是实际要构建的产品，而仅仅是一个一次性的产物。同样，这也迫使前端开发人员专注于那些没什么乐趣或意义的任务。在代码中重现已设计好的界面，通常还要追着设计师确认当窗口变大或变小时各项内容元素应如何重新排版，这些事同样对他们而言毫无乐趣。

由于交接过程所产生的问题基本都是比较显而易见的，同时，产品设计和研发人员都希望能够解决这些问题，无论在过去还是现在，这一呼声都是很高的。

于是，市面上逐渐构建出 2 种不同方向的解决路径：

其中 1 条路径：是针对最流行的画布式设计工具开发辅助应用程序。起初出现一些以视检为核心功能的工具（例如： Avocode、Zeplin、Simpli 和 Abstract、蓝湖、摹客）。随后，主流的设计工具开始陆续增加了视检功能（例如 Figma、Sketch、XD 和 InVision 中的开发模式）。之后，也出现了专门的工具，主要是以文档编写（例如： Zeroheight 和 InVision 的 DSM ）。在 Sketch 和 Figma 的上线插件市场后，也涌现出了很多对应的插件（例如： Anima、Locofy 以及其他“Figma 转 HTML”插件工具）。

另 1 条路径在本质上则截然不同。它试图通过打造新一代的设计工具来实现彻底消除交接过程，这些工具主张能够自行“端到端交付”，几乎不需要或完全不需要开发人员的协助。如今，最突出的代表工具当属 Webflow 和 Framer，然而，在市面上，此类工具种类很多，我们可以追溯到 25 年前的 Dreamweaver 。

然而，这些无代码/低代码工具存在 1 个巨大的问题，过去如此，现在依然如此，它们所构建的方式不仅消除了开发与设计师之间的交接过程，还消除了对开发人员本身的需求（简而言之，就是不要开发人员了）。但是，这就自然会导致这些工具所能让设计师端到端构建的产品的复杂性设置了限制（上限相当低，复杂的产品根本搞不定）。众所周知，商业上取得成功的更多集中在网站构建工具和平台，然而，原生 iOS/Android 或 Web 应用构建工具则始终无法突破（目前我只知道 Play for iOS 和 Draftbit）。我个人认为，主要原因在于应用程序的复杂逻辑超出了无代码工具所能提供的交付能力。在过去的几年里，一些垂直类工具，例如 Framer、Webflow、Builder.io 开始通过构建新的“桥梁”，通过使用插件，从 Figma 等画布工具导入设计资产。

因此，解决交接问题的路径上在其核心处还存在一个权衡：

要么，拥有一个通用的画布工具，能允许设计师们设计出世界上最复杂的应用程序，但是，设计交付只是一个半成品，还需要交接开发；要么，拥有一个专属的构建工具，能让设计师能够自行设计和开发，但是，设计师想要创建的复杂程度较高的产品就会受到限制。

据我所知，市面上只有 2 款设计/开发工具成功采用了不同的、统一策略。

Flash（由 Macromedia 开发，后被 Adobe 接手，最终被史蒂夫·乔布斯终结）

Visual Studio 的 Blend 工具，使用微软的 XAML 和 WPF 平台。

Flash 拥有 ActionScript，允许同一个对象既可以由设计师自由设计，同时开发者也可以使用 ActionScript 命令对其进行逻辑操作。这种设置让所有相关专业人士都能发挥所长。设计师专注于重要的体验和视觉的重要元素。也就是说，设计师不需要向开发人员交接任何内容，因为开发人员可以直接针对设计师创建的现有资产进行开发。没有一次性的中间产物，没有交接过程，也没有复杂度的限制。虽然 Flash 并不会辅助编写代码，但是，它允许开发者在设计师的舒适区就能开始接手工作。

Visual Studio 的 Blend 工具也是类似的故事，但使用的文件、结构和逻辑有所不相同。它是一个双环境设置。设计师可以进行设计，而 Visual Studio 开发人员可以针对完全相同的资产进行开发。同样，没有交接过程，没有一次性的中间产物，也没有复杂度限制。

众所周知，Flash 的消亡是因为与其安全性和性能上与 iPhone 不兼容。Blend 和 Visual Studio 现在也已经沦为小众且不流行的工具。在过去 7 年的工具使用情况调查中，我从未见过有人提及它们。与此同时，Figma 几乎占据了整个产品设计市场份额。

🔗 设计师们，我们正面临一个关于“Figma主义”的陷阱

这不得不让我们得出一个结论：即使是采用最佳方法的工具，也不能免于因各种其他原因而失败。商业确实是一场变幻莫测的游戏。

现在，正如我在一开始所说，产品设计和开发领域一直存在 2 个问题。接下来，我们一起探讨一下那个更隐蔽但更为重要的难题。

第 2 个问题：局限问题

简单的基于画布的工具对设计师隐藏了广泛的设计属性。

当前设计工具存在的问题影响深远，但这并非刻意为之。这其实是一种权衡的结果，设计师们过去只看到了“自由创作”这一优点，而忽视了其带来的局限性。设计师们普遍热爱创作自由，我也不例外。

重要的是，作为一名设计师，我们有必要了解我们是如何发展到今天这种在行业中已变得如此普遍的使用画布工具的现状。

我们从一张实体页面开始。平面设计师将纸张、墨水和颜色完美的调配。页面是静态的、具体的、清晰的。随后，图形处理软件出现了，帮助加快了设计速度，Photoshop、Freehand、CorelDraw、Illustrator（以及后来的更多软件）。所有的软件都帮助我们设计印刷品和大多静态的网页资产。之后，发生了一件重要的事情。电脑屏幕尺寸开始多样化。互联网和原生应用不得不适应这一变化。它们引入了响应式单位和规则。在 iPhone 和平板电脑发布之后，这一切变得更加复杂。但设计师，尤其平面设计师和早期的交互设计师们，却已经习惯了页面概念。自然而然，那些已盈利为生的设计工具继续为设计师们提供这种设计方式和体验。直接操作的便捷性（最初是用鼠标和键盘，后来是用手指手势和触控笔）让设计师们感到无比舒适，以至于他们不愿为了其他好处而放弃这种设计方式。但是，这也导致了一种不匹配，工具鼓励设计师拥有自由，而现在的需求却是响应式、系统化、智能化、参数化的设计规则，提供给开发人员来实现。

而这就是产生巨大分歧的地方，因为：

设计工具面临一个两难选择：要么提供完全的创作自由度，要么提供系统化的规则和约束。这两种特性很难在同一个工具中完美共存。

想一下“引力”的基本概念：在 Figma 推出自动布局（auto-layout）功能之前，所有主流的画布工具相比之下都提供了极大的自由度，这意味着无论是向上还是向下都没有“引力效应”。这与网页端以及原生的 iOS 和 Android 环境截然不同。

在传统设计工具中，所有元素默认是完全自由放置的，它们只是按层级堆叠，互不影响。元素之间没有推挤关系，也没有互动。内边距和外边距这些概念形同虚设。添加更多文字时，容器大小也不会自动调整。由于没有类似浏览器窗口的概念，所以无法使用相对于窗口的尺寸计算；甚至百分比尺寸也几乎不会被使用。因此，几乎所有元素都是独立存在的，没有相对关系。

随着时间推移，更适合 UI 设计的工具逐渐出现。Sketch 开创了先河，为后来的 XD 和 Figma 铺平了道路。Sketch 引入了组件系统、样式覆盖机制、将设计框架对应到网页 div 的概念映射，以及更多可调整参数的视觉属性（比如 Figma 中的颜色系统、文字排版、视觉效果和布局网格）。这些创新为设计领域带来了一股新的风暴，但同时也随着工具的发展带来了新的挑战。

具有技术思维的设计师们开始感到压力，纷纷自学编程。这让他们获得了巨大优势，因为通过编程实践，他们对UI实际开发的理解不再停留在表面。设计行业迫切需要更强大的工具，因此主流设计软件（Sketch、Figma和XD）都引入了“自动布局”功能，这实际上是网页开发中 Flexbox 布局的简化友好版本。这种变化就像在一个完全自由的设计画布中，创建了特殊的区域，在这些区域内元素会像网页 DOM 那样相互影响和排列，而这个特殊区域又被包含在更大的自由画布环境中。

这是革命性的。设计师们开始理解内容会如何影响其所在容器的大小。页面元素重新排列的方式变得更加合理，内边距这个概念终于有了实际作用。

有经验的设计师开始几乎完全依赖自动布局来创建他们的用户界面。

请花点时间思考这个现象的意义…

在没有元素间相互影响的设计工具环境中，我们却要创建大量使用自动布局的区域，让元素能够相互影响！如果设计工具的默认状态就像代码环境那样，元素天生就能相互影响，默认就支持自动布局，不是会更简单吗？实际上，网页开发、iOS 和 Android 开发环境本来就是这样工作的。

回顾过去十年的设计工具发展历程，我们可以看到一个明显的趋势：工具正在帮助设计师建立更系统化、更灵活的设计规则。

但是…

我们还未迎来最关键的变革。

对于 UI 设计（组件和页面构建），产品设计师不得不放弃传统的自由画布方式。

我认为，设计和构建数字产品必须与开发平台的实际约束保持一致。作为设计师，我需要能够像开发者一样使用弹性布局、网格系统、内外边距、百分比尺寸、窗口单位等全套工具。我需要能轻松调整窗口大小，并实时查看所有元素如何响应变化。组件应该区分“状态”和“属性”这两个不同概念。组件变体应该基于规则自动生成，而不是手动创建每一个变体。我们应该用设计令牌系统代替简单的样式，建立多层次、可复用的设计参数（如排版系统）。

设计工具的默认设置应该引导我们做出更好的决策，而非仅仅更美观或更简单的决策。它应该防止我们轻易创建出表面看似整洁但实际混乱、不一致且难以维护的系统。在《网络的纹理》中描述了数字界面设计的本质挑战：

“一个没有明确边界的界面，由许多小的、独立的、可变化的元素组成。这些元素来自不同角度，共同构建成一个可理解的整体，呈现出特定时刻的状态。”

数字产品设计有其独特的特性和挑战。我们需要的设计工具应该直面这些复杂性，而不是简化或隐藏它们。作为设计师，我们需要成长和进步，因为高质量的工作流程、良好的设计师和开发者关系、优质的产品以及用户满意度都值得我们投入更多努力。

未来的设计工具必须真正支持协作，而不仅仅是设计交付。大多数复杂产品的开发是离不开开发人员的参与。尽管 AI 工具和无代码平台看起来很有前景，但它们无法完全替代专业开发团队在复杂产品开发中的作用。

我相信设计工具领域的变革即将到来。我和朋友们正在开发一款名为Jux的工具，它体现了这些新理念。虽然目前还处于早期阶段，还有很长的路要走，但我们相信这将是一次真正的革新。