- 原文地址：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 月的。然後發現我的標題有點荒謬和吸睛......
在這篇內容豐富且充滿樂趣的文章中，我將解釋：
- 什麼是物件驅動的設計
- 為什麼這些問題仍然沒有解決
- 為什麼不使用物件導向的設計會有很大的風險
- 如何在設計流程中採用物件導向的設計
通過我的方法，讓 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。
程式設計師，他們只想創造很酷炫的東西，他們並不太關心它們看起來的樣子和視覺表現。對他們來講，“樣式” 這個難以捉摸的概念是留給藝術家的，對他們來說就像“約會”一樣陌生。他們並不能理解為什麼紅色的陰影是更紅的，為什麼標題文字應該往左邊一點點。
當不被打擾地獨自為一些複雜的新專案寫程式碼的時候，才是他們最開心的時候。
從本質上講，他們是不同的人。 不同的專業技能，不同的思考方式，不同的興趣愛好。
他們每個人都認為彼此的專業領域都是令人難以置信的複雜和費解的。因此，他們不惜一切代價避免介入彼此的領域。
也許兩個群體都不知道，或者坦白地說不關心，現在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 設計師的工作方法的重要性。
第 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、前端、後端、區塊鏈、產品、設計、人工智慧等領域，想要檢視更多優質譯文請持續關注 掘金翻譯計劃、官方微博、知乎專欄。