囚徒困境困境

by Colm Tuite

通过Colm Tuite

设计工具困境 (The Design Tool Dilemma)

详细介绍了设计工具领域中出现的两个相反的叙述。 (A detailed look at two opposing narratives emerging in the design tool space.)

There are two opposing narratives in the design tool space which have been evolving for many years. These narratives reflect two very different schools of thought when it comes to understanding the specific value our tools provide and which direction they should be headed.

在设计工具领域，有两种相反的叙述已经发展了很多年。 当理解我们的工具所提供的具体价值以及应该朝哪个方向发展时，这些叙述反映了两种截然不同的思想流派。

The first narrative is selling the notion that design artefacts can and should be the Single Source of Truth™ for the product. In this narrative, code is secondary—its job is to reproduce the design artefacts as accurately as possible. Platform constraints are mostly ignored in favour of speed and boundless creativity.

第一个叙述是出售一种观念，即设计人工制品可以并且应该是该产品的“真理的唯一来源”。 在这种叙述中，代码是第二位的，它的工作是尽可能准确地复制设计工件。 为了速度和无限的创造力，大多数平台约束被忽略。

Let’s call this the “bridging the gap” narrative.

我们称其为“ 弥合差距 ”的叙述。

The second narrative is centered around the idea that everyone collaborating on a product can and should be contributing to that same product. In this narrative, code is everything—it is the product. Platform constraints are respected and understood. Decisions are made in context and tools embrace their target mediums.

第二个叙述围绕这样一个思想，即每个产品上的每个人都可以并且应该为同一产品做出贡献。 在这种叙述中，代码就是一切，它就是 产品。 平台约束受到尊重和理解。 决策是根据上下文进行的，而工具则包含其目标媒体。

We will call this the “collaborative” narrative.

我们将其称为“ 协作 ”叙述。

So where did these narratives come from? How much sense does each one make? Let’s take a closer look.

那么，这些叙述从何而来？ 每个人有多大意义？ 让我们仔细看看。

叙述1：弥合差距 (Narrative 1: Bridging the gap)

For as long as digital designers have used design tools, we have always had a burning desire to have our ideas realised in production. To own the design process from idea to deployment has always been the holy grail. If you look at the evolutionary timeline of our design tools, you can see this desire manifesting itself.

只要数字设计师使用了设计工具，我们就一直渴望在生产中实现我们的想法。 拥有从构思到部署的整个设计过程一直是圣杯。 如果您查看我们设计工具的发展历程，您会发现这种渴望正在体现。

Around 2005, when my digital design career began, most of us were using either Illustrator or Photoshop to create vector-based illustrations of whatever product we were designing. This remained the status quo for many years—with most design job postings demanding fluency in Adobe’s Creative Suite.

在2005年左右，我的数字设计生涯开始时，我们大多数人都在使用Illustrator或Photoshop来创建我们要设计的任何产品的基于矢量的插图。 多年来一直保持这种状态-大多数设计职位要求Adobe的Creative Suite中的流利性。

Until one day, in 2010, Sketch arrived and shook the tree. Sketch was simpler, cheaper and much more focused. Of course, designers fought it at first, but ultimately found its clean UI and refined feature set refreshing.

直到2010年的一天，Sketch到达并摇了摇树。 素描是更简单，更便宜和更集中。 当然，设计人员一开始会与之抗争，但最终发现其简洁的UI和精致的功能集令人耳目一新。

Then more recently, Figma arrived. Figma expanded on the revolution that Sketch started. The feature set is very similar, but in terms of execution, I don’t think it’s close. Almost every feature has been surprisingly well implemented. Shockingly well, even.

然后最近，Figma到达了。 Figma扩展了Sketch开始的革命。 功能集非常相似，但是就执行而言，我认为它并不接近。 几乎每个功能都已实现了令人惊讶的良好实现。 甚至令人震惊。

Prototyping tools added an extra layer of realism—taking the static pictures our design tools exported and stitching them together, simulating touch events and screen transitions.

原型工具增加了一层真实感-拍摄我们设计工具导出的静态图片并将它们拼接在一起，以模拟触摸事件和屏幕过渡。

But there was still an observable gap to be bridged between design and development workflows. How could we take the next step?

但是，在设计和开发工作流之间仍存在可弥补的空白。 我们如何才能下一步？

The controversial “Developer Handoff”, of course. InVision and Abstract launched “Inspect”. Avocode, Marvel and Zeplin released “Handoff”. Figma and Sketch attempted to export CSS. The idea being that when designers had something worth sharing, they could hand their work off to developers in a format that developers understood.

当然，有争议的“开发者交接”。 InVision和Abstract发起了“检查”。 Avocode ， 奇迹和Zeplin发布的“切换”。 Figma和Sketch尝试导出CSS。 这样的想法是，当设计师拥有一些值得分享的东西时，他们可以将其工作以开发人员可以理解的格式交给开发人员。

The most recent notch on this timeline has been a new breed of tools promising to convert static pictures into production code. Supernova Studio, Rapid UI, PageDraw, Teleport, Sketch2React and Anima Launchpad are just a handful of the startups leading this charge.

此时间轴上的最新标记是一种新工具，有望将静态图片转换为生产代码。 Supernova Studio ， Rapid UI ， PageDraw ， Teleport ， Sketch2React和Anima Launchpad只是少数领导这项收费的创业公司。

At first glance, you may not notice anything unusual about this timeline. Our tools have just been improving exponentially, as one might expect. They’re becoming more performant, more robust, and more feature-rich. If you limit your outlook to the past 10 years, this all seems like a natural progression.

乍一看，您可能不会注意到有关此时间表的任何异常情况。 正如人们所期望的，我们的工具正在呈指数级改进。 它们正在变得越来越高性能，更强大并且功能更加丰富。 如果您将眼光限制在过去的十年中，这一切似乎都是自然而然的过程。

But go back just a little further and you will notice something very peculiar.

但是再往前走一点，您会发现一些非常奇怪的东西。

Let’s journey back, for a moment, to a time when print was the primary form of marketing communication. It was a simpler time. Endless debates about tools or frameworks were kept to a minimum. Occasionally, some upstart would mention QuarkXPress but the rebellion never lasted long. Most design professionals used Illustrator, Photoshop and InDesign. Adobe ruled the roost and that was that.

让我们回到片刻是行销沟通的主要形式的时代。 那是一个更简单的时间。 关于工具或框架的无休止的辩论被减至最少。 有时，一些新贵会提到QuarkXPress，但反叛活动并未持续很长时间。 大多数设计专业人员使用Illustrator，Photoshop和InDesign。 Adobe称雄，仅此而已。

Most notably though, designers were designing the end product, not imitations of it—the end product being stationery, posters, books, brand identities, brochures and other print material. Designers had direct influence over the product they were designing.

不过，最值得注意的是，设计师是在设计最终产品，而不是模仿它—最终产品是文具，海报，书籍，品牌标识，小册子和其他印刷材料。 设计师对其设计的产品具有直接影响。

This was possible because print designers had (and still have) a good command of the medium they were designing for. There was a close correlation between input and output constraints.

这是可能的，因为印刷设计师已经(并且仍然)很好地掌握了他们要设计的介质。 输入和输出约束之间存在密切的相关性。

For example, print designers knew there would be slight differences in how colours might be reproduced on a thick card stock as opposed to a lighter 120gsm letterhead. Designers were responsible for adding 3mm bleed and trim marks to accommodate inaccuracies in printer alignment. Designers were aware of turnaround times — they knew that fancy effects like debossing or hot foiling were more costly to reproduce.

例如，印刷设计师知道，较厚的卡片纸与较轻的120gsm信头纸相比，在较厚的卡片纸上复制颜色的方式会有细微的差异。 设计人员负责添加3mm的出血和修整标记，以适应打印机对齐中的不准确之处。 设计师意识到周转时间-他们知道像凹坑或热烫纸这样的奇特效果制作起来成本更高。

Especially when the digital print revolution arrived, many designers began investing time and money in learning as much as they could about the print medium. Print design software embraced the medium and catered to it.

尤其是在数字印刷革命到来之时，许多设计师开始投入时间和金钱来尽可能多地学习印刷介质。 平面设计软件接受并迎合了这种媒介。

Then at some point, web design became the primary focus and millions of print designers became web designers overnight.

然后在某个时候，网页设计成为主要焦点，数百万印刷设计师一夜之间成为网页设计师。

I’m not knocking this shift in focus. I myself made the transition from print to digital. Many of the skills graphic designers study are transferrable to other industries, and I love to see people expanding their horizons.

我没有把重点转移。 我本人已经从印刷向数字过渡。 平面设计师学习的许多技能都可以转移到其他行业，我喜欢看到人们扩大视野。

The issue was that we now had very little knowledge of the new medium we were designing for. Rather than spend time understanding this new medium, we tried to tame it. This became evident as we struggled to fit everything into a 960px container, referred to interfaces as “pages” and coined terms like “brochure website”.

问题是我们现在对要设计的新媒体知之甚少。 我们没有花时间去理解这种新媒介，而是试图驯服它。 当我们努力将所有内容装入一个960px的容器中时，这一点就变得明显了，这些容器被称为“页面”和诸如“宣传网站”之类的术语。

Most designers couldn’t write code, so we did what we could: draw pictures. To do it, we used the thing that had served us well for decades before: our graphic design software.

大多数设计师无法编写代码，因此我们做了我们可以做的事情：绘制图片。 为此，我们使用了几十年来一直为我们服务的东西：我们的图形设计软件。

Designers were no longer designing the end product, but imitations of it.

设计师不再设计最终产品，而是模仿它。

This paradigm shift went unaddressed for a long time, because image-based design was still very much a crucial part of designing for the web. Many of you will fondly remember creating enormous sprite sheets to hack effects like gradients and rounded corners. Rollover buttons, anyone?

这种范式转换很长一段时间都没有解决，因为基于图像的设计仍然是Web设计中至关重要的一部分。 你们中的许多人会深切地记得创建大量的Sprite表来破解渐变和圆角等效果。 滚动按钮，有人吗？

Fast forward to today, though, and image-based hacks have been completely displaced by CSS. Even the use of raster images as a form of communication is subsiding in favour of more performant and/or more immersive assets like CSS animations, SVG illustrations, and video.

但是，快速发展到今天，基于图像的黑客已经完全被CSS所取代。 甚至使用光栅图像作为一种交流形式，也逐渐取代了更高性能和/或更身临其境的资产，例如CSS动画，SVG插图和视频。

Today, the correlation between the web and print is about as close as the correlation between the web and architecture.

如今，网络与印刷品之间的相关性与网络与架构之间的相关性几乎一样。

Unfortunately, our tools haven’t adapted fast enough. Our current crop of digital design tools are very much an extension of print design tools. Young designers are enthusiastically learning digital design through the lens of static drawing tools.

不幸的是，我们的工具调整得不够快。 我们当前的数字设计工具非常多，是印刷设计工具的扩展。 年轻的设计师们正在通过静态绘图工具的镜头热情地学习数字设计。

Sure, there have been some impressive advancements, but for the most part, they are still just vector-based drawing tools optimised for illustration. Because of this, our tools lack the context and nuance necessary to make informed design decisions.

当然，已经有了一些令人印象深刻的进步，但是在大多数情况下，它们仍然只是针对插图进行了优化的基于矢量的绘图工具。 因此，我们的工具缺乏做出明智的设计决策所必需的上下文和细微差别。

叙述2：合作 (Narrative 2: Collaboration)

Rather than encourage drawing imitations of the end product, this narrative advocates taking code and making it easier to digest so that whole teams can collaborate on it.

这种叙述不是提倡模仿最终产品，而是提倡采用代码并使其易于消化，以便整个团队可以在其上进行协作。

Strangely, the origin of both narratives can be traced back to around the same time. Adobe Dreamweaver, the infamous WYSIWYG visual code editor, arrived on the scene in 1997. Softpress Freeway arrived a year earlier in 1996, and Microsoft Frontpage even earlier in 1995, just 5 years after Photoshop and more than a decade before Sketch.

奇怪的是，这两种叙述的起源都可以追溯到大约同一时间。 臭名昭著的WYSIWYG可视代码编辑器Adobe Dreamweaver于1997年问世。Softpress Freeway于1996年初问世，Microsoft Frontpage于1995年初问世，距Photoshop仅5年，而Sketch则早10多年。

Unfortunately, these tools were often more of a hindrance than a help. They were optimised for exporting to production, making them too cumbersome for the design process.

不幸的是，这些工具通常更多地是阻碍而不是帮助。 它们针对出口到生产进行了优化，这对于设计过程来说太麻烦了。

Gradually, a wave of designers, including myself, ditched the WYSIWYG editors in favour of a less restrictive design tool: the text editor.

渐渐地，包括我自己在内的一波设计师放弃了所见即所得的编辑器，转而使用一种限制性较小的设计工具：文本编辑器。

For a long time, typing code was pretty gnarly. But over time, a healthy eco-system of tools began to sprout around code, significantly lowering the barrier-to-entry. Today, we have code-based design tools which don’t require any coding knowledge at all.

长期以来，键入代码非常粗糙。 但是随着时间的流逝，一个健康的工具生态系统开始在代码周围萌芽，大大降低了进入的障碍。 今天，我们有了基于代码的设计工具，这些工具根本不需要任何编码知识。

Let’s take a closer look at the evolution of code-based design tools so far.

到目前为止，让我们仔细研究一下基于代码的设计工具的发展。

Code formatting and syntax highlighting were some of the first “tools” focused on making code more digestible. Applying colour and structure improved readability and scannability. Recently, tools like Prettier have automated this.

代码格式化和语法高亮显示是最早的一些“工具”，致力于使代码更易消化。 应用颜色和结构可以提高可读性和可扫描性。 最近，像Prettier这样的工具已经使它自动化。

Preprocessors and templating languages arrived around 2006. Tools like Haml, Sass, LESS, CoffeeScript and others improved code manageability even further by encouraging brevity, abstracting some of the visual complexity, and automating some of the more common tasks.

预处理器和模板语言大约在2006年问世。诸如Haml，Sass，LESS，CoffeeScript之类的工具通过鼓励简洁，抽象化一些视觉上的复杂性以及自动化一些更常见的任务，甚至进一步提高了代码可管理性。

JSX is a JavaScript syntax extension developed by Facebook which looks not too dissimilar to the template languages that came before it. React’s component API also helps to promote reuse and abstract visual complexity, again, helping our cause of making code more digestible and accessible.

JSX是Facebook开发JavaScript语法扩展，看起来与之前的模板语言并不太相似。 React的组件API还有助于促进重用和抽象的视觉复杂性，再次帮助我们使代码更易于消化和访问。

More recently, we are seeing tools remove barriers-to-entry like having to set-up dev environments and tinker with the command line etc. Compositor ISO and SEEK’s Style Guide Sandbox are doing some amazing work here.

最近，我们看到工具消除了进入壁垒，例如必须设置开发环境并修改命令行等。CompositorISO和SEEK的样式指南沙箱在这里做了一些了不起的工作。

Modulz (a design tool I’m building) and UXPin are also making code more accessible by removing barriers-to-entry. These tools visualise JSX, using familiar layers to represent it and a GUI for manipulating component props.

Modulz (我正在构建的设计工具)和UXPin还通过消除入门障碍，使代码更易于访问。 这些工具使用熟悉的层来表示JSX以及用于操纵组件道具的GUI来可视化JSX。

Polypane are building a smart design environment where you can preview your designs across a multitude of browsers, devices and viewports. Another example of a workflow which considers the full context of the target medium.

Polypane正在构建一个智能设计环境，您可以在其中跨多个浏览器，设备和视口预览设计。 考虑目标媒体的完整上下文的工作流的另一个示例。

These visual code editors are simply the next step in the progression of making code easier to write. All of this innovation makes sense and is possible because a huge portion of front-end development is inherently visual.

这些可视化代码编辑器只是使代码更易于编写的下一步。 所有这些创新都是有意义的，并且是可能的，因为前端开发的很大一部分本质上都是可视的。

Spoiler alert: I agree with Jason’s prediction. Browser dev tools have already begun to move in this direction, offering GUIs for visually manipulating CSS styles like transitions, shadows, and colour.

剧透警报：我同意杰森的预测。 浏览器开发工具已经开始朝这个方向发展，提供用于可视化操纵过渡，阴影和颜色等CSS样式的GUI。

Of course, browser dev tools operate on compiled code, but these same visual tools can apply to precompiled code, too. Compositor Lab and Modulz Editor make it easy to edit React components visually.

当然，浏览器开发工具可以在已编译的代码上运行，但是这些相同的可视化工具也可以应用于预编译的代码。 Compositor Lab和Modulz Editor使得可视化编辑React组件变得容易。

Xcode is a hugely underrated tool—allowing teams to design, develop, test and debug their products through a combination of code editing and direct manipulation.

Xcode是一个被大大低估的工具，它使团队可以通过组合代码编辑和直接操作来设计，开发，测试和调试产品。

Airbnb’s Lona is one of the most promising visual code editors I’ve seen. Lona Studio provides a graphical interface for building component systems, mocking up new screens from existing components, previewing designs with real data, experimenting with multiple screen sizes, and much more.

Airbnb的Lona是我见过的最有前途的视觉代码编辑器之一。 洛纳Studio提供了建筑构件系统，从现有的组件嘲讽了新的画面，真实的数据预览设计，具有多种屏幕尺寸试验，以及更多的图形界面。

This same progression can also be observed in other industries like game design, music production, architecture, video editing, etc. Among others, Maya, Unity, Cubase, Logic Pro and Final Cut all provide tools for direct manipulation so whole teams can collaborate on the same product.

在游戏设计，音乐制作，建筑，视频编辑等其他行业中也可以观察到同样的进展。其中， Maya ， Unity ， Cubase ， Logic Pro和Final Cut等都提供了直接操纵的工具，因此整个团队可以在相同的产品。

While each of these tools functions at a different level of abstraction, they all share the same goal: to make code more digestible, more manageable, more visual, and more accessible to a wider audience.

尽管这些工具中的每个工具在不同的抽象级别上起作用，但是它们都具有相同的目标：使代码更易消化，更易管理，更可视化，并且更广泛的读者可以访问。

Though these tools may look very different, the underlying concept remains constant. There is no fundamental paradigm shift. There is no duplication of work. No wasted effort. There are no fake simulations or inaccurate renderings. There is no lack of context. There is just code, in many forms.

尽管这些工具看起来可能大不相同，但基本概念保持不变。 没有根本的范式转换。 没有重复的工作。 没有浪费的精力。 没有伪造的模拟或不正确的渲染。 不缺少背景。 只有代码，形式很多。

By continuing with this narrative, we can expose UI designers to the reality of the mediums we’re designing for, while hiding all of the irrelevant complexity, enabling ourselves to make well-informed design decisions.

通过继续这种叙述，我们可以使UI设计人员了解我们要设计的媒介的真实性，同时隐藏所有不相关的复杂性，从而使我们能够做出明智的设计决策。

困境 (The dilemma)

Design teams, companies, and investors have invested huge amounts of both time and money in supporting a broken design process: the traditional image-based workflow.

设计团队，公司和投资者已投入大量时间和金钱来支持破碎的设计过程：传统的基于图像的工作流程。

An entire industry has been built upon this shaky foundation: tools to draw pictures, tools to add interactions to pictures, tools to version pictures, tools to store pictures, tools to extract data from pictures. Each of them attempting to make these static imitations seem more like the real product—as if by layering simulations on top of simulations we could somehow bridge the impossible distance between vector graphics and interactive software.

在这个不稳定的基础上已经建立了整个行业：绘制图片的工具，向图片添加交互的工具，版本图片的工具，存储图片的工具，从图片提取数据的工具。 他们每个人都试图使这些静态模仿看起来更像真实的产品-好像通过将模拟分层放在模拟之上，我们可以某种方式弥合矢量图形和交互式软件之间不可能的距离。

Today, our digital products are embracing increasingly complex technologies: micro-interactions, animations, AR, VR, voice input, audio output, video, multiple pixel-densities, infinite viewport dimensions, brightness detection, etc. As designers continue to explore these new territories, vector-based drawing tools will continue to be exposed for their shortcomings.

如今，我们的数字产品正在拥抱日益复杂的技术：微交互，动画，AR，VR，语音输入，音频输出，视频，多个像素密度，无限的视口尺寸，亮度检测等。随着设计师不断探索这些新技术在领土上，基于矢量的绘图工具将继续存在缺点。

Consider how the design landscape might change over the next five years. How will each of these narratives play out? To get an accurate sense, I think it’s best to go back to basics and ask ourselves some tough questions.

考虑一下未来五年设计格局可能会如何变化。 这些叙述将如何发挥作用？ 为了获得准确的理解，我认为最好回到基础知识并问自己一些棘手的问题。

What does it mean to design digital products today? Which aspects of design ought a design tool expedite, automate, or simplify?

今天设计数字产品意味着什么？ 设计工具应加快，自动化或简化设计的哪些方面？

I still remember how Rebekah Cox, one of my all-time favourite designers, defined what product design meant at Quora in the early days.

我仍然记得我一直以来最喜欢的设计师之一丽贝卡·考克斯(Rebekah Cox)如何在早期定义Quora产品设计的含义 。

“A user interface is the product of a design. A design is a set of decisions about a particular product.” — Rebekah Cox

“用户界面是设计的产物。 设计是针对特定产品的一系列决策。” —丽贝卡·考克斯(Rebekah Cox)

It’s been almost a decade since I first read this definition of design, but it stuck with me all those years. It was the first time I understood that an interface is the result of the design, not the design itself. The design is the set of decisions that led to the product.

自从我第一次阅读设计的定义以来，已经过去了将近十年，但这些年来，它一直困扰着我。 这是我第一次了解接口是设计的结果，而不是设计本身。 设计是导致产品的一系列决策。

So, if design is a set of decisions, which decisions go into designing the digital products of today? Here’s a small sample off the top of my head:

因此，如果设计是一组决策，那么设计当今的数字产品需要考虑哪些决策？ 这是我脑海中的一个小样本：

• How should a button behave when hovered, pressed, focused, or disabled?当鼠标悬停，按下，聚焦或禁用时，按钮应如何表现？
• How should this UI behave when there is no data to populate it?当没有数据可填充时，此UI应该如何表现？
• How will this UI cope when populated with unusually long data strings?当用异常长的数据字符串填充时，该用户界面将如何应对？
• In which order should elements receive focus when tabbing through?遍历时元素应以什么顺序获得焦点？
• Should any keyboard shortcuts be available to interact with this UI?是否有任何键盘快捷键可用于与此UI交互？
• Should any voice commands be available to interact with this UI?是否有任何语音命令可用于与此UI交互？
• Should any sounds play while interacting with this UI?与该用户界面交互时，是否应该播放任何声音？
• How will this colour or font render across all of the most common permutations of browsers, browser versions, and operating systems?这种颜色或字体如何在浏览器，浏览器版本和操作系统的所有最常见排列中呈现？
• How will the tiny change I’m making to this button component impact other areas of the product?我对此按钮组件所做的微小更改将如何影响产品的其他区域？
• How should x component behave when its data has not yet loaded?x组件尚未加载数据时应如何表现？
• How should x component behave while its data is loading?x组件在加载数据时应如何表现？
• How should this layout adapt to the web’s infinite array of possible viewport dimensions, aspect ratios, and pixel densities?这种布局应如何适应网络的无限可能的视口尺寸，纵横比和像素密度的数组？

These are the kinds of decisions that digital product designers mull over daily. Not only must we make these decisions, but we must test them, scrutinise them, communicate them, and sell them.

这些都是数字产品设计师每天都会考虑的决策。 我们不仅必须做出这些决定，而且还必须测试它们，仔细检查它们，传达它们并出售它们。

But such nuanced product decisions cannot be captured in a collection of vectors, even with interactions layered on top.

但是，即使交互作用位于顶层，也无法将这些细微的产品决策捕获到矢量集合中。

Earlier, I referred to “developer handoff” as being controversial. What I was getting at is this: the heavily promoted workflow of going from static mockups to code makes little sense considering the vast differences between the two mediums.

之前，我提到“开发人员移交”是有争议的。 我要说的是：从静态模型到代码的大力推动的工作流程，考虑到两种媒介之间的巨大差异，这毫无意义。

The problem with “developer handoff” is not in the name. Nor is the problem in the implementation. Even the notion of designers passing their work along the production line is conceptually sound.

“开发者移交”的问题不在名字上。 实施中的问题也不是。 甚至设计师将他们的工作沿着生产线传递的想法在概念上也是合理的。

The problem is that there is nothing useful to “handoff”. Getting the information out of the vectors is not the hard part. Honestly, most of it is useless anyway. It’s getting the necessary information in that’s the challenge. This is the reason that vector-based drawing tools are not well-suited to UI design. Vector graphics are physically incapable of holding the kind of information necessary to adequately inform the design of a digital product.

问题在于“移交”没有任何用处。 从向量中获取信息并非难事。 老实说，大多数情况还是没有用的。 它正在获取必要的信息，这就是挑战。 这就是基于矢量的绘图工具不适用于UI设计的原因。 矢量图形在物理上无法保存充分告知数字产品设计所需的信息。

But even if we could somehow pack these decisions into vector graphics, illustration tools do not provide an environment conducive to making key decisions about a digital product. You cannot make well-informed product design decisions in an environment that lacks any context of the medium you’re designing for.

但是，即使我们能够以某种方式将这些决策整合到矢量图形中，插图工具也无法提供有利于做出关于数字产品的关键决策的环境。 在缺少您要设计的媒体的任何上下文的环境中，您无法做出明智的产品设计决策。

These are the decisions that make or break digital products. If you want to be the one to make these decisions, you must become familiar with the many environments in which your product will exist.

这些是决定或破坏数字产品的决定。 如果要成为做出这些决定的人，则必须熟悉产品将存在的许多环境。

“Production code is a surrogate for decision-making power. Production code is the source of truth. It is the realtime sum total of all the conversations, all the decisions, all the politics…it is everything. Whoever is pushing code to production is running the product. Everyone else only has influence.” — Rebekah Cox

“生产代码是决策权的替代品。 生产代码是真理的源头。 它是所有对话，所有决策，所有政治活动的实时总和……这就是一切。 谁将代码推向生产环境，谁就会运行该产品。 其他所有人只有影响力。” —丽贝卡·考克斯(Rebekah Cox)

Rebekah proposes that the people with the most decision-making power are those closest to the code.

丽贝卡建议，拥有最大决策权的人是最接近守则的人。

If our design tools are to provide us with the same level of product influence that developers have enjoyed exclusively for decades, they need to move on from the broken workflows of the past and continue to embrace the interactive mediums of the future.

如果我们的设计工具能够为我们提供与开发人员几十年来一样独特的产品影响力，那么他们就需要从过去繁琐的工作流程中继续前进，并继续拥抱未来的交互媒体。

If you’re interested in Modulz, the new design tool I’m working on, we post regular updates on Twitter. If you want to chat about tooling or systems, feel free to reach out to me via email or Twitter.

如果您对我正在使用的新设计工具Modulz感兴趣，我们会在Twitter上定期发布更新。 如果您想谈论工具或系统，请随时通过电子邮件或Twitter与我联系。

Shoutout to Dave Feldman, Adam Morse, Scott Raymond, Patrick Smith, Michael Le, Kilian Valkhof, David Tuite and others for helping out with editing.

向Dave Feldman，Adam Morse，Scott Raymond，Patrick Smith，Michael Le，Kilian Valkhof，David Tuite等人大声疾呼，以帮助他们进行编辑。

翻译自: https://www.freecodecamp.org/news/the-design-tool-dilemma-225541c4ad1d/

囚徒困境困境