[譯] 如何提高設計到開發的協做效率

• 原文地址：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 。並且這篇文章真的很是長，你還能夠準備一桶爆米花和可樂（笑）。

一月的聖誕節？

當你仍是個小孩的時候，聖誕節真的真的很是使人興奮。一想到聖誕老人帶來的禮物，以及打開禮物時的場景，讓整個月都充滿了不可思議的興奮和喜悅。

在我做爲UI設計師的生涯裏，當我第一次使用 Sketch App 時，我也像個孩子同樣的興奮：

「你是認真的嗎？！在過去的 3 個月裏，我可能已經在 Photoshop 那些愚蠢的小像素圖形中浪費了 90％ 的時間，它們甚至看起來都不是我想要的樣子。爲何以前沒有人告訴我有這個 App ？！太難以置信了。」

做爲一名設計師，個人職業生涯中只有兩個階段：Sketch 以前的生活（BS）和 Sketch 以後生活（AS）。

我不想說 Sketch 以前的生活，簡直糟糕透了。全部的東西看起來都……有些不同，有些怪，呃……有點像素化。設計一個標題就差很少要花掉一個星期的時間，更不用說設計一個完整的頁面了。

有了 Sektch 以後的生活簡直不要太爽。我敢說你甚至能夠跟一幫小朋友組建一個設計團隊。

你能夠重複使用各類元素。它們都是精美的，矢量化的，有條理的，而且很是簡潔和直觀。

好吧，若是你是產品經理，設計師或前端工程師，如今你也會孩子同樣地興奮。

可能如今是一月初，但我感受就像聖誕節同樣。歡迎來到對象驅動設計的世界。

做者注：當我在耶路撒冷和約旦河西岸寫這篇文章的時候，看到一些聖誕樹還擺在上面......從那時起就注意到一些東正教基督教日曆中聖誕節其實是在 1 月的。而後發現個人標題有點荒謬和吸睛......

在這篇內容豐富且充滿樂趣的文章中，我將解釋：

1. 什麼是對象驅動的設計
2. 爲何這些問題仍然沒有解決
3. 爲何不使用面向對象的設計會有很大的風險
4. 如何在設計流程中採用面向對象的設計

經過個人方法，讓 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 設計師形象：精心修剪的鬍鬚，新穎時尚的裝扮

UI設計師傾向於認爲本身是藝術家，他們的做品是藝術品。只要用戶可以理解他們做品中的美，他們的產品就能擁有數百萬用戶。

他們喜歡排版，並熱衷於手工藝和手衝咖啡。他們最喜歡的顏色是 #FEB4B1。

典型的程序員形象：絕不在意的打扮，極其小衆的興趣愛好，好比 Magic The Gathering （譯者注：一種集換式卡牌遊戲。）

程序員，他們只想創造很酷炫的東西，他們並不太關心它們看起來的樣子和視覺表現。對他們來說，「樣式」 這個難以捉摸的概念是留給藝術家的，對他們來講就像「約會」同樣陌生。他們並不能理解爲何紅色的陰影是更紅的，爲何標題文本應該往左邊一點點。

當不被打擾地獨自爲一些複雜的新項目寫代碼的時候，纔是他們最開心的時候。

---

從本質上講，他們是不一樣的人。 不一樣的專業技能，不一樣的思考方式，不一樣的興趣愛好。

他們每一個人都認爲彼此的專業領域都是使人難以置信的複雜和費解的。所以，他們不惜一切代價避免介入彼此的領域。

程序員眼裏設計師的工做

設計師眼裏程序員的工做

也許兩個羣體都不知道，或者坦白地說不關心，如今UI設計師的視覺工做和前端工程師的工做已經有不少重合的部分。

基於此，若是這兩個角色創建了一種明確的設計語言（也就是 Sketch 中的 Symbols）的話，那麼 D2D 流程將會很是簡單和快速。

可是，因爲每一個角色對彼此孤立的工做並不感興趣，所以他們之間仍存在很是明顯的知識差距，這是另外一個致使團隊 D2D 流程低效的緣由。

所以，UI設計師和前端工程師使用統一的設計語言，對改善低效是很是有意義的：

「產生良好結果的模式應該被推廣，而那些形成問題的人應該獲得糾正。」 —— Jeff Gothelf，Lean UX 的做者

React Native — 對象起的做用

Sketch — Symbol 起的做用

4. 沒法遵循對象驅動設計存在的問題

1. 設計系統的缺失會浪費設計師和程序員大量的時間

簡單的 UI 與複雜的 UI

UI 設計師

理論上，D2D 交付流程應該是直接的。

理論上，UI 設計師已經與前端開發能達成一致，而且能夠無縫地協做。

理論上，他們會事先約定好統一的設計語言，而且使用可重用的組件和元素。設計師在 Sketch 中複製粘貼一下，前端開發一兩行代碼就能搞定。

然而，理論卻不多能轉化爲現實。

實際狀況是，大多數 UI 設計師會花大量時間設計一些新的自定義元素。

首先，由於他們不是程序員，因此他們不明白實現這些新的設計元素須要額外作不少的工做。

其次，許多 UI 設計師認爲他們的做品是藝術，而不是科學。所以他們並不情願爲了實用主義而犧牲做品的美感。

成爲 UI 設計師後發現居然不能掙到錢，夢想破滅了。

他們喜歡花費大量的時間對現有元素進行細微的調整，而不是把很容易實現的設計稿儘快交付給前端工程師。

他們花了太多的時間和精力在細節上（好比把文本移動幾個像素）而不是項目重心上（好比設計和體驗一個新的功能）。

細節是很重要，可是當已有的 UI 元素已經很好地知足需求和場景了，很難證實這些細節的調整真的會帶來有效的提高。

UI 設計師過度關注細節致使項目進度減緩，這個事實也讓問題變得更加顯著。設計評審被推遲，產品經理的信息同步也不及時，設計師也只願花更多的時間在他們各自的設計工做中。

前端工程師

當前端工程師拿到設計最終稿時，應當已經進行了幾輪評審，以確保每一個人都清楚最終的預期。

可是，咱們仍然發現問題仍舊存在，由於：

1. 前端工程師過度相信設計稿。他們一般會認爲最終實現的效果必須跟設計稿上徹底相同，儘管有些設計稿實現起來很困難，可是他們將全部 UI 設計師都視爲專家。所以，他們不會試圖簡化或討論設計方案，他們相信一切背後都有一些合理的緣由，UI 設計師的設計稿就是最終完美的方案。
2. 前端工程師比其餘人更討厭會議。所以，他們並不想爲了糾結字體大小是 12px 仍是 14px 進行冗長和無聊的辯論，他們只是想盡快開完會，與設計師達成一致，而後愉快地回去寫代碼。
3. 前端工程師一般比較內向和靦腆。所以，他們不太可能 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 來建立。不要擔憂它們是否是缺乏組織或者搭建起來很不方便：意識到這些問題，並從中學習和思考，本質上也是學習的一個過程。

信息架構：邏輯清晰地組織你的 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、前端、後端、區塊鏈、產品、設計、人工智能等領域，想要查看更多優質譯文請持續關注 掘金翻譯計劃、官方微博、知乎專欄。