银河土星_设计师来自土星，开发人员来自木星：或者，为什么沟通很重要

最新推荐文章于 2024-10-01 05:04:32 发布

cumian9828

最新推荐文章于 2024-10-01 05:04:32 发布

阅读量607

点赞数

文章标签： python java 编程语言人工智能大数据

原文链接：https://www.freecodecamp.org/news/designers-are-from-saturn-developers-are-from-jupiter-or-why-communication-matters-7d91794e5a37/

版权

银河土星

by Albino Tonnina

通过白化Tonnina

设计师来自土星，开发人员来自木星：或者，为什么沟通很重要 (Designers are from Saturn, developers are from Jupiter: or, why communication matters)

关于“但在规格”效果，UI工具包和其他方面看起来有所不同。 (About the ‘But it looks different on the Specs’ effect, UI Toolkits, and other stuff.)

Two different planets, but at least they’re in the same Solar System! And that’s the end of the analogy with planets.

两个不同的行星，但至少它们在同一个太阳系中！这就是行星类比的终结。

过敏咨询 (Allergy Advice)

This is an article about Design Systems, particularly on the topic of UI Toolkits and the dynamics of the communication between Designers and Developers.

这是一篇有关Design Systems的文章，特别是关于UI Toolkit以及Designer和Developer之间的通信动态的主题。

Designers, something tells me that you know about Design Systems and that you may dig them :) In case you want to read more, Nathan Curtis wrote a lot about it. I do love and respect his work on Design Systems.

设计师 ，有些告诉我您对设计系统了如指掌，也可以对它们进行挖掘:)如果您想了解更多信息，内森·柯蒂斯(Nathan Curtis)撰写了很多有关它的文章。我喜欢并尊重他在设计系统方面的工作。

Developers, I’m going to show some code at the end. The playground is a React + CSS-in-JS library (such as emotion or styled-components) app.

开发人员 ，我将在最后展示一些代码。游乐场是一个React + CSS-in-JS库(例如情感或样式化组件)应用程序。

一种典型的情况 (A kind of a typical scenario)

Our Designer produced a series of nice designs, including the layout of our Documents page:

我们的设计师制作了一系列精美的设计，包括“ 文档”页面的布局：

It’s clean, it’s balanced, it’s kinda pleasing to the eye. For the Designers, this is the culmination of a long process, a whole series of tasks involving researching, interviewing, thinking, reviewing, rethinking, whiteboard-ing, prototyping, and wireframing. A freaking long and tedious process that often Developers are not exposed to.

干净，平衡，令人赏心悦目。对于设计师而言，这是一个漫长过程的高潮，整个过程涉及研究，访谈，思考，审阅，重新思考，白板，原型制作和线框图制作等一系列任务。这是一个漫长而乏味的过程，通常开发人员都不会接触到。

How did the Designers produce this image anyway? They probably used a design toolkit. A very popular one is Sketch.

设计师是如何产生这种形象的？他们可能使用了设计工具包 。 Sketch是一种非常受欢迎的工具。

Alas, the way this software works is diametrically opposed to the way Developers work. And I say that’s the crux of our matter.

las ，此软件的工作方式与开发人员的工作方式截然相反。 我说那是我们问题的症结所在 。

Designers need tools that let them re-iterate quickly, reviewing and updating, feedback after feedback, one stakeholder meeting after the other. Designers need tools like Sketch.

设计师需要工具，使他们能够快速重复，审阅和更新，反馈后反馈，一个利益相关者开会。 设计人员需要诸如Sketch之类的工具。

另一方面，开发人员的工作方式不同。 (Developers, on the other hand, work differently.)

They work on ever-changing codebases that at any point in time must produce a working release of an application. It takes effort to implement a layout like the one in our example, designing, abstracting, implementing, refactoring, testing, reviewing, refactoring, bug fixing, refactoring. Developers need to make sure they don’t break anything else or pollute the codebase with bad, duplicated code.

他们使用不断变化的代码库 ，这些代码库在任何时候都必须产生应用程序的有效发行版。要像我们的示例中那样实现一种布局，即设计，抽象，实现，重构，测试，审阅，重构，错误修复，重构，需要付出很多努力。开发人员需要确保他们不会破坏其他任何东西或使用错误的重复代码污染代码库。

To me, being a designer is more like jumping backwards and forwards, whereas developers work in a continuous loop of development.

对我来说，成为设计师更像是向前跳来跳去，而开发人员则在不断的开发循环中工作。

视觉规格文件 (The Visual Spec file)

Now it’s time for Designers to communicate with Developers, hand off the baton.

现在是时候让设计师与开发人员进行交流， 交出指挥棒了。

There are layouts, spaces, and colors (and so on) to be documented. Sketch or any other tool doesn’t know much about your current codebase, your file structure, or your abstraction, so what can Sketch do? Measure things. And that’s what will be produced:

有要记录的布局，空格和颜色(等等)。 Sketch或任何其他工具对您当前的代码库，文件结构或抽象了解不多，那么Sketch可以做什么？衡量事情。这就是产生的结果：

几天过去了... (A few days go by…)

Stuff is ready and the Designers have the first look at it:

东西已经准备好了，设计师们首先看了一下：

沮丧的设计师，沮丧的开发商。 (Frustrated Designers, frustrated Developers.)

That’s the moment when the enchantment is really broken. The Spec file. Little issues with color, spacing, typography, layout, miscommunicated details, missing behaviours.

那是结界真正破裂的时刻。 规格文件 。颜色，间距，版式，布局，细节传达不正确，行为缺失等小问题。

Developers will have to interpret and adapt the specs to their own system in the codebase on the fly when they should just worry about implementing the business logic of the new feature. Designers are not to blame though — they may simply not know about such a system.

当开发人员只需要担心实现新功能的业务逻辑时，他们将不得不在代码库中即时解释和调整规范以适应他们自己的系统。设计师不要责怪-他们可能根本不了解这样的系统。

My grandpa used to say:

我爷爷曾经说过：

When Designers and Developers don’t communicate well, get a Design System with a well shared and communicated set of tools, abstractions, and constrains.

当设计人员和开发人员之间的沟通不畅时，请获得一个具有良好共享和交流的工具，抽象和约束集的设计系统。

您需要一个好的UI工具包 (You need a good UI Toolkit)

It’s through a shared system that Designers and Developers can really communicate effectively without stress. A UI Toolkit aims to reinforce the principles documented in a Design System. It is governed by a highly shared and documented set of conventions, UI patterns, behaviours, and it’s designed, tested and agreed on by everyone. It’s where Designers’ and Developers’ efforts meet.

通过共享的系统，设计人员和开发人员可以真正有效地进行交流，而不会感到压力。 UI工具包旨在加强设计系统中记录的原理。它受一组高度共享和记录的约定，UI模式，行为的支配，并且每个人都对其进行设计，测试和同意。 这是设计师和开发人员共同努力的地方。

为什么您真的需要一个好的UI工具包 (Why you really need a good UI Toolkit)

Is your app getting increasingly more complex?
您的应用程序变得越来越复杂吗？
Are designers talking quite a lot about inconsistencies in the app?
设计师是否在谈论应用程序中的不一致之处？
CI/CD? Going fast fast fast?
CI / CD？快快快快吗？
Remote teams?
远程团队？
Getting a bit messy with those CSS files?
这些CSS文件有点混乱吗？
Starting to care about the size of the app?
开始关心应用程序的大小？
Is the User Experience at the core of your business model?
用户体验是否是您的业务模型的核心？

You don’t need to tick all these — even one may be enough :)

您不需要对所有这些都打勾，即使其中一个也可以:)

为什么需要自己的UI工具包 (Why you need Your Own UI Toolkit)

A Design System is all about the Language. Visual language, UI Design language, etc. It takes a lot of effort to define your own: Product, Design, Engineering, all these departments will be heavily involved.

设计系统全部与语言有关 。视觉语言，UI设计语言等。 定义您自己的产品需要花费很多精力 ：产品，设计，工程，所有这些部门都会投入大量精力。

A lot of times that’s just not a viable option. There are amazing frameworks out there, semantic-ui, ant-design, Bootstrap, Material-UI. They all come with a sort of pre-made Language and a battle-tested UI Toolkit, ready for you to use.

很多时候，这不是一个可行的选择 。有很棒的框架，语义UI ， ant-design ， Bootstrap ， Material-UI 。它们都带有一种预制的语言和经过实践检验的UI工具包 ，可供您使用。

The catch? In my honest opinion, soon enough they won’t fit you anymore. You will want to evade them. Besides, the UI toolkits are probably so engineered to be hard to control. Remember that those frameworks are made to pass countless cases, maybe more than what you need. Plus, this extra complexity is paid in kb as well.

抓住？ 以我的诚实观点，很快他们将不再适合您。 您将要逃避它们。 此外，UI工具包的设计可能很难控制。请记住，这些框架可以传递无数种情况，也许超出了您的需求。另外，这种额外的复杂性也以kb为单位。

偷艺术家 (Steal as an artist)

Do not adopt a UI Toolkit. Copy from others instead, and by that I mean take the bits that fit you the most and implement them from scratch. It’s now common for highly user centric companies to have their own Design System, and many of them open-sourced!

不要采用UI工具包。而是从他人那里复制，这意味着我选择最适合您的内容并从头开始实施。对于高度以用户为中心的公司来说，拥有自己的设计系统已经很普遍了，其中许多都是开源的！

Look at this list of Design Systems: https://adele.uxpin.com:

查看以下设计系统列表： https : //adele.uxpin.com ：

BBC: Gel
英国广播公司：凝胶
Trello: Nachos
特雷洛：玉米片
Salesforce: Lightning
Salesforce：闪电

and dozens more. And in the end, it’s all a matter of designing and delivering this together. It’s about building something specific for your domain, also unique and representative of your brand. It’s rewarding, and you get to give it a nice name, too :)

还有几十个最后，所有这些都是一起设计和交付的。它是针对您的领域构建特定的东西 ，同时也是您品牌的 独特代表。这很有意义，您也可以给它起一个好名字:)

让我们做一个 (Let’s make one)

I’m gonna show you how easy it is to bootstrap your own Design System.

我将向您展示引导您自己的设计系统有多么容易。

I’m gonna call it Larry.

我叫它拉里(Larry) 。

Let’s take a little portion of our layout and try to build it from scratch:

让我们占一小部分布局，然后尝试从头开始构建它：

最终结果优先 (End result first)

The following CodeSandbox is the one and only app in the world that implements Larry:

以下CodeSandbox是世界上唯一实现Larry的应用程序：

You can find Larry on GitHub: https://github.com/albinotonnina/larry

您可以在GitHub上找到Larry ： https ： //github.com/albinotonnina/larry

文档资料 (The Documentation)

This bit is the most important. Who is in charge of this, maybe Designers? Well typically yes, but trust me on this: you should both be equally involved in documenting your Language. You should both agree on literally everything here.

这一点是最重要的。谁负责这件事，也许是设计师？通常，是的，但是请相信我：你们俩都应该同等地参与文档语言的编写。 你们应该就这里的一切达成共识。

Let’s start defining some really basic conventions:

让我们开始定义一些非常基本的约定：

色彩 (Colors)

Let’s generate a palette for our layout.

让我们为布局生成一个调色板。

I suggest that you define a series of semantic names from these colors, like so:

我建议您从这些颜色定义一系列语义名称，如下所示：

headerText = JapaneseIndigoparagraphText = JapaneseIndigoelementBackgroundDefault = SnowelementBackgroundHover = BrilliantAzureelementButton = LightGray — alpha 60%

headerText = JapaneseIndigo 段落文本 = JapaneseIndigo elementBackgroundDefault =雪elementBackgroundHover = BrilliantAzure elementButton =浅灰色— alpha 60％

These are the names you’re both gonna use when speccing (which is a word).

这些都是speccing 时 (这是一个字) 你们都打算用的名称。

间距 (Spacing)

Pay extra attention to spacing. Without a clear strategy for spacing, things can go really wrong.

要特别注意间距。 如果没有明确的间隔策略，事情可能真的会出错。

Define and agree on a spacing system, for example:

定义并同意间距系统，例如：

A spec file would look like this:

规格文件如下所示：

版式 (Typography)

Make sure that font-sizes, font-weights, line-heights, margins, colors in your headings, your paragraphs and so on just match. Call them with names you like, eg. HeaderHuge, HeaderLarge, HeaderTiny or use semantic tags (h1, h2, h3) properly. Just make sure you are aligned on this.

确保标题，段落中的字体大小，字体粗细，行高，边距，颜色，颜色等恰好匹配。用您喜欢的名字给他们打电话，例如。 HeaderHuge，HeaderLarge，HeaderTiny或正确使用语义标记(h1，h2，h3)。只要确保您对此保持一致即可 。

模式 (Patterns)

What rhymes with UI Toolkit? Pattern library! You need to start populating your library of patterns. What you want is to have the components that you need behave the way you agreed so you can compose them the way you want, anytime you want.

UI Toolkit有哪些押韵？ 模式库 ！您需要开始填充模式库。您想要的是使所需的组件按照约定的方式运行，以便您可以随时随地按所需的方式进行组合。

Start from the particles and primitives, such a Box component, for when you have to set spacings and borders around something else.

从粒子和图元(例如Box组件)开始，当您必须设置其他物体的间距和边界时。

Add more specialised new particles, such as a Text component or a Flex component, which you could imagine as a Box component + some flex utilities.

添加更多特殊的新粒子 ，例如Text组件或Flex组件，您可以将它们想象为Box组件+一些flex实用程序。

See them as particles that live in isolation, not aware of the context in which they will be used and of the space that should exist around them.

将它们视为孤立存在的粒子，不知道它们将在其中使用的上下文以及在它们周围应该存在的空间。

Continue with more complex UI Components, compositions of other smallest components and so on.

继续使用更复杂的UI组件，其他最小组件的组成等等。

What’s important here is not the technology or which kind of abstractions are in your documentation. What’s important is that you do this together.

此处重要的不是文档中的技术或哪种抽象。重要的是你们在一起做。

你明白了吗？ (You get the gist?)

You have defined constants and you have some particles to build.

您已经定义了常量，并且需要构建一些粒子。

You will reiterate over these particles and extend the library pretty quickly, so embrace and prepare for elasticity. Developers, you don’t want Designers to finish documenting the entire System before starting to implement the code. You have to do this thing together or it won’t just take off.

您将重申这些粒子并快速扩展库，因此请拥抱并为弹性做准备。开发人员，您不希望设计人员在开始实施代码之前先完成整个系统的文档编制。 您必须一起做这件事，否则就不会腾飞。

So, Designers and Developers, straight after the article go make your own Larry if you don’t have one!

因此，设计师和开发商如果您没有这篇文章，请在文章发表后立即创建自己的Larry ！

码 (Code)

You have a copy of Larry, you can clone and play with it. Your Larry may be different or you may be using different frameworks, so I’m going to go through the key points of this approach.

您拥有Larry的副本，可以克隆并使用它。您的拉里可能有所不同，或者您使用的框架可能不同，所以我将介绍这种方法的关键点。

主题，定义常量 (Theme, define the constants)

It’s an object with our theme constants, so spaces definitions, colors, fonts, typography, breakpoints, anything. Here’s Larry’s theme, and here’s a sample version of it:

这是一个带有我们主题常量的对象，因此空格定义，颜色，字体，版式，断点等都可以。这是Larry的主题，这是它的示例版本：

There’s no limit to the complexity/completeness you can achieve here, after all it’s a matter of generating a JavaScript object, just imagine what you could do!

您可以在这里实现的复杂性/完整性没有限制，毕竟，这只是生成一个JavaScript对象的事，请想象您可以做什么！

This is a core file. Every color, margin or padding, font-size or font-weight or breakpoint must come from here and only from here.

这是一个核心文件。 每个颜色，边距或填充，字体大小或字体粗细或断点都必须来自此处，并且只能来自此处。

CSS-in_JS libraries are amazing tools, and styled-system makes them even better. It’s a set of utilities for Design Systems and consist of functions that take props as an argument and return style objects, while making it simpler to use values from a theme and apply styles responsively across breakpoints.

CSS-in_JS库是很棒的工具，而样式化的系统使它们变得更好。它是用于Design Systems的一组实用程序，由以props作为参数并返回样式对象的函数组成，同时使使用主题中的值和跨断点响应地应用样式更加容易。

This approach take advantage of these utilities, so feel free to evaluate it.

这种方法利用了这些实用程序的优势，因此可以随时对其进行评估。

将主题插入您的应用 (Plug the theme into your app)

Provide those constants to your app: every component in the app will have access to our theme constants.

将这些常量提供给您的应用程序：应用程序中的每个组件都可以访问我们的主题常量。

创建基本的UI组件 (Create basic UI Components)

更专业的UI组件 (More specialised UI components)

Here’s a Flex component.

这是一个Flex组件。

在功能文件中实现UI组件 (Implement UI components in your feature files)

是时候渲染一些东西了 (Time to render something)

This is where you implement your UI Component and your business logic.

在这里，您可以实现UI组件和业务逻辑。

文件结构 (The files structure)

This is Larry’s file structure. I don’t have strong opinions on file structures, actually I believe in something different: move your files around until you feel comfortable with them.

这是拉里的文件结构。我对文件结构没有很强的见解，实际上，我相信有一些不同之处：移动文件，直到对文件感到满意为止。

Larry is all in a “design-system” folder. This is where you can find its constants and generic and reusable UI components.

拉里都在“ 设计系统”文件夹中。在这里可以找到其常量以及通用和可重用的UI组件。

Notice also the UI folder into the Document layout folder — that’s where I define and export the UI components specific for our feature.

还要注意UI文件夹到Document layout文件夹中，这是我定义和导出特定于我们功能的UI组件的地方。

结论 (Conclusion)

With large and complex apps, it’s never easy to keep the UI consistent and cohesive. Design Systems help. Custom Design Systems and tailored UI Toolkits really help.

使用大型和复杂的应用程序，保持UI的一致性和内聚性绝非易事。设计系统帮助。定制设计系统和量身定制的UI工具包确实有帮助。

Designers and Developers may have very different approaches to the same problem, but that doesn’t mean that they cannot communicate effectively.

设计人员和开发人员针对同一问题可能有非常不同的方法，但这并不意味着他们无法有效地沟通。