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