設計系統是如何從多方面解決日益增長的痛點

這是來自于 InVision DesignBetter 站點的一系列設計系統相關的文章，希望能幫助更多人理解并運用設計系統。設計系統讓團隊理解并使用一種統一的設計語言。他可以減少你的設計負債，加速設計流程，連接產品設計和開發實現之間的鴻溝。

在 19 世紀六十年代，計算機技術的發展速度遠遠超過了軟件研發的速度。電腦變得更快更便宜了，而軟件研發卻仍舊十分緩慢，且很難維護，漏洞百出。這種差距，以及該如何應對的窘境，被稱之為軟件危機[1]。

在 1968 年，NATO 軟件工程會議[2]上，Douglas McIlroy 提出了組件式開發的解決思路。組件式開發通過代碼重用來釋放軟件編程的潛能，使其更加高效并且易于擴展。這大大降低了軟件研發的所需的人力，并且提高了研發速度，使得軟件可以更充分地利用計算機的能力。

而現在，50 年之后，我們正經歷著一場相似的挑戰，不過這一次是在軟件設計領域?，F在的設計流程已經不能滿足軟件迭代的節奏，因為我們的設計方式仍然處于原始地定制化地解決單個問題的處境中，不能很好地規?；?/span>

你是否遇到過這種情況：當你審視以往的設計稿時，發現自己用了很多種相似的藍色，或者是一組相近的按鈕，它們散落在你產品的不同角落中。此時你開始意識到，你的設計竟然如此不統一，如此不完整，而且如此難以維護。

在這種狀態下，想讓設計的步伐跟上開發節奏，一般公司可能會做三件事：

?招來更多人

?加快設計速度

?找到一個能一舉多得的解決方案

即使招來了更多的熟練的設計師，這種定制化作坊式的設計方式也難以規?；?。因為這種模式本身就很慢，難以統一，并且隨著時間變化越來越難以維護。

設計系統通過“設計復用”讓設計團隊更好更快地設計產品，并使規模化成為可能。這就是設計系統的最初出發點：通過一系列可以復用的設計組件，結合一定的標準規范來組裝它們，快速構建不同的應用。

過去 50 多年來，工程師通過這種方式成功運轉工作流程?，F在，設計師們也意識到了設計系統內在的潛力，加入到這個行列中來。

用系統思維讓設計規模化

最近這段時間你可能已經注意到“設計系統”在行業內被討論得越來越熱烈。設計正在規模化，很多公司開始往設計中投入越來越多，提供更好的用戶體驗來提升產品的競爭優勢，以此吸引更多客戶，同時減少無意義的支出。

這種公司內部一般有這么幾種特征：

?設計團隊正在增長

?每個團隊都有設計的參與

?無論是產品層面還是平臺層面，設計扮演的角色越來越重要

如果你是一個設計師，這種對設計的投入應該會讓你很興奮，但這也伴隨著一些挑戰。你如何保證這么多團隊這么多產品在設計上保持統一？你如何保證這么多團隊可以同時快速迭代？有一部分設計師不可避免地要設計一些定制化的東西，這一部分東西你將如何維護呢？

為了理解設計系統如何面對并解決這些挑戰，我們有必要先理解設計系統是什么？設計系統其實是將標準規范和組件這兩個概念的優勢結合起來，形成一個更加強大的東西。

標準規范

了解 Macintosh 用戶界面的技術知識在產品設計中至關重要，但是理解用戶界面背后的理論能夠幫助你創造令人驚艷的產品。

                                                                         ——蘋果人機交互指南

理解一個系統的設計背后是什么，同時理解為什么，對于構建驚人的用戶體驗是極其重要的。定義和遵循標準規范能夠幫我們更好地理解它，因為它會消除主觀臆斷和模糊不清的東西，讓我們的團隊協作阻力和困惑更小。

在設計和開發中都要遵循標準規范。當我們將一些東西，比如命名方式、無障礙可訪問性要求、文件結構都標準化，那么團隊合作就更加緊密一致，并且能減少錯誤。

視覺語言是設計標準規范的核心部分。定義好顏色、形狀、文字、圖標、間距和動畫的樣式，可以幫助你創造更加一致的品牌感和用戶體驗。再由這些元素組合成設計系統中的組件，它們會在傳達品牌的個性時起到十分重要的作用。

沒有標準規范，決策將變得武斷且難以評判。這樣會導致設計沒法規?；?，也讓用戶體驗變得支離破碎。

提示：跨平臺特性

你的設計語言應該是能夠跨平臺的，保持在 web、iOS、Android 和 email 上的表現一致性。在你的設計系統中顯著的位置展示它們，并給出詳細的文檔，這可以幫助其他成員了解組件應該長什么樣，具有什么樣的行為。舉個例子，谷歌的 Material Design 就深入介紹了他們設計語言[3]的方方面面。

組件

組件是設計系統中可復用的代碼，也是組成用戶界面的基本元素。組件的復雜度不盡相同。當一個組件功能最小化時，比如一個按鈕組件或一個下拉菜單組件，可以讓設計系統變得更加靈活，復用程度更高。而一些復雜的組件，比如說用于展示特定數據的表格，只適用于一些特定場景，而這些場景是有限的。因此，組件可復用性越高，后期維護的工作量就越小，設計系統也就更易于規模化。

組件式開發通過代碼復用來減少開銷，而標準規范管理組件的設計目的、樣式和用法。這樣，你就可以用一個系統來輔助團隊協作，并讓所有成員更清晰地理解要做的是什么以及為什么要這么做。

設計系統的價值

讓我們來詳細地了解一下設計系統是如何從多方面解決日益增長的痛點的。

讓設計規?；?/span>

隨著團隊增長，每個設計師都專注于自己的一畝三分地，比如我只負責搜索，你只負責發現頁，他只負責賬號管理，等等。這就會導致設計語言支離破碎，就像是一個設計的通天塔，每個設計師都講著不同的語言——設計師各自解決各自的問題，沒有系統性思考。

沒有共同的設計語言來約束產品，設計流程和用戶體驗就變得不統一。當團隊沒有形成統一的設計慣例，設計評判也變得不夠高效。想要在團隊內形成統一的慣例，就必須要有一個共享的庫，來存放公共的設計模式和樣式。

一般來說這是一些靜態文件，比如說一些示例元素，但是這種方式很容易過時。所以，很多團隊會采用 Shopify Polaris[4]這種方式，系統性地展示包含組件、設計規范和設計最佳實踐，而且這個系統是動態的，跟隨業務隨時更新的。

內部的設計系統站點可以保證團隊所有人都擁有一份統一的設計數據源，并及時保持同步。

管理設計負債

隨著團隊和產品增長，會有很多負債。這里所說的負債，不是指金錢上的，而是指設計和技術上的負債。當我們為一些短期目的做設計時，就會出現設計負債。大量豐富的不可復用的和不統一的樣式或模式，就形成了設計負債，并導致設計系統的維護變成不可能的任務。隨著時間流逝，這種負債積累起來，讓我們在前進的道路上的負擔越來越重。

設計創造并不一定會產生負債，就像花錢不會恒定產生金融負債一樣。但是設計系統可以讓你的設計工作更加有計劃性，不會產生太多設計或代碼上的負債，同時也讓你的設計模式持續增長，有效促進產品迭代。

保障設計統一性

一致可復用的標準化組件可以讓產品設計變得更加統一，更容易理解，且更加可預測。同時，標準化組件也讓設計師更多地專注于如何構建更好的用戶體驗，而不是糾結于樣式的調整。

快速構建原型

基于設計系統，可以快速地構建界面、交互和流程，就像搭樂高積木一樣。這可以讓你快速構建一些產品原型或實驗性的功能，來進行測試以快速驗證想法。

快速迭代

不管是樣式迭代還是用戶體驗改進，使用設計系統都可以減輕工作量。以前可能要更改幾百行代碼，現在只需要改動幾行就可以了，迭代更加快捷無痛，可以快速靈活地探索產品方向。

提高可用性

不夠一致的界面會妨礙產品可用性。當無數各自獨立的元素和交互形式組合在一起，頁面越來越重，造成明顯的加載延遲，這將會導致極其糟糕的用戶體驗。同時，這些代碼會產生潛在的沖突，讓你的產品變得脆弱。使用設計系統之后，我們可以使用統一的全局的組件庫，而不再是獨立分散的組件，來避免這種潛在沖突，保證產品質量。

提升無障礙可訪問性

有了設計系統，我們可以在組件層面優化無障礙可訪問性，來幫助殘障人士或網絡、設備不好的人獲得更好的使用體驗，這也是一種易用性的提升。在第三節《構建你的設計系統》中，Katie Sylor-Miller 將解釋設計系統如何依照當地法律來提高無障礙可訪問性。

設計系統迷思

盡管設計系統有這么多好處，很多團隊在引進設計系統時也會發現這是一件極難推進的事。設計師會感覺自己被束縛被限制，但通常這些容易被感知的缺點反而是設計系統最大的優勢。

讓我們來一一解開這些在推廣設計系統時常常聽到的迷思吧。

迷思 1：限制性太大

迷思：負責單一模塊的設計師常常會認為這一模塊的設計應該與其他模塊不同。正因為此，一個通用的系統常常會被認為具有太多限制并且不能很好地滿足一些特定模塊的需求。

現實：設計師常常會為某一個特定模塊想出一些獨特的方案，長此以往就欠下很多設計負債。而有了設計系統，我們也可以創建一些新的設計模式來解決問題，這些設計模式同時反哺設計系統，適用于更多的模塊。

迷思 2：讓設計缺乏創造性

迷思：如果設計師被設計系統所束縛，就沒有太多發揮的余地了。前端的積壓任務中將充滿著設計樣式更新的任務。設計樣式迭代不算是小事，而且有著很大的風險，很多新的特性代碼會被不小心移除，也會對產品可用性產生負面影響。

現實：設計系統內的組件是相互依賴的，這意味著當你改動一個地方其它使用到這個組件的地方都會同步更新，你的“創造”會及時同步。這使得設計系統內的樣式更新變得很容易做到，以前可能需要幾星期做完的工作，現在只需要一個下午就搞定了。

迷思 3：設計系統是一次性的

迷思：設計系統一旦構建好，就算是完成了。

現實：設計系統是動態的、變化的，它需要跟隨產品需求不斷維護和進化。你的產品是構建于由可復用組件組成的設計系統之上的，因此設計系統的更新會自動同步于你的產品，這樣就可以花費更少的時間來維護產品更新，而是轉移到設計系統之上，也就更加容易規?；?。

總結

設計系統并不是一時的風尚或者假說。當我們想要規?；O計流程來適應快速迭代的產品節奏時，就會發現這種基于組件的設計和開發模式是一種十分可靠的解決方案。

作者：Marco Suarez

原文：https://www.designbetter.co/design-systems-handbook/introducing-design-systems

翻譯：Juuun

References

[1] 軟件危機: 

https://en.wikipedia.org/wiki/Software_crisis
[2]NATO軟件工程會議：

http://homepages.cs.ncl.ac.uk/brian.randell/NATO/nato1968.PDF 

[3] 設計語言: 

https://material.io/guidelines/style/color.html

[4] Shopify Polaris: https://polaris.shopify.com/