2021-4-23 濤濤
編輯導語：設計在產品中日?？梢姡O計體系從何而來？很多時候，我們可以基于一套架構嚴謹、規則統一的體系框架，對產品表現層面的設計工作可以逐漸實現模塊化運作；本文作者分享了關于設計體系的整體詳細介紹，我們一起來了解一下。
——WHY 為什么？
設計體系從何而來，為何出現？設計體系如何發展到現在的樣子？
——WHAT 是什么？
設計體系是什么？不是什么？關于設計體系有哪些誤區？與設計規范、組件庫、模式庫的區別是什么？有哪些現存的設計體系？
——HOW 如何做？
如何搭建自己公司的設計體系？
——FUTURE 設計體系的未來如何？
這篇文章有大量我的個人理解，因此難免出錯或是不準確的地方。
國內設計和前端界對Design System主要存在兩種叫法，設計系統和設計體系。
看看百度詞條對兩個詞匯的解釋：
系統，來源于古代希臘文（systεmα），英文為system，日文音譯，后引為中文，即形容若干部分相互聯系、相互作用，形成的具有某些功能的整體。
體系，英文為structure，泛指一定范圍內或同類的事物按照一定的秩序和內部聯系組合而成的整體，是不同系統組成的系統。
要了解Design System，首先就得了解到它一定不是一堆UI組件，不只是設計師的事；如果稱Design System稱為“設計系統”，則是把它當成“產品”存在了，過于靜態，失去了人之間的聯系，但恰恰是人之間的聯系才能促成優秀設計體系的生成。
因此盡管原英文單詞不同，但依據實際表達的意思，本文偏向于認同“設計體系”的名稱，相信你讀完之后也會認同這樣的叫法。
目前來說，設計體系尚未出現清晰的定義，我們可以看一些設計體系的專家的定義：
“由明確的標準指導的可重用組件的集合，這些組件可以組裝在一起以構建任意數量的應用程序?！薄猈ill Fanguy（2017，inVision設計體系專家）
“一組相互關聯的模式和實例的共享，通過將一致地組織它們以服務產品目標。模式（Pattern）是我們用來創建界面的重復元素：如用戶流、交互、按鈕、文本字段、圖標、顏色、排版、微復制等；實例(Practices)是我們在團隊工作中如何選擇創建、獲取、共享和使用這些模式?！薄?Alla Kholmatova（2017，著有設計體系：數字化產品設計的系統化方法）
“由個人、團隊或社區記錄和發布的視覺風格、組件和其他的庫，以作為代碼和設計工具，以便采用產品可以更加高效和有凝聚力?！薄狽athan Curtis（2017，設計體系咨詢專家，幫助多個企業搭建設計體系）
在本文綜合的理解下，我試著為設計體系下了更加清晰的定義：
設計體系（Design System，也可以叫設計系統）是可重用組件的集合，由清晰的標準引導，通過機制化的組織流程和具象的指南與工具加以整合，以幫助開發者（設計、工程等）高效且一致地創建大量的應用，并且動態地確保用戶體驗的一致性。
如果你之前不太了解設計體系，可能現在有點懵，沒關系，相信讀完我這篇文章，你一定就能了解。
試想一下，現在你現在是UX設計師A1，我們現在因為某項用戶需求或業務需求需要處理。
盡管A1設計師和B1工程師的自己的習慣可能類似，但由于參與人數的增多和任務量的增多，每個人都有自己的見解與習慣；考慮這一個按鈕中的每一種元素，回憶一下數學中的排列組合問題，最后將發現同一個問題的解決方案的組合情況將會產生成百上千甚至萬種可能，而這里很多都是重復工作。
怎么辦？我們需要定義明確清晰的規則，讓不同的人都能為統一問題達成相對一致的解決方案處理，即達成設計工程化。
設計體系便是一種解決辦法。但盡管是叫“設計體系”而不是叫“開發體系”，但這并不意味著這只是設計的事情；因此接下來，我將談談設計體系是如何誕生的。
上面的故事已經從側面體現出，當業務與用戶的需求迫使組織面對一系列的問題，迫使企業需要探索合適的解決方法。
總的來說，設計體系的出現便是用來應對組織在敏捷、協作和債務處理等方面的需求。
——敏捷響應需求：在多設備、多平臺的現在，組織不可能選擇每隔幾年再更新一個全新的數字產品，因為這意味著在交互上用戶需要重新學習，在戰略上這種方式的不確定性因素過大，如果失敗就意味資源的大量浪費。
就特性而言，數字產品不同于實體產品，往往需要盡快上市，最小成本檢驗，盡快迭代，以獲取更強的競爭力，而且以往寫的代碼也不會被磨損，需要定期進行維護；因此這些便對組織滿足用戶體驗的速度做出了要求，因此更多的組織逐漸采用如等以敏捷（Agile）和精益（Lean）思維為基礎的敏捷開發（Scrum）、設計沖刺（Design Sprint）等方法。
——復雜的協作鴻溝：對用戶來說，只需要點擊升級便可獲得最新的體驗，但這意味著這種體驗的即時在線化將體驗迭代的簡單交給了用戶，而復雜就留給了組織；UX設計師、前端工程師、產品經理、內容策略師們、可訪問性專家等等組成的組織結構和工作流程都需要得到適應性的改變，才能提供快速迭代的流程去完成版本管理、設計管理、債務管理等工作？
Alex Schleifer（Airbnb設計副總監）也提到這樣的情況：雖然工具的提升幫助編碼的速率和設計的效率都在提升，但最終使設計生效的是多方面的協作的結果，然而原有方式越來越多暴露出在跨學科溝通上的問題，這些依然阻礙著產品創新以實現更佳用戶體驗的效率。
——債務大量累積： 這里的債務不是指經濟上的債務，在設計上，由于設計人員的個體差別和缺乏系統性機制促進設計經驗溝通，設計往往在長期的開發過程中提供了許多定制化的解決方案；在UI上可以體現為不同樣式的按鈕或顏色等、UX上可以體現為同一軟件上的交互邏輯混亂等，這造成了設計債務（Design Dept）。
而技術債務（Technical Dept）亦是如此，為同一個問題，不同的工程師使用不同的代碼或是令牌標記，加大了代碼設計與維護、拓展的難度；同時，我認為其中還存在一個債務，我將其稱之為產品債務（Product Dept），不同類別的產品經理等負責產品定義等職能的人員為同一產品或業務功能提供了不同，但效果相似的產品解決辦法。
而且無論你是互聯網公司，亦或是傳統產品公司，越是龐大的體系，人員就越細分，在整體設計上的知識就越分裂，就越有可能出現同一問題多個定制化解決方案的情況，這會讓出現在工程、產品、設計上的債務就越龐大。
這些設計、技術、產品債務讓管理、維護都異常艱難；而且只要審視一下我們日常工作的周遭，就會發現債務其實無處不在；那些雜亂的視覺形象應用、那些不統一的工業產品材料與色彩、那些無準則的交互行為、那些不一致的反饋聲音、同一數字產品不同的功能模塊定義等等……
時至今日，設備和用戶的多樣性都在激增，以往的標準、工作流程和基礎設施都難以支撐；我們用設計和開發應對的問題越來越多，變化也越來越多，但我們一直在定制化和通用化之間無序游離。
可以在一些軟件中看到同樣的一個功能按鈕出現十幾種形式，而它們要解決的問題卻幾乎一樣；也可以看到那些拙劣的設計規范中，萬物歸為一種單調樣式，降低了開發成本，卻帶來用戶認知的困難。它們都難以維護，極大地阻礙了組織創造體驗、達成商業可持續和創新的效率。
面對著這些問題，公司只能存在幾種選擇（Suarez等人，inVison）：
大部分組織為了滿足快速發展的需要，往往更多采用A和B的方式（例如各種各樣的業務擴充，產生了大量對工程和設計人員的需求，如阿里、網易、字節、美團等）。
但提升人員，仍然不能解決定制化方案的拓展問題，仍然存在大量不可復用的方案，造成效率的浪費；好比毒素累積，治標不治本，當達到足夠的毒素累積之后，創新將寸步難行。
如果不首先創新構建方式，就無法創新產品，這是非常簡單的真理?！狝lex Schleifer（Airbnb設計副總監）
雖然組織內也一直在提升效率，但管理只能提升局部效率，工具才能帶來系統的變革。
設計體系的提出并不只是為了解決用戶體驗的問題，而是適應組織內的開發需求。而通配式解決方案的方法則更具系統性、遠期性。這便是設計體系的源頭，模塊化（Modularity）是一個關鍵詞。
早在福特的時代，“流水線”思維就將生產流程模塊化進而提升生產效率和生產一致性，形成大批量的工業化時代，形成了強勢的美國汽車工業；二戰之后，20世紀60年代，豐田作為日本汽車制造商的一分子運用精益生產的小批量生產方法，注重發掘工人的創造力，即時解決問題，響應需求，降低遠期浪費。 (E Ries, 2012)
回到軟件開發上來。20世紀60年代，越來越多組織發現軟件發展的速度已經跟不上硬件的升級，軟件開發越來越容易緩慢、難維護且容易出錯。在開發上，預算超支、超時運行，在使用效果上效率和質量都很低下；在運維上，不符合要求、難以維護管理代碼，容易造成軟件無法交付。
硬件與軟件之間的差距以及解決這個問題而造成的困境，軟件危機（Software Crisis）便出現了。
沒人能對這些問題視而不見，開發者與設計師的先驅們開始探索解決方案。
1968年，第一屆北約軟件工程（NATO）會議上，道格拉斯·麥克羅伊（Douglas McIlroy）提出了基于組件（Component-based）的開發方法，通過復用代碼來提高編程潛力的方法，減少編程的工作量，同時能幫助編程工作更高效、更易于擴展且靈活，提升軟件開發速度；因此這被認為是有可能是解決“軟件危機”的方法之一，這種方法可以算是早期的設計體系的基礎雛形。（軟件危機&INvision）——維基百科，關于軟件危機的描述
而在設計界，也有先驅提出了類似方法。1977年，Alexander等人通過其書A Pattern Language，提出了模式語言（Pattern Language），期望用系統化的方法解決設計建筑、城鎮和建設方式的問題，幫助形成一種實現為250多種不同類型建筑的持續性方式（Koivisto，2019）；這種語言通過共享共同的模式，用共同設計的方式將更多人納入設計過程。
如果每個模式都是解決共同的問題，那么當面向同樣的問題時，用模式等方式快速應用以前的解決方法將可能是高效的工具；這里的模式（Pattern）便是用戶界面設計中的循環解決方式，模式庫是特定用戶界面上重復設計元素的集合。
在網頁開發時代，網頁設計師用基礎的網頁架構就能搭載數以萬計的頁面。
21世紀初，YUI和jQuery UI等庫的引入，為開發人員提供了一套小部件和模式的工具包，以創建更一致的網站用戶界面（Forst, 2016）（例如Bootstrap是Twitter開發的基于網頁解決方案的前端工具包，供設計師和開發人員使用）。
但這些方法也會些有優有劣，例如Mary Collin就曾對使用Bootstrap開發的網頁進行綜合對比，結果發現Bootstrap容易導致成果缺乏獨特性，看起來外觀非常一致；但在另一方面，在移動端響應性和拓展性方面效果很不錯，因為足夠穩定。
Mary Collin的一些網頁對比
在現代，互聯網興起，尤其是移動互聯網的興起，降低了信息分發與復制的邊際成本和提供了龐大的用戶量；即時在線的網絡為數字產品的測試和快速迭代提供了可能，良好的用戶體驗能為企業創造的價值將遠超傳統時代，體驗的重要性迫使數字產品不得不用更快速的升級換代過程滿足用戶需求。——（俞軍，2020）
但規范或庫本身是靜態的，依然具備過多的不確定性，并且缺乏對開發全鏈路的支持，尤其是未來的每一次的設計如何決策。
因此進一步，一些通用設計資產(Design Assets)被逐漸固定下來，并輔以使用的規則描述，設計模式（Design Patterns）逐步形成，為協作而生，通過為重復的共同問題快速生成解決方案，并盡可能在整個組織內保持一致以提升效率。因為類似的原因和目的，也同時產生了例如樣式指南、設計語言、內容指南、甚至是品牌識別系統等等類似產物。
在軟件開發問題上，設計規范和設計模式成為內部設計師們依靠復制粘貼進行傳播的文檔，亦或是前端工程們網上開源共享的模式庫（Pattern libraries）或組件庫。
與設計模式不同，模塊化設計（Modular Design）引入了敏捷設計方法的思想；建立在以前的基礎上，讓解決方案的更快、更短的迭代，前端框架是提供特定解決方案和特定外觀和感覺的工具”（Frost，2013）。
框架本質上是模塊化的，它們專注于單個項目或設計問題（Frost，2013）；對于多個設計問題，框架、模式庫或模塊化設計本身不足以系統地使用，這樣的背景下，便迎來了設計體系的涌現。
2013年，Brad Forst提出了原子設計（Atomic Design）理論為設計體系的出現奠定了一波理論熱度，提供了更加形象化的描述說明；這讓更多人意識到這些問題的存在，并且提供了易于理解且廣泛傳播的理論基礎和解決方案。
Brad Forst，原子設計（Atomic Design）理論
原子設計理論將交互元素似化學因子一般逐步拆分。
這是一種逐步拆分式的模塊化方法。
他建議用模式庫（Pattern Library，也被稱為用戶界面庫、組件庫、資產庫等）集合構成用戶界面的可重用組件，并通過指南（Guideline）指導如何創建，以進一步綜合了風格指南、流程指南、設計語言等等設計指南；包括他之內的幾位設計體系先驅都提出要進一步整合領域內語言，開始更多地使用設計體系（Design System）這樣的語言來代表類似的事物。
理論如此，實踐永遠不會落下?；ヂ摼W的廣泛普及帶來用戶需求量爆炸，對公司來說，越來越多的業務量壓力和一致的體驗需求的迫使下，越來越多的企業推出了自家的設計體系。
2014年伊始，Google推出了質感設計體系（Material Design System），類似的時間前后Atlassian搭建了Atlassian設計體系和Airbnb也在內部搭建設計體系（即后來的設計語言體系，DLS，Design Language System）；在此之后，一系列公司跟進開始研究和開放自己的設計體系。
例如Apple的人機界面指南（HIG），Microsoft的流暢設計體系（Fluent Design System）、IBM的碳設計體系（Carbon Design System），Salesforce的Lightning設計體系、Shopify的Polaris設計體系,甚至一些英國、美國、澳大利亞等公共部門也推出了自己的設計體系，如英國政府的GOV.UK設計體系。
而在國內，搭建的比較完善的有知名的螞蟻金服Ant Design設計體系，還有Element，以及View UI等中臺設計體系，以及許多存在于部門內部、仍然只是設計規范、或者設計體系不完全體的內容。
——插個題外話，微軟的流暢設計體系（Fluent Design System）是我這篇文章最開始的起點，從簡單論述微軟如何統一用戶體驗聚焦到流暢設計體系。
當然關于Fluent Design System的更多內容，我會在本系列文章之后，單獨出篇文章描述我的發現【稿子都差不多了，寫著寫著就寫成了設計體系系列文章哈哈】。
我們現在知道設計體系是為了什么了，但在現在的階段，問題不是能搭建什么，而是如何能更好地搭建。
“體驗工程的建設已經遠遠不止于一套設計規范或一套組件庫，他需要一套完整的系統來支撐，解決內部協作的一致性問題，解決設計系統更新的周期性問題，解決一群設計師與工程師如何規模化的生產各種業務 UI 的問題，從而最終解決用戶體驗一致性的問題“——Alibaba Fusion Design
文章來源：人人都是產品經理 作者：龍哩個龍
藍藍設計( www.73404.com.cn )是一家專注而深入的界面設計公司，為期望卓越的國內外企業提供卓越的UI界面設計、BS界面設計 、 cs界面設計 、 ipad界面設計 、 包裝設計 、 圖標定制 、 用戶體驗 、交互設計、 網站建設 、平面設計服務