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