[译] 如何提高设计到开发的协做效率

原文地址：How to Save UI Designers & Front-End Developers up to 50% of Their Time

原文做者：Henry Latham

译文出自：掘金翻译计划

本文永久连接：github.com/xitu/gold-m…

译者：meterscao

校对者：rockyzhengwu, Park-ma

为何一月会有圣诞节

提示：这篇文章有不少有趣和无趣的表情包，也有不少大图。除非你不在意流量费用，建议最好仍是先连上 Wi-Fi 。并且这篇文章真的很是长，你还能够准备一桶爆米花和可乐（笑）。html

一月的圣诞节？

当你仍是个小孩的时候，圣诞节真的真的很是使人兴奋。一想到圣诞老人带来的礼物，以及打开礼物时的场景，让整个月都充满了不可思议的兴奋和喜悦。前端

在我做为UI设计师的生涯里，当我第一次使用 Sketch App 时，我也像个孩子同样的兴奋：android

“你是认真的吗？！在过去的 3 个月里，我可能已经在 Photoshop 那些愚蠢的小像素图形中浪费了 90％的时间，它们甚至看起来都不是我想要的样子。为何以前没有人告诉我有这个 App ？！太难以置信了。”ios

做为一名设计师，个人职业生涯中只有两个阶段：Sketch 以前的生活（BS）和 Sketch 以后生活（AS）。git

我不想说 Sketch 以前的生活，简直糟糕透了。全部的东西看起来都……有些不同，有些怪，呃……有点像素化。设计一个标题就差很少要花掉一个星期的时间，更不用说设计一个完整的页面了。程序员

有了 Sektch 以后的生活简直不要太爽。我敢说你甚至能够跟一帮小朋友组建一个设计团队。github

你能够重复使用各类元素。它们都是精美的，矢量化的，有条理的，而且很是简洁和直观。数据库

好吧，若是你是产品经理，设计师或前端工程师，如今你也会孩子同样地兴奋。编程

可能如今是一月初，但我感受就像圣诞节同样。欢迎来到对象驱动设计的世界。后端

做者注：当我在耶路撒冷和约旦河西岸写这篇文章的时候，看到一些圣诞树还摆在上面......从那时起就注意到一些东正教基督教日历中圣诞节其实是在 1 月的。而后发现个人标题有点荒谬和吸睛......

[免费下载这个 UI 工具包](http://eepurl.com/dhWTbP)

在这篇内容丰富且充满乐趣的文章中，我将解释：

什么是对象驱动的设计
为何这些问题仍然没有解决
为何不使用面向对象的设计会有很大的风险
如何在设计流程中采用面向对象的设计

经过个人方法，让 UI 设计师能够花更多的时间作快乐的设计，让前端开发能集中精力开发功能，而不是在那里一个像素一个像素地调间距。设计到开发的流程（我简称为 “D2D”）效率将真正提升十倍。

你为何要关心这个？

许多产品经理和UI设计师读到这里都会想，

“我已经用了 3 年 Sketch 的 Symbols 和 Typography 功能，说一些我不知道的东西吧，而后中止你那愚蠢的圣诞节比喻。”

他们并无错。我猜测大多数设计师必定程度上都会在 Sketch 文件里建立可重用的 Symbols（相似于编程术语中的“对象”）。

可是，在过去的两年中，和我合做的设计师里历来没有人能找到一种全面的方式，来改善 D2D 交付过程当中的低效问题。

这个问题存在的 3 个缘由

在深刻研究 D2D 问题以前，首先要说明白：既然已经有这么多的设计工具了，为何仍然存在 D2D 效率低下的问题。

1. 平庸的标准

不幸的是，许多读者会自信地认为，这不是他们或他们的公司会遇到的问题。

由于生产力和效率是相对的。不多有 UI 设计师和产品经理能意识到：可能会存在一个比如今更好的设计流程。

咱们倾向于以咱们周围的其余创业公司和 UI 设计师为标准。若是每一个人都以相同的方式工做，那么它可能就是最有效的，对不对？

不对。

咱们有一种最多见的偏见，会基于咱们的认知对这个世界上的事物产生刻板的印象，就像咱们如今说的“效率”。

举个例子：

假如我有些超重，但我全部的朋友都很胖。当我周围的人都比我胖的时候，我极可能会认为本身是一个健康的人，由于个人参考点（我肥胖的朋友们）比我更糟糕。

然而，仅仅由于他们不如我健康，并不必定意味着我就是健康的。个人体重依旧超重。

所以，为了实现效率的明显飞跃，就得去打破平庸的标准，而且不断尝试创新。

“若是我问人们想要什么，他们会说更快的马。” —— 亨利·福特

2. 盲目相信现有的流程

D2D 效率低下一直存在的一个缘由是，咱们老是假设咱们在公司使用的这些流程和方法都已是最优的。

可是事实并不是如此。

首先，无论是否真的遵循敏捷开发的思想，效率低下的问题总会存在。特别有些是你甚至均可能意识不到的问题。

其次，你必定能意识到，因为缺少统一的合做和竞争体系，项目一开始就会当即进入“互相抢占资源，而非高效合做”的局面，正如 LeanUX 的做者 Jeff Gothelf 所描述的那样。

这样的场景每每意味着设计师资源变得紧缺，一般在少数产品经理和大量程序员之间共享。设计师对应多个产品和开发，这致使他们之间的合做也可能会变得混乱和无序。所以，UI 设计师不多可以停下来，尝试作一些系统化的设计方案，使其具备更高的灵活性。

只有遵循对象驱动的设计流程，才能实现真正意义上的速度和敏捷。

3. 设计师和程序员是彻底不一样的人

在咱们美好的想象中，设计师每周都能进行设计评审和回顾，无所不能的产品经理也能高效地与每一个人沟通和配合。没错，对于检验作没作很容易，可是对于怎么作就很难。

这能够归结为：UI设计师和前端工程师之间的根本误解，或者说是专业鸿沟。

UI设计师倾向于认为本身是艺术家，他们的做品是艺术品。只要用户可以理解他们做品中的美，他们的产品就能拥有数百万用户。

他们喜欢排版，并热衷于手工艺和手冲咖啡。他们最喜欢的颜色是 #FEB4B1。

典型的程序员形象：绝不在意的打扮，极其小众的兴趣爱好，好比 Magic The Gathering（译者注：一种集换式卡牌游戏。） — 典型的程序员形象：绝不在意的打扮，极其小众的兴趣爱好，好比 Magic The Gathering （译者注：一种集换式卡牌游戏。）

程序员，他们只想创造很酷炫的东西，他们并不太关心它们看起来的样子和视觉表现。对他们来说，“样式” 这个难以捉摸的概念是留给艺术家的，对他们来讲就像“约会”同样陌生。他们并不能理解为何红色的阴影是更红的，为何标题文本应该往左边一点点。

当不被打扰地独自为一些复杂的新项目写代码的时候，才是他们最开心的时候。

从本质上讲，他们是不一样的人。 不一样的专业技能，不一样的思考方式，不一样的兴趣爱好。

他们每一个人都认为彼此的专业领域都是使人难以置信的复杂和费解的。所以，他们不惜一切代价避免介入彼此的领域。

也许两个群体都不知道，或者坦白地说不关心，如今UI设计师的视觉工做和前端工程师的工做已经有不少重合的部分。

基于此，若是这两个角色创建了一种明确的设计语言（也就是 Sketch 中的 Symbols）的话，那么 D2D 流程将会很是简单和快速。

可是，因为每一个角色对彼此孤立的工做并不感兴趣，所以他们之间仍存在很是明显的知识差距，这是另外一个致使团队 D2D 流程低效的缘由。

所以，UI设计师和前端工程师使用统一的设计语言，对改善低效是很是有意义的：

“产生良好结果的模式应该被推广，而那些形成问题的人应该获得纠正。” —— Jeff Gothelf，Lean UX 的做者

4. 没法遵循对象驱动设计存在的问题

1. 设计系统的缺失会浪费设计师和程序员大量的时间

UI 设计师

理论上，D2D 交付流程应该是直接的。

理论上，UI 设计师已经与前端开发能达成一致，而且能够无缝地协做。

理论上，他们会事先约定好统一的设计语言，而且使用可重用的组件和元素。设计师在 Sketch 中复制粘贴一下，前端开发一两行代码就能搞定。

然而，理论却不多能转化为现实。

实际状况是，大多数 UI 设计师会花大量时间设计一些新的自定义元素。

首先，由于他们不是程序员，因此他们不明白实现这些新的设计元素须要额外作不少的工做。

其次，许多 UI 设计师认为他们的做品是艺术，而不是科学。所以他们并不情愿为了实用主义而牺牲做品的美感。

他们喜欢花费大量的时间对现有元素进行细微的调整，而不是把很容易实现的设计稿尽快交付给前端工程师。

他们花了太多的时间和精力在细节上（好比把文本移动几个像素）而不是项目重心上（好比设计和体验一个新的功能）。

细节是很重要，可是当已有的 UI 元素已经很好地知足需求和场景了，很难证实这些细节的调整真的会带来有效的提高。

UI 设计师过度关注细节致使项目进度减缓，这个事实也让问题变得更加显著。设计评审被推迟，产品经理的信息同步也不及时，设计师也只愿花更多的时间在他们各自的设计工做中。

前端工程师

当前端工程师拿到设计最终稿时，应当已经进行了几轮评审，以确保每一个人都清楚最终的预期。

可是，咱们仍然发现问题仍旧存在，由于：

前端工程师过度相信设计稿。他们一般会认为最终实现的效果必须跟设计稿上彻底相同，尽管有些设计稿实现起来很困难，可是他们将全部 UI 设计师都视为专家。所以，他们不会试图简化或讨论设计方案，他们相信一切背后都有一些合理的缘由，UI 设计师的设计稿就是最终完美的方案。
前端工程师比其余人更讨厌会议。所以，他们并不想为了纠结字体大小是 12px 仍是 14px 进行冗长和无聊的辩论，他们只是想尽快开完会，与设计师达成一致，而后愉快地回去写代码。
前端工程师一般比较内向和腼腆。所以，他们不太可能 PK 得过自信的产品经理和自负的 UI 设计师。

所以，尽管在前期有设计评审和讨论环节，他们最终仍是去作了一些重复的、不合理的、或者实现起来很困难的东西。

2. 随着时间的推移，D2D 效率越来越低下

D2D 效率低下的时间越长，对现有和将来团队成员的资源浪费就越大。这道理看起来很明显，但一般老是被咱们忽视。

咱们经常更专一于短时间目标（加班加点完成手头上堆积的事情），而不是着眼于长期的目标和最终的成功。

在实现短时间的冲刺目标和完成大量项目功能的过程当中，咱们根本无暇去改善合做中的低效问题。

由于关注短时间的目标很容易，由于你们都面临很大的压力，由于咱们不多会停下来思考咱们如此忙碌的真正目的是什么。

3. 没有设计系统 = 设计缺陷

在设计流程中，UI 设计师的设计越不系统化，在后期的工做中将会面临更多的问题。

咱们来举个例子：

假如全部的图标都没有统一的尺寸，有些是 24x24，有些是 40x24，有些是 12x16。这不只会浪费程序员的时间（正如我在第一点所强调的那样），并且还意味着未来任何的变化都会变得很是麻烦。若是未来但愿更改某些图标，就必须针对每个图标每个特定的尺寸进行从新设计和导出，不然这些图标在最终的展现时候要么错位，要么会被拉伸。

此外，若是 UI 设计师在 Sketch 文件中，不建立严格的文本样式、取色板，以及可重复使用的 Symbols（好比全部按钮尺寸都是24x24）的话，就会严重阻碍咱们编辑现有元素的效率。

假如想要对整个产品中的文本样式进行统一的调整，咱们只能对 Sketch 中的每个页面挨个进行手动的调整。可是若是使用了 Typography 的话，彻底不用如此麻烦。对于一个拥有大量页面的完整 App 来讲，这样的调整和更新会浪费UI设计师大量的时间。

4. 不创建设计系统会妨碍团队协做

若是没有设计系统，UI 设计师的大部分时间都会花在建立新的元素或者对现有的设计不断地修改上面。

这意味着他们没有更多的时间进行脑暴或者在 Sketch 里面与前端工程师一块儿尝试新的想法。

团队能够经过组织设计评审来测试不一样的方案，或者调整正在讨论的设计，这很是有利于整个团队对设计的投入和支持。

“持续相互反馈的团队将会创造更好的产品。” —— Jim Semick，InVision

此外，设计系统能避免了 UI 设计师为了相同的方案进行重复的设计评审和返工，这为整个团队节省了大量时间。

在这里下载个人免费 UI 工具包：http://eepurl.com/dhWTbP

如何实现对象驱动的设计

如今，但愿你已经明白实施设计系统是多么的重要。

下一节中，在深刻研究构建和维护设计系统的细节以前，我将讨论更改 UI 设计师的工做方法的重要性。

第 1 步：得到 D2D 流程的主导权

在承诺遵循对象驱动设计以前，必须确保 UI 设计师能获得适当的激励。

若是他们作这个的理由很含糊：“这能让团队更高效”、“咱们只是被要求这么作”，若是是这样的话，那就算了吧。

可是，若是设计师打心底承认 D2D 交付流程是他们的角色和责任中很关键的部分，那么他们不只更有动力和积极性去构建一个设计系统，并且会长期地维护和完善它。

让我强调一下：创建设计系统不只仅只是个一次性的任务。每当你开始新的设计或验证方案时，你都应该把他们准确地组织在你的设计系统中，这样能够供未来使用。

UI 设计师必须是彻底承认他们应该为 D2D 流程负责任。不然，他们对于如何用编程的方式实现设计从而改进设计流程的过程，也不会特别的好奇和投入。

他们须要阅读一些关于设计和开发流程的文章，参加基础编程的课程，学习 Material Design 指南，了解前端工程师的工做，向产品经理、前端工程师或者其余设计师学习，等等。

总之，他们要跳出温馨区，不能为了只专一于他们喜欢的和感到温馨的东西而放弃那些更重要的学习，不能最后又回到了 Sketch 和 Dribble 上来。

第 2 步：构建设计系统

构建设计系统的核心目的，是基于面向对象的编程思想建立一个完整的元素列表。指望的结果是经过你在 Sketch 中建立的设计系统，让设计师和程序员可以更加紧密的合做，从而让整个团队也运做得更加的高效。

设计师和程序员之间互相的沟通会带来更加深彼此的理解，也会让整个团队创造出更优秀的产品。

1/7 从基础开始：颜色和文本样式

对象驱动的设计必须从基础开始：定义颜色和文本样式。由于全部其余的元素都须要这些信息：好比，一个按钮须要明确背景颜色、边框颜色；一行文本须要明确字体、字号和行高。

2/7 为单个页面建立独立控件

经过建立一个示例页面，你就很快能理解对象驱动设计的原理，并指导怎样在实际的工做中运用。根据个人经验，只有不断以迭代的方式来践行对象驱动的设计理论，才能真正有效地学习如何建立一个完整的设计系统。

在开始尝试的时候，不要担忧不全面。由于当你建立过一些示例页面以后，你很快就能明白怎么合理地建立这些元素。

能够从标题栏（带有文本和按钮的那种标题栏）、或者文本段落开始，也能够用其余任何你想尝试的控件。请记住，从最小的元素起，就要开始保证设计的一致性。

元素指的是一组 Symbols ，好比一个标题栏或者一个段落文本

YouTube 视频连接：youtu.be/5MGNi24hHAE （已经打不开了）

3/7 Override（更改元素的信息）

在 Sketch 中若是选中一个 Symbol，在右侧的面板（在 “Override” 中）就能看到这个对象包含的那些能够被修改的的信息，好比标题栏中包含的文本。

但须要注意的是，这样的修改并不会改动到 Symbol 自己的样式。由于这个本质上很像前端的工做方式：

你定义展现给用户的界面（好比，字号、排版、对齐方式等），可是最终填充的内容（好比名称、地址、图标等等）是从数据库中拉取来的。

好比，你能够定一个图片按钮的位置、大小，可是实际展现的图片是存放在 CDN 中。

4/7 建立一组示例页面

如今你已经看到了 Overrides 的强大功能，你知道须要建立哪些类型的 Symbols，以及 Symbols 之间是怎么关联和组合起来的（例如标题栏中的按钮）。

但愿你也意识到这个过程须要多么周密的规划和组织了。你可能已经本身定义了一些 Typography ，但我怀疑只是在为左对齐，中对齐仍是右对齐建立了一个变体。

如今尝试建立 4-5 个页面，而且全部的页面都只能基于先前定义的 Symbols 来建立。不要担忧它们是否是缺乏组织或者搭建起来很不方便：意识到这些问题，并从中学习和思考，本质上也是学习的一个过程。

5/7 为 Symbols 准确地命名

如今，你应该对如何建立一个完整的设计系统有了清晰的理解。

可是在深刻研究完整的设计系统以前，我建议花一些时间了解下信息架构。

信息架构本质上是指用最符合逻辑最优的方式来组织信息。

在有设计系统的状况下，全部的对象都处在清晰的层次结构里，而且都有符合逻辑的命名，经常使用的元素也很是便于使用。

搭建一个全面的设计系统前，首先要确保你已经熟悉整个产品，明确全部你须要建立的 Symbols ，而且明白如何才能找到最佳的方式来组织它们。哪些元素是最经常使用的？其余设计师怎么能找到这些 Symbols？他们会指望每一个 Symbol 应该怎样命名？

若是不能作到以上所说的点，未来在 Symbols 的查找和重命名上就会耗费大量的时间，并且也没法用一种逻辑清晰的方式来添加新的 Symbols。

6/7 建立全面的设计系统

如今你已经建立了一些 Symbols ，很明确你的产品须要哪些 Symbols，而且有一套清晰的命名体系，因此如今是时候来完成整个设计系统了。

为了保证设计系统的结构清晰，你须要留出专门的时间来完成它，而且全身心投入其中。

当你在完成的过程当中，可能会发现一些命名上的错误和缺陷。所以，请随时检查你的命名规则，建立一些用于测试的页面而且验证一致性。

由于你的产品是独一无二的，所以你须要建立的这些 Symobls 也是独一无二的。因此，你必须去思考如何最好地架构这个设计系统，以及这个系统究竟须要包含哪些内容。

7/7 设计评审

与产品经理，UX/UI 设计师，还有前端工程师一块儿组织设计评审，来展现新的设计系统。

你会发现团队的全部成员都会当即意识到它的价值。前端工程师很高兴，由于他们有一个明确的交付文件可供参考和使用；产品经理也很高兴，由于他们能够与设计师快速地搭建产品原型；其余的设计师也很高兴，由于他们均可以在 Sketch 内的同一设计系统中协同工做了。

当你将你的设计系统保存到 Sketch 中的 “Template”，并与其余 UI 设计师共享后，大家就能够开瓶酒好好庆祝下了。

第 3 步：维护你的设计系统

当你完成设计系统后，你还须要维持它继续向前迭代。

任何新的设计元素，无论是否会在最终的产品中体现出来，都应该将它们正确地归类和组织为 Symbols。

极可能你的工做很是的繁忙，项目的节奏也很是快，你不太可能会有机会从新将最终的设计稿再一点一点地重构成结构清晰命名规范的 Symbols。与其在未来浪费更多的时间，不如在一开始就用最优的方式来设计。

不管你有多忙都请记住：磨刀不误砍柴工。

另外，若是你的团队中还有其余的设计师的话，大家都须要为设计系统的发展做出贡献。

团队中的每一个成员都必须遵循设计规范。还应该有专门的设计师来负责将新的 Symbols 添加到产品的 “Library” 中，以确保全部的人都能访问到已有的和新增的 Symbols。

这个设计师还应按期更新主干上的文件，以便全部团队成员均可以访问到最新版本，避免因未保存文件而浪费任什么时候间。我建议使用 Github 或 Sketch Cloud ，你还可使用付费版的 Abstract，用一种更直观、对设计师更友好的方式来管理文件的版本。

若是大家仅仅是一个很小的团队，彷佛就不太须要这样的组织方式。可是在某些时候，你可能须要提早慎重思考：若是没有最新的设计系统，新的 UI 设计师怎样知道从什么地方开始工做？大家怎么互相协做？

第 4 步：创新永无止境

正如我在步骤 1 中所说的，这个过程的核心要素是承担责任。坚持指望很容易，承担责任却很艰难。

可是，这对成功相当重要。

您必须保持警戒，不断学习，不断寻找新工具来提升技能并改善你的工做流程。

Sketch App 正在不断改进，Sketch 社区也不断出现很酷的新插件。同时其余的设计工具也正在出现，好比 Adobe XD，你能够关注这些软件而且尝试一下。

顶级公司将 5-15％的收入用于培训员工，若是你是设计师，坚持每周花些时间了解新的技术，体验新的产品。

永远记住：投资自身不断学习，而且着眼于公司的长远目标才是成功的关键，而不是眼前那些看起来很紧急或者很重要的事情。

关于做者：

Henry Latham 是一名位于柏林的自由职业 UX / UI设计师，正在寻找潜在的联合创始人。

若是发现译文存在错误或其余须要改进的地方，欢迎到掘金翻译计划对译文进行修改并 PR，也可得到相应奖励积分。文章开头的 本文永久连接 即为本文在 GitHub 上的 MarkDown 连接。

掘金翻译计划是一个翻译优质互联网技术文章的社区，文章来源为掘金上的英文分享文章。内容覆盖 Android、iOS、前端、后端、区块链、产品、设计、人工智能等领域，想要查看更多优质译文请持续关注掘金翻译计划、官方微博、知乎专栏。