編輯導(dǎo)語：設(shè)計(jì)在產(chǎn)品中日?？梢?，但設(shè)計(jì)體系從何而來？很多時(shí)候，我們可以基于一套架構(gòu)嚴(yán)謹(jǐn)、規(guī)則統(tǒng)一的體系框架，對(duì)產(chǎn)品表現(xiàn)層面的設(shè)計(jì)工作可以逐漸實(shí)現(xiàn)模塊化運(yùn)作；本文作者分享了關(guān)于設(shè)計(jì)體系的整體詳細(xì)介紹，我們一起來了解一下。

本文即是第一章，介紹設(shè)計(jì)體系的來源，相信讀完本系列文章的，你可以了解到以下內(nèi)容：

——WHY 為什么？

設(shè)計(jì)體系從何而來，為何出現(xiàn)？設(shè)計(jì)體系如何發(fā)展到現(xiàn)在的樣子？

——WHAT 是什么？

設(shè)計(jì)體系是什么？不是什么？關(guān)于設(shè)計(jì)體系有哪些誤區(qū)？與設(shè)計(jì)規(guī)范、組件庫、模式庫的區(qū)別是什么？有哪些現(xiàn)存的設(shè)計(jì)體系？

——HOW 如何做？

如何搭建自己公司的設(shè)計(jì)體系？

——FUTURE 設(shè)計(jì)體系的未來如何？

這篇文章有大量我的個(gè)人理解，因此難免出錯(cuò)或是不準(zhǔn)確的地方。

國內(nèi)設(shè)計(jì)和前端界對(duì)Design System主要存在兩種叫法，設(shè)計(jì)系統(tǒng)和設(shè)計(jì)體系。

看看百度詞條對(duì)兩個(gè)詞匯的解釋：

系統(tǒng)，來源于古代希臘文（systεmα），英文為system，日文音譯，后引為中文，即形容若干部分相互聯(lián)系、相互作用，形成的具有某些功能的整體。
體系，英文為structure，泛指一定范圍內(nèi)或同類的事物按照一定的秩序和內(nèi)部聯(lián)系組合而成的整體，是不同系統(tǒng)組成的系統(tǒng)。

要了解Design System，首先就得了解到它一定不是一堆UI組件，不只是設(shè)計(jì)師的事；如果稱Design System稱為“設(shè)計(jì)系統(tǒng)”，則是把它當(dāng)成“產(chǎn)品”存在了，過于靜態(tài)，失去了人之間的聯(lián)系，但恰恰是人之間的聯(lián)系才能促成優(yōu)秀設(shè)計(jì)體系的生成。

因此盡管原英文單詞不同，但依據(jù)實(shí)際表達(dá)的意思，本文偏向于認(rèn)同“設(shè)計(jì)體系”的名稱，相信你讀完之后也會(huì)認(rèn)同這樣的叫法。

一、設(shè)計(jì)體系的涌現(xiàn)：適應(yīng)組織的需要

目前來說，設(shè)計(jì)體系尚未出現(xiàn)清晰的定義，我們可以看一些設(shè)計(jì)體系的專家的定義：

“由明確的標(biāo)準(zhǔn)指導(dǎo)的可重用組件的集合，這些組件可以組裝在一起以構(gòu)建任意數(shù)量的應(yīng)用程序?！薄猈ill Fanguy（2017，inVision設(shè)計(jì)體系專家）

“一組相互關(guān)聯(lián)的模式和實(shí)例的共享，通過將一致地組織它們以服務(wù)產(chǎn)品目標(biāo)。模式（Pattern）是我們用來創(chuàng)建界面的重復(fù)元素：如用戶流、交互、按鈕、文本字段、圖標(biāo)、顏色、排版、微復(fù)制等；實(shí)例(Practices)是我們在團(tuán)隊(duì)工作中如何選擇創(chuàng)建、獲取、共享和使用這些模式?！薄?Alla Kholmatova（2017，著有設(shè)計(jì)體系：數(shù)字化產(chǎn)品設(shè)計(jì)的系統(tǒng)化方法）

“由個(gè)人、團(tuán)隊(duì)或社區(qū)記錄和發(fā)布的視覺風(fēng)格、組件和其他的庫，以作為代碼和設(shè)計(jì)工具，以便采用產(chǎn)品可以更加高效和有凝聚力?！薄狽athan Curtis（2017，設(shè)計(jì)體系咨詢專家，幫助多個(gè)企業(yè)搭建設(shè)計(jì)體系）

在本文綜合的理解下，我試著為設(shè)計(jì)體系下了更加清晰的定義：

設(shè)計(jì)體系（Design System，也可以叫設(shè)計(jì)系統(tǒng)）是可重用組件的集合，由清晰的標(biāo)準(zhǔn)引導(dǎo)，通過機(jī)制化的組織流程和具象的指南與工具加以整合，以幫助開發(fā)者（設(shè)計(jì)、工程等）高效且一致地創(chuàng)建大量的應(yīng)用，并且動(dòng)態(tài)地確保用戶體驗(yàn)的一致性。

如果你之前不太了解設(shè)計(jì)體系，可能現(xiàn)在有點(diǎn)懵，沒關(guān)系，相信讀完我這篇文章，你一定就能了解。

二、小故事：一個(gè)按鈕的旅程

試想一下，現(xiàn)在你現(xiàn)在是UX設(shè)計(jì)師A1，我們現(xiàn)在因?yàn)槟稠?xiàng)用戶需求或業(yè)務(wù)需求需要處理。

1. 那么最開始我們需要考慮是這個(gè)需求用按鈕還是用其他解決方案解決。最后我們決定了使用按鈕的方式。
2. 然后再考慮一些視覺因素，例如框線、背景塊、描述、顏色、陰影、字體等元素，每個(gè)因素都需要考慮一遍……
3. 再考慮頁面中的位置關(guān)系，在頁面靠左還是靠右？與四面保持多大間距？……
4. 再加上互動(dòng)因素，懸停的時(shí)候、點(diǎn)擊的時(shí)候、選中的時(shí)候、不可用的時(shí)候，再加上后續(xù)結(jié)果是跳出彈窗？打開新頁面？還是僅僅是頁面的小變化？……
5. 嗯，不錯(cuò)好像設(shè)計(jì)做完了，評(píng)審一下，大家似乎都同意了。然后交給視覺設(shè)計(jì)師C1處理視覺。差不多之后，再交到前端工程師小B1手上，啪啦啪啦敲一堆代碼，好像實(shí)現(xiàn)了。
6. 驗(yàn)收的時(shí)候又發(fā)現(xiàn)和最初設(shè)計(jì)并不一樣。前端怪你某個(gè)標(biāo)注沒做清楚，然后就又拉著前端改改改……
7. 如果又要做個(gè)按鈕，設(shè)計(jì)師A2與工程師B1之間又如何進(jìn)行設(shè)計(jì)連接？工程師B2如何快速修改工程師B1的代碼？他們與組織中其他的設(shè)計(jì)師AN和工程師們BN又如何連接？……
8. 又到某次軟件需要版本升級(jí)，需要對(duì)按鈕進(jìn)行統(tǒng)一的改色和調(diào)整，不過之前的幾個(gè)前端到換到其他部門了，新的前端工程師B3發(fā)現(xiàn)軟件中的按鈕，盡管都是按鈕，但代碼都不相同，他花了非常多的時(shí)間找到了各個(gè)按鈕的代碼并逐一進(jìn)行了更改……
9. 而這些僅僅是一個(gè)按鈕，如果再加入表單、選項(xiàng)卡、標(biāo)簽欄、搜索欄、樹形控件等等組件……停停停，已經(jīng)腦溢血了。

盡管A1設(shè)計(jì)師和B1工程師的自己的習(xí)慣可能類似，但由于參與人數(shù)的增多和任務(wù)量的增多，每個(gè)人都有自己的見解與習(xí)慣；考慮這一個(gè)按鈕中的每一種元素，回憶一下數(shù)學(xué)中的排列組合問題，最后將發(fā)現(xiàn)同一個(gè)問題的解決方案的組合情況將會(huì)產(chǎn)生成百上千甚至萬種可能，而這里很多都是重復(fù)工作。

怎么辦？我們需要定義明確清晰的規(guī)則，讓不同的人都能為統(tǒng)一問題達(dá)成相對(duì)一致的解決方案處理，即達(dá)成設(shè)計(jì)工程化。

設(shè)計(jì)體系便是一種解決辦法。但盡管是叫“設(shè)計(jì)體系”而不是叫“開發(fā)體系”，但這并不意味著這只是設(shè)計(jì)的事情；因此接下來，我將談?wù)勗O(shè)計(jì)體系是如何誕生的。

三、源起何處？——應(yīng)對(duì)組織的挑戰(zhàn)

上面的故事已經(jīng)從側(cè)面體現(xiàn)出，當(dāng)業(yè)務(wù)與用戶的需求迫使組織面對(duì)一系列的問題，迫使企業(yè)需要探索合適的解決方法。

總的來說，設(shè)計(jì)體系的出現(xiàn)便是用來應(yīng)對(duì)組織在敏捷、協(xié)作和債務(wù)處理等方面的需求。

——敏捷響應(yīng)需求：在多設(shè)備、多平臺(tái)的現(xiàn)在，組織不可能選擇每隔幾年再更新一個(gè)全新的數(shù)字產(chǎn)品，因?yàn)檫@意味著在交互上用戶需要重新學(xué)習(xí)，在戰(zhàn)略上這種方式的不確定性因素過大，如果失敗就意味資源的大量浪費(fèi)。

就特性而言，數(shù)字產(chǎn)品不同于實(shí)體產(chǎn)品，往往需要盡快上市，最小成本檢驗(yàn)，盡快迭代，以獲取更強(qiáng)的競爭力，而且以往寫的代碼也不會(huì)被磨損，需要定期進(jìn)行維護(hù)；因此這些便對(duì)組織滿足用戶體驗(yàn)的速度做出了要求，因此更多的組織逐漸采用如等以敏捷（Agile）和精益（Lean）思維為基礎(chǔ)的敏捷開發(fā)（Scrum）、設(shè)計(jì)沖刺（Design Sprint）等方法。

——復(fù)雜的協(xié)作鴻溝：對(duì)用戶來說，只需要點(diǎn)擊升級(jí)便可獲得最新的體驗(yàn)，但這意味著這種體驗(yàn)的即時(shí)在線化將體驗(yàn)迭代的簡單交給了用戶，而復(fù)雜就留給了組織；UX設(shè)計(jì)師、前端工程師、產(chǎn)品經(jīng)理、內(nèi)容策略師們、可訪問性專家等等組成的組織結(jié)構(gòu)和工作流程都需要得到適應(yīng)性的改變，才能提供快速迭代的流程去完成版本管理、設(shè)計(jì)管理、債務(wù)管理等工作？

Alex Schleifer（Airbnb設(shè)計(jì)副總監(jiān)）也提到這樣的情況：雖然工具的提升幫助編碼的速率和設(shè)計(jì)的效率都在提升，但最終使設(shè)計(jì)生效的是多方面的協(xié)作的結(jié)果，然而原有方式越來越多暴露出在跨學(xué)科溝通上的問題，這些依然阻礙著產(chǎn)品創(chuàng)新以實(shí)現(xiàn)更佳用戶體驗(yàn)的效率。

——債務(wù)大量累積：?這里的債務(wù)不是指經(jīng)濟(jì)上的債務(wù)，在設(shè)計(jì)上，由于設(shè)計(jì)人員的個(gè)體差別和缺乏系統(tǒng)性機(jī)制促進(jìn)設(shè)計(jì)經(jīng)驗(yàn)溝通，設(shè)計(jì)往往在長期的開發(fā)過程中提供了許多定制化的解決方案；在UI上可以體現(xiàn)為不同樣式的按鈕或顏色等、UX上可以體現(xiàn)為同一軟件上的交互邏輯混亂等，這造成了設(shè)計(jì)債務(wù)（Design Dept）。

而技術(shù)債務(wù)（Technical Dept）亦是如此，為同一個(gè)問題，不同的工程師使用不同的代碼或是令牌標(biāo)記，加大了代碼設(shè)計(jì)與維護(hù)、拓展的難度；同時(shí)，我認(rèn)為其中還存在一個(gè)債務(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è)計(jì)上的知識(shí)就越分裂，就越有可能出現(xiàn)同一問題多個(gè)定制化解決方案的情況，這會(huì)讓出現(xiàn)在工程、產(chǎn)品、設(shè)計(jì)上的債務(wù)就越龐大。

這些設(shè)計(jì)、技術(shù)、產(chǎn)品債務(wù)讓管理、維護(hù)都異常艱難；而且只要審視一下我們?nèi)粘９ぷ鞯闹茉?，就?huì)發(fā)現(xiàn)債務(wù)其實(shí)無處不在；那些雜亂的視覺形象應(yīng)用、那些不統(tǒng)一的工業(yè)產(chǎn)品材料與色彩、那些無準(zhǔn)則的交互行為、那些不一致的反饋聲音、同一數(shù)字產(chǎn)品不同的功能模塊定義等等……

時(shí)至今日，設(shè)備和用戶的多樣性都在激增，以往的標(biāo)準(zhǔn)、工作流程和基礎(chǔ)設(shè)施都難以支撐；我們用設(shè)計(jì)和開發(fā)應(yīng)對(duì)的問題越來越多，變化也越來越多，但我們一直在定制化和通用化之間無序游離。

可以在一些軟件中看到同樣的一個(gè)功能按鈕出現(xiàn)十幾種形式，而它們要解決的問題卻幾乎一樣；也可以看到那些拙劣的設(shè)計(jì)規(guī)范中，萬物歸為一種單調(diào)樣式，降低了開發(fā)成本，卻帶來用戶認(rèn)知的困難。它們都難以維護(hù)，極大地阻礙了組織創(chuàng)造體驗(yàn)、達(dá)成商業(yè)可持續(xù)和創(chuàng)新的效率。

四、組織的應(yīng)對(duì)？996還是一勞永逸？

面對(duì)著這些問題，公司只能存在幾種選擇（Suarez等人，inVison）：

• A-不改變速度雇傭更多的人（通過內(nèi)部雇傭或業(yè)務(wù)外包）；
• B-提升員工設(shè)計(jì)與開發(fā)的速度（個(gè)人能力的極致壓制，996、007）；
• C-改變工作的方式，創(chuàng)建通配式的解決方案，提高設(shè)計(jì)與代碼復(fù)用率以提升效率（如模塊化）。

大部分組織為了滿足快速發(fā)展的需要，往往更多采用A和B的方式（例如各種各樣的業(yè)務(wù)擴(kuò)充，產(chǎn)生了大量對(duì)工程和設(shè)計(jì)人員的需求，如阿里、網(wǎng)易、字節(jié)、美團(tuán)等）。

但提升人員，仍然不能解決定制化方案的拓展問題，仍然存在大量不可復(fù)用的方案，造成效率的浪費(fèi)；好比毒素累積，治標(biāo)不治本，當(dāng)達(dá)到足夠的毒素累積之后，創(chuàng)新將寸步難行。

如果不首先創(chuàng)新構(gòu)建方式，就無法創(chuàng)新產(chǎn)品，這是非常簡單的真理?！狝lex Schleifer（Airbnb設(shè)計(jì)副總監(jiān)）

雖然組織內(nèi)也一直在提升效率，但管理只能提升局部效率，工具才能帶來系統(tǒng)的變革。

設(shè)計(jì)體系的提出并不只是為了解決用戶體驗(yàn)的問題，而是適應(yīng)組織內(nèi)的開發(fā)需求。而通配式解決方案的方法則更具系統(tǒng)性、遠(yuǎn)期性。這便是設(shè)計(jì)體系的源頭，模塊化（Modularity）是一個(gè)關(guān)鍵詞。

五、設(shè)計(jì)體系的發(fā)展歷程

早在福特的時(shí)代，“流水線”思維就將生產(chǎn)流程模塊化進(jìn)而提升生產(chǎn)效率和生產(chǎn)一致性，形成大批量的工業(yè)化時(shí)代，形成了強(qiáng)勢的美國汽車工業(yè)；二戰(zhàn)之后，20世紀(jì)60年代，豐田作為日本汽車制造商的一分子運(yùn)用精益生產(chǎn)的小批量生產(chǎn)方法，注重發(fā)掘工人的創(chuàng)造力，即時(shí)解決問題，響應(yīng)需求，降低遠(yuǎn)期浪費(fèi)。 (E Ries, 2012)

回到軟件開發(fā)上來。20世紀(jì)60年代，越來越多組織發(fā)現(xiàn)軟件發(fā)展的速度已經(jīng)跟不上硬件的升級(jí)，軟件開發(fā)越來越容易緩慢、難維護(hù)且容易出錯(cuò)。在開發(fā)上，預(yù)算超支、超時(shí)運(yùn)行，在使用效果上效率和質(zhì)量都很低下；在運(yùn)維上，不符合要求、難以維護(hù)管理代碼，容易造成軟件無法交付。

硬件與軟件之間的差距以及解決這個(gè)問題而造成的困境，軟件危機(jī)（Software Crisis）便出現(xiàn)了。

沒人能對(duì)這些問題視而不見，開發(fā)者與設(shè)計(jì)師的先驅(qū)們開始探索解決方案。

1968年，第一屆北約軟件工程（NATO）會(huì)議上，道格拉斯·麥克羅伊（Douglas McIlroy）提出了基于組件（Component-based）的開發(fā)方法，通過復(fù)用代碼來提高編程潛力的方法，減少編程的工作量，同時(shí)能幫助編程工作更高效、更易于擴(kuò)展且靈活，提升軟件開發(fā)速度；因此這被認(rèn)為是有可能是解決“軟件危機(jī)”的方法之一，這種方法可以算是早期的設(shè)計(jì)體系的基礎(chǔ)雛形。（軟件危機(jī)&INvision）——維基百科，關(guān)于軟件危機(jī)的描述

而在設(shè)計(jì)界，也有先驅(qū)提出了類似方法。1977年，Alexander等人通過其書A Pattern Language，提出了模式語言（Pattern Language），期望用系統(tǒng)化的方法解決設(shè)計(jì)建筑、城鎮(zhèn)和建設(shè)方式的問題，幫助形成一種實(shí)現(xiàn)為250多種不同類型建筑的持續(xù)性方式（Koivisto，2019）；這種語言通過共享共同的模式，用共同設(shè)計(jì)的方式將更多人納入設(shè)計(jì)過程。

如果每個(gè)模式都是解決共同的問題，那么當(dāng)面向同樣的問題時(shí)，用模式等方式快速應(yīng)用以前的解決方法將可能是高效的工具；這里的模式（Pattern）便是用戶界面設(shè)計(jì)中的循環(huán)解決方式，模式庫是特定用戶界面上重復(fù)設(shè)計(jì)元素的集合。

在網(wǎng)頁開發(fā)時(shí)代，網(wǎng)頁設(shè)計(jì)師用基礎(chǔ)的網(wǎng)頁架構(gòu)就能搭載數(shù)以萬計(jì)的頁面。

21世紀(jì)初，YUI和jQuery UI等庫的引入，為開發(fā)人員提供了一套小部件和模式的工具包，以創(chuàng)建更一致的網(wǎng)站用戶界面（Forst, 2016）（例如Bootstrap是Twitter開發(fā)的基于網(wǎng)頁解決方案的前端工具包，供設(shè)計(jì)師和開發(fā)人員使用）。

但這些方法也會(huì)些有優(yōu)有劣，例如Mary Collin就曾對(duì)使用Bootstrap開發(fā)的網(wǎng)頁進(jìn)行綜合對(duì)比，結(jié)果發(fā)現(xiàn)Bootstrap容易導(dǎo)致成果缺乏獨(dú)特性，看起來外觀非常一致；但在另一方面，在移動(dòng)端響應(yīng)性和拓展性方面效果很不錯(cuò)，因?yàn)樽銐蚍€(wěn)定。

Mary Collin的一些網(wǎng)頁對(duì)比

在現(xiàn)代，互聯(lián)網(wǎng)興起，尤其是移動(dòng)互聯(lián)網(wǎng)的興起，降低了信息分發(fā)與復(fù)制的邊際成本和提供了龐大的用戶量；即時(shí)在線的網(wǎng)絡(luò)為數(shù)字產(chǎn)品的測試和快速迭代提供了可能，良好的用戶體驗(yàn)?zāi)転槠髽I(yè)創(chuàng)造的價(jià)值將遠(yuǎn)超傳統(tǒng)時(shí)代，體驗(yàn)的重要性迫使數(shù)字產(chǎn)品不得不用更快速的升級(jí)換代過程滿足用戶需求?！ㄓ彳姡?020）

但規(guī)范或庫本身是靜態(tài)的，依然具備過多的不確定性，并且缺乏對(duì)開發(fā)全鏈路的支持，尤其是未來的每一次的設(shè)計(jì)如何決策。

因此進(jìn)一步，一些通用設(shè)計(jì)資產(chǎn)(Design Assets)被逐漸固定下來，并輔以使用的規(guī)則描述，設(shè)計(jì)模式（Design Patterns）逐步形成，為協(xié)作而生，通過為重復(fù)的共同問題快速生成解決方案，并盡可能在整個(gè)組織內(nèi)保持一致以提升效率。因?yàn)轭愃频脑蚝湍康?，也同時(shí)產(chǎn)生了例如樣式指南、設(shè)計(jì)語言、內(nèi)容指南、甚至是品牌識(shí)別系統(tǒng)等等類似產(chǎn)物。

在軟件開發(fā)問題上，設(shè)計(jì)規(guī)范和設(shè)計(jì)模式成為內(nèi)部設(shè)計(jì)師們依靠復(fù)制粘貼進(jìn)行傳播的文檔，亦或是前端工程們網(wǎng)上開源共享的模式庫（Pattern libraries）或組件庫。

與設(shè)計(jì)模式不同，模塊化設(shè)計(jì)（Modular Design）引入了敏捷設(shè)計(jì)方法的思想；建立在以前的基礎(chǔ)上，讓解決方案的更快、更短的迭代，前端框架是提供特定解決方案和特定外觀和感覺的工具”（Frost，2013）。

框架本質(zhì)上是模塊化的，它們專注于單個(gè)項(xiàng)目或設(shè)計(jì)問題（Frost，2013）；對(duì)于多個(gè)設(shè)計(jì)問題，框架、模式庫或模塊化設(shè)計(jì)本身不足以系統(tǒng)地使用，這樣的背景下，便迎來了設(shè)計(jì)體系的涌現(xiàn)。

六、大量涌現(xiàn)的設(shè)計(jì)體系

2013年，Brad Forst提出了原子設(shè)計(jì)（Atomic Design）理論為設(shè)計(jì)體系的出現(xiàn)奠定了一波理論熱度，提供了更加形象化的描述說明；這讓更多人意識(shí)到這些問題的存在，并且提供了易于理解且廣泛傳播的理論基礎(chǔ)和解決方案。

Brad Forst，原子設(shè)計(jì)（Atomic Design）理論

原子設(shè)計(jì)理論將交互元素似化學(xué)因子一般逐步拆分。

• 在最底層級(jí)是原子（Atoms，例如按鈕、圖標(biāo)的最小組件等）;
• 原子構(gòu)成分子（Molecules，分子由兩個(gè)或多個(gè)攜帶自身屬性的原子組裝而成，并形成更實(shí)質(zhì)性和功能性的組件，例如由表單標(biāo)簽、輸入和按鈕組成的搜索表單）;
• 分子組成為有機(jī)體（Organisms，分子和原子組成的更大組裝體，是界面的一部分，如導(dǎo)航欄或標(biāo)題）;
• 再組成為模板（Templates，將原子、分子和有機(jī)體等相對(duì)抽象的屬性放入情境中，接近最終解決效果，但更關(guān)注底層頁面結(jié)構(gòu)）;
• 最后這些模板在設(shè)計(jì)師和工程師的協(xié)作下，變成實(shí)際的頁面（Pages）。

這是一種逐步拆分式的模塊化方法。

他建議用模式庫（Pattern Library，也被稱為用戶界面庫、組件庫、資產(chǎn)庫等）集合構(gòu)成用戶界面的可重用組件，并通過指南（Guideline）指導(dǎo)如何創(chuàng)建，以進(jìn)一步綜合了風(fēng)格指南、流程指南、設(shè)計(jì)語言等等設(shè)計(jì)指南；包括他之內(nèi)的幾位設(shè)計(jì)體系先驅(qū)都提出要進(jìn)一步整合領(lǐng)域內(nèi)語言，開始更多地使用設(shè)計(jì)體系（Design System）這樣的語言來代表類似的事物。

理論如此，實(shí)踐永遠(yuǎn)不會(huì)落下?；ヂ?lián)網(wǎng)的廣泛普及帶來用戶需求量爆炸，對(duì)公司來說，越來越多的業(yè)務(wù)量壓力和一致的體驗(yàn)需求的迫使下，越來越多的企業(yè)推出了自家的設(shè)計(jì)體系。

2014年伊始，Google推出了質(zhì)感設(shè)計(jì)體系（Material Design System），類似的時(shí)間前后Atlassian搭建了Atlassian設(shè)計(jì)體系和Airbnb也在內(nèi)部搭建設(shè)計(jì)體系（即后來的設(shè)計(jì)語言體系，DLS，Design Language System）；在此之后，一系列公司跟進(jìn)開始研究和開放自己的設(shè)計(jì)體系。

例如Apple的人機(jī)界面指南（HIG），Microsoft的流暢設(shè)計(jì)體系（Fluent Design System）、IBM的碳設(shè)計(jì)體系（Carbon Design System），Salesforce的Lightning設(shè)計(jì)體系、Shopify的Polaris設(shè)計(jì)體系,甚至一些英國、美國、澳大利亞等公共部門也推出了自己的設(shè)計(jì)體系，如英國政府的GOV.UK設(shè)計(jì)體系。

而在國內(nèi)，搭建的比較完善的有知名的螞蟻金服Ant Design設(shè)計(jì)體系，還有Element，以及View UI等中臺(tái)設(shè)計(jì)體系，以及許多存在于部門內(nèi)部、仍然只是設(shè)計(jì)規(guī)范、或者設(shè)計(jì)體系不完全體的內(nèi)容。

——插個(gè)題外話，微軟的流暢設(shè)計(jì)體系（Fluent Design System）是我這篇文章最開始的起點(diǎn)，從簡單論述微軟如何統(tǒng)一用戶體驗(yàn)聚焦到流暢設(shè)計(jì)體系。

當(dāng)然關(guān)于Fluent Design System的更多內(nèi)容，我會(huì)在本系列文章之后，單獨(dú)出篇文章描述我的發(fā)現(xiàn)【稿子都差不多了，寫著寫著就寫成了設(shè)計(jì)體系系列文章哈哈】。

我們現(xiàn)在知道設(shè)計(jì)體系是為了什么了，但在現(xiàn)在的階段，問題不是能搭建什么，而是如何能更好地搭建。

“體驗(yàn)工程的建設(shè)已經(jīng)遠(yuǎn)遠(yuǎn)不止于一套設(shè)計(jì)規(guī)范或一套組件庫，他需要一套完整的系統(tǒng)來支撐，解決內(nèi)部協(xié)作的一致性問題，解決設(shè)計(jì)系統(tǒng)更新的周期性問題，解決一群設(shè)計(jì)師與工程師如何規(guī)?；纳a(chǎn)各種業(yè)務(wù) UI 的問題，從而最終解決用戶體驗(yàn)一致性的問題“——Alibaba Fusion Design

作者：龍哩個(gè)龍 。公眾號(hào)：LONG說設(shè)計(jì)

本文由 @龍哩個(gè)龍 原創(chuàng)發(fā)布于人人都是產(chǎn)品經(jīng)理。未經(jīng)許可，禁止轉(zhuǎn)載

題圖來自Unsplash，基于CC0協(xié)議