2020-2-28 濤濤
這篇文章來自于 Invision 出品的書籍，圍繞規劃、設計、構建和實現設計系統的實踐經歷來指導讀者，其中包含了經驗豐富專家的真知灼見和一手經驗。我很喜歡，也分享給大家，推薦閱讀。這是一個系列，一共有 7 章，感興趣的話，持續關注吧。
20 世紀 60 年代，計算機硬件技術的升級開始超越軟件發展的速度。計算機的處理速度變得越來越快，價格也越來越便宜，但計算機軟件開發仍然處于緩慢、難以維護的境地，并且還很容易出錯。兩者之間的差距以及解決這個問題的困境被稱之為「軟件危機」。
在 1968 年的北約軟件工程會議上，道格拉斯·麥克羅伊（Douglas McIlroy）提出了基于組件開發有可能是解決「軟件危機」的方法之一。基于組件開發是一種通過復用代碼來提高編程潛力的方法，該方法能幫助編程工作更、更易于擴展。這樣做既能減少編程工作量又能提升軟件開發的速度，讓軟件更好地運用現代計算機的力量。
在 50 年后的今天，我們又面臨著類似的挑戰，只不過這一次是在設計領域。在 UI 設計中，設計的角色是在為特定需求量身定做解決方案，所以很難去基于整個應用進行擴展。
你有沒有走查過你輸出的界面，發現自己使用了幾十種類似的藍色，或者同一個按鈕不同的用法，將這些樣式組合對應到你設計的每一個 UI 界面，就會意識到一套不成體系的設計是多么的難以維護。
△ 一份 UI 樣式走查收集的成果，里面羅列的十幾種類似的按鈕樣式說明之前團隊挖的坑有多深。
在這種狀態下，設計要跟上開發的速度，公司可以選擇做以下三件事：
通過復用設計，設計系統能夠幫助團隊更好、更快地構建產品——復用性使規范成為可能。這是設計系統的核心和價值。一個設計系統是一個可復用組件的合集，由清晰的規范作為指導，組合在一起構建成各種的應用程序。
50 多年來，工程師們一直在遵循著這個理念執行工作。現在是時候讓設計充分發揮其潛力加入他們了。
你可能已經清楚地意識到，設計系統已經成為當今軟件行業的一個熱門話題，并且理由也很充分。很多企業投資設計系統，因為他們認識到產品體驗能夠帶來競爭優勢，不僅能吸引和留住客戶，更降低產品學習成本。
在重視設計系統的公司內部，通常能看見這種情況：
如果你是設計師，那么前面所說對設計的投資聽起來可能會令你很興奮，但其實也帶來很多挑戰。當一個應用由不同的團隊負責迭代各自模塊的時候，你將如何跨平臺設計一致的 UI？又如何使所有團隊能夠進行快速迭代？當團隊的設計師設計出新的獨立樣式時，你又將如何處理這種不可避免的設計需求？
要了解如何應對上述的挑戰，我們要先了解什么是設計系統。設計系統將個體和整體兩個概念各自的優點結合在一起。
1. 標準
擁有 MAC 用戶界面的技術知識是產品設計的關鍵因素，但了解用戶界面背后的理論，才能夠幫助你創造出色的產品。——蘋果人機交互指南
為了設計卓越的用戶體驗，不僅要了解設計系統背后的內容，還要了解其設計的原因。我們一般會通過建立和遵守標準來達成共識，這樣做能消除主觀性和歧義性，保證產品團隊內部不會出現摩擦和混亂。
這套標準的內容涵蓋了設計和開發。例如對命名約定、無障礙標準和文件結構等等，幫助團隊達成共識，減少出錯。
視覺語言是設計標準的核心部分。定義顏色、形狀、類型、圖標、布局和動效的樣式和用法對于創建品牌一致的用戶體驗至關重要。系統中的每個組件都包含這些元素，它們在表達品牌特性中扮演著不可或缺的角色。
沒有標準，決策時就會無據可依。這不僅不能擴展設計，還會造成復雜、差勁的用戶體驗。
超越平臺
視覺語言可以不局限于單一平臺，可以在 Web，iOS，Android 和其他平臺上延續。將規范文檔展示在設計系統網站的醒目位置，能夠幫助系統開發者了解組件的樣式和交互模式。例如，Google 的 Material Design 就深入到其產品視覺語言的各個層面。
2. 組件
組件是系統中復用代碼的一部分，它們充當應用程序界面的基礎。組件的復雜性各不相同。將組件簡化為單個功能（如按鈕或下拉菜單）可以增加其靈活性，使其更易于復用。復雜的組件，如特定類型數據的圖表，可以很好地滿足其應用場景，但是這種復雜性限制它的使用場景數量。組件的復用性越高，需要維護的次數就越少，規模也就越簡單。
基于組件的開發通過復用代碼來減少技術開銷。建立標準規范了這些組件的用途、樣式和用法。兩者結合在一起，就相當于為你的產品團隊配備了一個清晰的系統，讓他們了解到為什么和怎么做。
讓我們詳細看看設計系統如何幫助你解決一直以來的痛苦。
1. 擴展式設計
隨著團隊的成長，設計師通常會將注意力集中在應用程序的獨立功能區域，如搜索和發現、帳戶管理等。這就會導致設計碎片化，就像是一座設計的巴別塔，每個設計師都將他們的設計語言往上添。當設計師單獨而不是系統地去解決問題時，就會發生這種情況。
沒有通用設計語言統一產品和設計，用戶體驗就會開始崩潰。當缺乏設計規范時，設計討論就變得毫無用處。為了使團隊內部保持一致，必須要有一個共享的來源——可供參考的官方樣式庫。
大多數情況下的樣式庫都是靜態的內容，例如設計模版。但是靜態的參考幾乎立刻就會過時。這就是為什么有的團隊會建造像 Shopify’s Polaris 站點這樣的網站——一個設計系統站點，用該設計系統構建而成，記錄系統的所有方面，包括組件、指南和交互最佳使用場景。因為它是與系統一起構建的，所以它能夠保持其永遠是的。
對于產品團隊而言，內部設計系統站點是最佳、最易訪問的共享來源。它提供了一個引力，使團隊成員保持一致和同步。
2. 管理你的債務
隨著應用程序和團隊的時間積累，會慢慢形成債務。這種債務不是金融債務，而是技術和設計債務。這些債務是因為解決獨立問題獲得的。設計債務由大量不可復用和不一致的樣式和慣例組成，而維護它們是不可能完成的任務。隨著時間的推移，這些債務的累積會成為減緩增長的巨大負擔。
創造行為本身并不會產生債務——就像花錢本身并不會產生金融債務一樣。但使用設計系統將使你的設計和代碼保持足夠簡潔，同時仍然允許你進行升級和迭代。
3. 一致的設計
一致且重復使用的標準化組件，使你應用程序的易用性大大提升。標準化的組件還能讓設計師花更少的時間關注樣式，花更多的時間專注于提升用戶體驗。
4. 更快的原型
在設計系統下工作，你可以像玩樂高一樣快速拼湊流程和交互，構建無數的原型和方案進行快速驗證，從而幫助團隊快速獲得數據和結論。
5. 提高可用性
頁面樣式的不一致會影響產品的可用性，當 CSS 因為數不清的不一致樣式元素和交互增加時，頁面加載時間也會加長，這會導致很糟糕的用戶體驗。它還可能產生沖突的 CSS 和 JavaScript，從而可能破壞你的應用程序。通過使用設計程序，通過構建一個整體的組件庫（而不是每頁）來避免這些沖突，從而花費更少的時間來保證產品質量。
6. 建立可訪問性程序
可訪問性在組件級別就可以實現，針對殘疾人士、網速較慢和老舊的計算機上進行優化。這是一個建立易用性程序很好的方法， 在第 3 章「構建設計系統」中，Katie Sylor-Miller 解釋了設計系統如何幫助你改善產品的可用性，并保證遵守你所在國家/地區的法律。
（譯者注：美國殘疾人法案于 1990 年 7 月通過并簽署，其中有規定網站的可用性必須遵守《美國殘疾人法》（ADA）的相關內容。）
即使有上述說的這些好處，在團隊內部推行一個設計系統的時候，仍然很難說服團隊成員。設計師可能會感到局限或束縛，但通常這些被感知到的弱點正是設計系統的最大優勢。
讓我們來揭穿那些你在推行設計系統時經常會遇到的誤區吧。
誤區1：過于局限
誤區：負責深入獨立業務的設計師看到的設計標準可能會與其他需求的不一樣，因此，他們會認為通用的設計系統過于局限，可能無法滿足某些特定業務的需求。
現實：設計師通常會設計出自定義的解決方案以滿足應用中的獨立的業務，從而增加了設計和技術的負擔。而使用設計系統，這些被設計的新解決方案可以被反饋到設計系統里面，使每個人都可以使用這些改進方案。
誤區2：缺乏創造力
誤區：如果設計師被限制在一個設計系統下做設計，那么他將不能去自由地探索設計風格。前端的工作通常包含著各種樣式風格的更新。對應用程序的風格進行改版通常不是一個小任務。這也可能是一個很大的風險，因為從事這項工作會移除一部分的舊資源，可能會對可用性產生負面影響。
現實：設計系統的組成部分是相互關聯的，這意味著當一個位置進行更改時，這項更改會在整個系統中同步，這使得系統內的樣式更新工作變得輕而易舉，但影響卻大得多。以前是幾周甚至幾月的工作量，現在可以在一個下午就能完成。
誤區3：一勞永逸
誤區：設計和構建完設計系統后，工作就完成了。
現實：設計系統是有生命的，這意味著需要不斷對其進行維護和改進。但是由于應用是由設計系統的復用性組件提供支持的，因此該應用會自動同步設計系統的改進內容，從而減少維護應用程序的工作量。這就是設計系統提供的擴展能力。
設計系統不是一時流行的方法，也不是未經檢驗的假設。為了讓設計找到與技術的快速發展相匹配的同等方案，基于組件的設計和開發是一種行之有效的可靠解決方案。
現在你已經了解了創建設計系統的真正價值，讓我們在下一章中深入探討實際的設計過程吧。
文章來源：優設 作者：彩云譯設計