設計體系丨如何創建設計體系？（四）

原標題：設計體系丨如何創建設計體系？（四）

編輯導語：在上一篇文章中，作者詳細介紹了設計體系的價值與缺陷，《設計體系丨設計體系有什麼用？價值與缺陷（三）》；本文作者從六個方面詳細分析了應該怎麼樣創建一個設計體系，我們一起來了解一下。

介於網上的文章大多隻是教大家如何建立“組件庫“或是”設計規範“，但卻說它這是建立”設計體系“，而本章的目的即是基於我的理解，在各種大佬的肩膀上，逐步構建一個幫助大家構建真正的設計體系的體系化方法思路。

爲了更好的理解，本系列文章核心內容我也是參照了4本書、4篇論文（其中3篇還是碩士論文）、網站文章（30+）、網站視頻（5+），相信已經囊括目前關於設計體系相關知識的半壁江山。寫到最後的感受基本類似於大佬住我心，有些寫出的話難以找回原出處，但確實可能被某個實踐者說過；所有的參考內容和推薦內容，我會在另一篇文章進行分享，感興趣的朋友可以持續關注。

在創建設計體系之前，首先我們需要思考的問題，就是目前我們是否需要建立設計體系?

如果公司存在大量的產品需要進行遠期開發和迭代，或者公司已經存在大量的設計師和前端工程師，並進行着重複工作時，這便是搭建和推行設計體系的好時機。

構建設計體系有哪些階段？

不同的人有不同的理解，因爲我是服務設計背景，因此在我的理解下，會將構建設計體系的階段拓展到組織設計方面，並且分爲以下6個階段內容：

願景建立：宣揚願景，建立目標
團隊配置：配置團隊結構與人員
資產清查：資產清查與體系用戶研究
資產建立：建立資產與體系內容
流程搭建：搭建體系運行和維護流程
體系評估：體系效果評估

後面的內容也將大致圍繞這些展開。

一、願景建立：宣揚願景，建立目標

要想從設計規範演變成設計體系，僅僅依靠組織內幾個人用愛發電是很難的，發電往往只能產出小的體系，難以長期維護；爲了實現更好的效果，我們需要從組織高層處獲取支持，並獲取更多資源用來建設體系。

我的第三篇文章講到的所有價值都可以作爲觸動組織提供更多資源的基礎，不過對不同的人需要有不同的側重點。

面對組織高層，可以側重講提高工作效率、減少維護成本和開發成本、高設計質量帶來的市場競爭力等角度出發。除此之外，有些企業可能會看重對行業的影響力和引領度而打算投資建設設計體系。
面對設計與開發團隊，可以側重談論減少設計與技術重複勞動，提升設計開發的效率，以花更多時間思索如何是實現多方面的需求，並創建一致化的品牌和流暢的用戶體驗，提高協作滿意度。

當然口說無憑，就算有第三方業務的數據還是很難說服他們，我們需要更加顯性具體的方式衡量ROI。在我們擁有初步的設計體系後，可以通過與設計和開發團隊進行類似設計衝刺的活動，來評估使用和不使用設計體系可以節省多少時間與財力，提供一個簡單的指標，來幫助獲取組織認同，獲取更多資源。

在這個過程中，我們也需要設定合適的期望以衡量設計體系的效果；以下幾個因素可以作爲合適的標準（基於Termini & Martin，2018），可以通過上述的活動推算基本指標數據，之後作爲建設設計體系的OKR中的關鍵結果的衡量指標。

易用度：用戶使用某個產品/服務來解決問題的難易程度（Ant Design，2020）。
交付量：最明顯的是使用設計體系後同等時間效果下，設計與開發的交互量的變化。
錯誤率：這個指標用來衡量如果使用設計指標後，可以消除的失誤產生幾率。
可用性：通過可用性指標測試，用來測試產品的可用性情況，另外這個方面也可用客戶滿意度來衡量。
複用率：組件被使用者多次重複使用的幾率。
團隊滿意度：可以針對現有設計與開發團隊進行內部調查，瞭解設計與開發使用設計體系的滿意度。
團隊NPS：一開始設計體系並不是強制使用的，除了依靠體系團隊的推廣外，十分依靠使用者的推薦，因此評估使用者的淨推薦值將是不錯的衡量，也能側面反應團隊滿意度。

二、團隊配置：配置團隊結構與人員

現在如果資源就緒，組織也支持我們去做，也對我們抱有一定預期和期望，那麼着重準備我們的團隊吧，配置的關鍵是根據組織和產品發展情況合理調配。

1. 選擇合適的人員

儘管叫”設計體系”，但設計師只是其中一環而已。不同的組織當然會有不同的人員構成，會有不同的適配性變化。

Nathan Curtis的文章，設計你的設計體系團隊（Designing a Systems Team，2017)結合自身建設體系的實踐經驗就認爲，需要一個包含設計、技術、管理等組成的多學科設計體系團隊來促進體系的使用和進步，在此文中也描述了不同規模團隊的人員構成推薦。

不同規模團隊的人員組成，圖片源於Nathan Curtis（2017）

設計體系團隊中的子團隊，圖片源於Nathan Curtis（2017）

無論規模大小，團隊領導者必須分別具備設計、編程和產品管理技能。同時在大型體系團隊中，將包含產品（偏設計）主管和產品（偏工程）主管；同時搭配數個全職和兼職的設計與工程人員，甚至還可以加入內容策略師、可訪問性專家、性能專家等等角色。

除了領導者之外，我們還需要找那些人？inVision的書中也提到了一個人員列表，例如：

設計師定義系統的視覺元素；
前端開發人員創建模塊化且高效的代碼；
可訪問性專家確保系統符合WCAG（網頁內容無障礙指南，全稱Web Content Accessibility Guidelines，是一套幫助開發者開發能讓殘障人士更容易訪問Web內容的國際標準）等標準；
內容策略師可以幫助團隊確定表達內容的方式和基調；
用戶研究人員可以幫助您瞭解客戶需求；
性能專家可以確保系統能快速地加載到所有設備上；
產品經理確保符合客戶與業務需求；
大領導(副總裁和主管)可以在整個公司（尤其是中高層管理層）內倡導和協調願景……

2. 選擇合適的管理模式

設計體系本身就可以作爲產品，當然也可以作爲方法論；如果把設計體系當成產品，那麼體系用戶將會有三種劃分。

基於Nikolas Klein（Figma）的劃分設計體系的成熟度（The spectrum of maturity for design systems）一文，我們可以將設計體系的用戶劃分爲創造者（Creators）、使用者（Users，原文是Consumer消費者）、貢獻者（Contributors）等三種角色。

創造者是體系結構的構建者，不僅爲現有問題提供初步設計解決方案和前端解決方案，也承擔推廣、分發、同步、質量管理、版本管理和更新等任務，是設計體系的核心團隊。
使用者是公司內外的團隊，使用設計體系中的指南、組件、資源、工具等元素來構建產品。
貢獻者是在實際使用過程中，發現現有問題，提出新的解決方案，並通過體系流程協助設計體系團隊協同更新體系的人。

設計體系團隊會跟着組織大小適應性的變化。團隊小的時候採用少量人兼職管理；而團隊逐漸發展，當產品組合足夠龐大時，就不得不併行發展，或是引入顧問或成立專門的設計體系開發者與管理者。其中的體系用戶角色也會跟着變化：

小型團隊：所有創造者都是使用者，使用者多是貢獻者；
中型團隊：部分使用者是創造者，貢獻者多來於創造者；
大型團隊：貢獻者同時來於創造者和使用者；
平臺型體系：擁有大量外部使用者依賴該體系，貢獻者不止來源於企業內部，也來源於外部使用者。

在實踐中，組織內部通常有不同的設計體系管理模式。那麼這裏的關鍵是我們如何選擇合適的設計體系關係模型？

例如Airbnb全球永遠2000餘名員工，約有60+個產品設計師，同時有全職的設計體系團隊（設計師與工程師共同組成）（Kholmatova，2017）。

設計體系專家Nathan Curtis（2015）和Salesforce的Jina Anne（2015）提出了4種設計體系團隊與產品團隊的關係模型。

如下：

獨裁模式（Solitary Model, “The Overlord”）單獨的一個設計團隊來建立設計體系，其他團隊根據需求進行使用。（一般初期的設計團隊會使用）
集中化模式（Centralized Model）.一個全職、單獨的中央的設計團隊運營支撐其他團隊使用的設計體系。（如Atlassian設計體系和Airbnb的DLS）
聯盟模式（Federated Model）多個產品團隊的設計師一起決策和管理設計體系。（如TED）
混合循環模式（Cyclical Model）。結合集中化模式與聯盟模式，有專門的管理團隊和其他內部團隊的貢獻，同時不定期會將其他產品的人員調入設計體系團隊進行管理維護；同時通過開放設計體系，還加入一些生態系統中組織外部團隊的貢獻支持。 (如Salesforce的Lightning設計體系以及目前螞蟻集團的Ant Design設計體系）

圖源自Nathan Curtis（2015）和Jina Anne（2015）提出的4種團隊關係模式

當然不同的團隊模式有不同的優缺點：

獨裁模式可以進行快速搭建，但因爲缺乏生態貢獻而限制了體系的進一步發展。
集中化模式的核心負責團隊雖然方便管理，但容易丟失對用戶的理解。
聯盟模式集成了對用戶的理解，但缺乏合適的管理和負責制度則讓設計體系容易停滯。
混合循環模式目前得到更多的使用，但操作起來也十分複雜。

三、資產清查：資產清查與體系用戶研究

大型團隊的形成往往很難一蹴而就，但只要我們召集到足夠的人手，便可以開始行動，但不是立即開展體系建設，而是在着手開始設計體系的建設之前，需要對現有資產進行清查。

當然我們使用簡單或者更加標準化的清查方式都可以，例如Brad Frost就舉例了使用在線PPT來放置截圖的方式進行清查（Brad Frost，2016）；並且在這一過程中，可以讓組織中儘可能多的人蔘與，例如UX設計師、視覺設計師、前端開發人員、後端開發人員、文案、內容策略師、產品經理等等任何的其他利益相關者，可以讓整個團隊瞭解到現有的問題，並建立共享詞彙表（Brad Frost，2016）。

圖來自Atomic Deign，P97（Brad Frost，2016）

HubSpot平臺中的所有按鈕的視覺組件

更加標準的方式則需要我們的的主力團隊來實現。除了視覺樣式之外，我們需要更加詳實的記錄出處、交互的狀態變化、交互模式等等變化；這裏其實可以找測試專家，提供一份測試用例，能更方便的探查那些隱祕的彈窗、信息通知等方式（因爲這些不容易被察覺到）。

1. 要清查哪些內容？

我將在後面的文章中，放出我基於對御三家平臺級設計體系（Apple的HIG、Google的MDS、Microsoft的FDS）和國內外企業級設計體系（Salesforce的LDS、Atlassian的ADS、螞蟻金服的AD）的資產清單。

資產清查這一過程，我們可以收集到最新的有可能繁複無比的UI組件的設計與編碼清單、內容策略、文案策略、表達溝通策略等等，以及存在於這些基礎之上的不一致現象；這些產出可以不僅讓團隊們都瞭解現在的問題有多麼嚴峻，也會讓高層領導真正意識到問題。可以幫助團隊瞭解確定設計體系的工作範圍，也可以獲取組織的資源支持。

剩下的就需要設計體系團隊對哪些模式應該保留，哪些應該走，哪些可以合併在一起等相關內容進行覈查、討論。

2. 體系用戶研究

設計體系的關鍵是體系如何與真實的人溝通，而不是組件本身。因此在我們清查、構建和迭代的過程會不斷穿插體系用戶的研究。這個過程將會讓大家知道，我們正在建設體系，希望他們即時測試和使用，提出意見。

永遠不要閉門造車，直到最後扔出個不能用的廢鐵，被體系用戶棄置。

一開始就讓每個人都參與進來，並在整個過程中與他們合作，對於您所設計的語言的成功至關重要。——Marco Lopes，TravelPerk高級產品設計師

通常來說設計體系的搭建不是從0到1，而是從0.1、0.2到1。因此我們除了瞭解現有的設計資產外，還需要知道現有的規則。設計體系的用戶包含高管、領導、管理層（關注效益目標），產品團隊中的設計師、前端工程師與產品經理等（關注實際使用效果），以及內外部社區用戶（關注輔助使用效果）。

這個過程，我們可以獲取到領導層期望目標、各個協作團隊成員的工作流、協作工具與軟件、協作規則。這裏的協作工具不只是包含純粹軟件工具，還包括那些標註筆記等任何內容。如果對資產有大致瞭解，也基本瞭解體系用戶的相關情況後，我們就可以着手建立資產。

四、資產建立：建立資產與體系內容 1. 確立定位

在建立詳細的資產內容前，可以思考一下設計體系的定位。設計體系從規模上可以分成平臺級設計體系（如Apple的HIG、Google的MDS、Microsoft的FDS）和公司級設計體系（如Atlassian的ADS、Salesforce的LDS和螞蟻金服的AD）。

平臺級設計體系除了服務自身企業團隊外，更加專注幫助生態夥伴建立生態應用；而公司級設計體系目前主要服務於企業內某些產品的設計與開發，通常也公開給外部人員使用。

並且每個組織根據自身業務特色所形成的設計體系的結構都會所不同，沒有兩個完全一致的設計體系；例如Material中就有機器學習的組件，Fluent中針對不同硬件也會有說明，Lightning中則會出現更多的數據、表單等組件，一些體系專門加入全球化與本地化的模式指南，是因爲往往這些公司需要應對更多國際化的挑戰，而對可訪問性要求高的體系的產品也多是體量大、用戶廣的產品。

2. 內容建立

我在前面的文章中已經預先提到了設計的體系的結構，接下來的重點就需要我們對三個層核心體系內容進行適應性的重塑和建立。

下面是我提出的設計體系VGLT-MO三層一環結構，幫助大家理解設計體系。

願景與原則（Vision & Principle），它們作爲設計決策的參考，指導前行。
指南（Guidelines），包含樣式指南（Style Guideline）、模式指南(Patterns Guideline)、內容指南（Content Guideline）等更多通過文字和圖像進行傳達的內容。
庫與工具（Libraries & Tools），包含組件庫（Components Libraries）、工具包（Toolkits）、協同工具（Collaborative Tools）等可以直接進行使用的內容。

一環是管理結構（Management Structure）與組織流程(Organization Process)，包圍着這三層內容，它促進整個設計體系成爲一個活的生態系統。

其中各內容的描述如下：

願景與原則（Vision & Principle）：

願景是最大的標記原則根據組織和產品的目的變化，主要作用是建立一種通用的評價標準，指導設計與開發，幫助使用人員進行評估，以形成相關團隊的決策共識。也有稱設計價值觀、設計語言的。

模式指南(Patterns Guideline)：

模式是可重用組件的集合，模式指南對功能性模式進行規則定義，其中包含大量的組件內容，但其中的重點是對如何使用組件進行定義。另外除了組件外，還會對互動方式、輸入方式、可用性等等內容進行定義。

樣式指南（Style Guideline）：

樣式指南是對大部分非功能性模塊進行規範，對如配色、交互狀態、動畫、排版、間距、圖標樣式、形狀與邊框、插畫、照片、標誌、佈局、數據可視化方式，甚至可能包括品牌身份，設計語言，聲音和語氣，寫作，模式和代碼風格指南等進行描述和定義，提供最佳用例和錯誤用例。它們大部分無法形式單獨組件，但是可以提供代碼。

內容指南（Content Guideline）：

內容指南通常無法提供代碼，但能通過描述和用例來對一些難量化的內容進行規範指導。例如語氣和音調、音效、文案風格等。

組件庫（Components Libraries）：

這是主要面向前端工程人員的工具，通常是開放的網站或者內部的文件（是文件而非文檔）。組件背後是體系中的可重用代碼的一部分，它們是應用程序接口的構建塊，開發人員可以快捷地使用它們。不同的體系中組件的大小和複雜性可能有所不同，如頭像框、對話框、彈窗、按鈕、橫幅、下拉式菜單、文本框、選擇框、菜單、導航等等。

工具包（Toolkits）：

這主要面對設計人員，提供了可供常規設計軟件打開，由設計師直接使用的文檔。一般直接可以在體系網站或在設計團隊內部流傳。

協同工具（Collaborative Tools）：

更爲前沿的設計體系搭建者，開始提供創建依託於生產力軟件的輔助工具，以進一步提升設計與開發者之間進行溝通的效率。如React-Sketch.app、Kitchen等。當然另一方面搭載設計體系的網站或文檔也算是一種協作工具。

管理結構（Management Structure）：

管理結構描述的是設計體系維護團隊的職能和構成結構，以及他們與組織的產品的關係。

組織流程（Organization Process）：

組織流程描述設計體系如何得到形成、應用、更新和推廣，是使設計體系成爲鮮活生命體的血液。

着手建立之前，我們需要了解進行資產構建的82原則：心急喫不了熱豆腐，永遠不要試圖一個一個建完，我們可以先完成80%的成分建設，再用後面的維護升級完成剩下的部分；否則預先看起來不錯的內容會在後續測試升級中將會被證明是無用的工作。

不管是願景還是原則或是指南等內容，我們都可以在持續更新中進行調整。

3. 構建體系願景與原則

我們首先可以在體系定位的基準下，構建願景（Vision），這裏的願景指設計體系的願景，願景通常是簡潔的一句話，描述設計體系要實現的效果，指導大方向；清晰的願景讓人明白該往何方前進，更容易建立動力，爲實現體驗目標和業務目標建立決策的基礎。

願景通常比較隱藏，有些體系只說明瞭自己是什麼，例如Alibaba Fusion只說自己是企業級的中後臺設計系統解決方案，而未詳細指出自己要達成的效果。

下面的設計體系的願景可以作爲參考：

Material Design System——更快地構建精美的產品
Lightning Design System——創造世界上最好的企業應用程序體驗
Polaris Design System——共同爲Shopify的所有商家打造出色的體驗
Ant Design——創造高效愉悅的工作體驗

根據願景，我們可以形成3-5條的原則，通常由簡短的單詞或短句構成，搭配詳細說明。原則描述了根據組織特色和產品特色下，該設計體系的發展方向。

我們看看Ant Design的原則：

自然：數字世界的光速迭代使得產品日益複雜，而人類意識和注意力資源有限。面對這種設計矛盾，追求「自然」交互將是 Ant Design 持之以恆的方向。

確定性：界面是用戶與系統交互的媒介，是手段而非目的。在追求「自然」交互基礎上，通過 Ant Design 創造的產品界面應是高確定性、低合作熵的狀態。

意義感：一個產品或功能被設計者創造出來不只是用戶的需要，而更多是承載用戶的某個工作使命。產品設計應充分站在工作視角，促成用戶使命的達成；同時，在「自然」、「確定」之上，兼顧用戶的人性需求，爲工作過程創造富有意義感的人機交互。

生長性：企業級產品功能的增長與用戶系統角色的演變相生相伴；設計者應爲自己創造的產品負責，提升功能、價值的可發現性。用發展的眼光做設計，充分考慮人、機兩端的共同生長。

如何建立原則？

在我參與的設計體系實踐中，其中我主要策劃了關於設計體系建立的企業共創工作坊。

這個工作坊由企業方品牌設計師、體驗設計師（偏工業設計）、用戶研究員等參與；在工作坊上，我們不僅對品牌現有典型用戶進行回顧（這些用戶均在項目中有入戶訪談過），建立對用戶對於交互體驗的需求，另外由於有品牌部成員的參與，也能結合品牌發展理念，輔助呈現在設計願景和原則上。

基於ABB的設計體系建設過程的案例和我的經歷，可以提出一種方法是：我們可以嘗試聚集產品和工程師團隊，然後劃分爲不同的小組。其中一半從業務需求和用戶需求角度進行探討，另一半從產品設計、體驗設計、前端工程師等體系用戶角度進行原則構建。

總之，我們需要在體系原則的建立中融合業務需求、用戶需求以及體系用戶的需求，通過關鍵決策，建立關鍵規則。這些規則能夠形成設計決策的評價指標，

當然詳細說明的原則讓設計與開發團隊向願景前進，能作爲評估決策的標準，並且會可以隨着體系和組織的發展不斷迭代改善，所以一開始我們不必想着完全定義清楚。

《要想建立設計體系，必須先定義設計原則》。這篇文章論述在設計原則定義上的理解，可以去看看。

4. 指南與組件建立

根據清查的資產清單內容，我們可以進一步建立指南內容：

樣式指南（包含色彩、字體、網格、標誌、材質、插畫、圖標、陰影、形狀、版式等內容）
內容指南（聲效、視頻、圖片、文案風格、語音語調等內容）
模式指南（可訪問性、環境、手勢、輸入方式、交互、動效、可用性、可訪問性、可視化定義等內容），在模式指南中會包含大量的組件（包含通用組件、導航、基礎輸入、菜單與工具條、文本、選擇器、數據展示、反饋、狀態與訊息等內容）。

指南提供最佳實踐，能夠將代碼實時渲染和呈現，並且提供明確的規則，便於使用者使用。

我認爲，每個指南中的內容的建立我們可以遵循以下流程和方式：

清查：資產清查是指南重構的基礎，在上面的步驟中，我們已做了資產清查工作。
重構：基於資產清查結果和已確立的體系願景、原則，創建可視化的內容（例如文案型的就寫出來，視覺組件就做出來，交互型組件就做出交互，聲音型的就形成聲音，重點是讓大家都能看的到、聽的到），並召集大家進行評判，確立保留的內容或重建新內容；
定義：根據確定的內容，進行代碼編輯或較詳盡的內容，形成可以組件或一些全局樣式等的代碼；
指導：對內容進一步確定統一的命名，記錄其使用規則，並且提供最佳實踐和錯誤實踐，並建立設計令牌（Design Token）。

我們創建的每個內容都需要根據業務需求在通用和靈活中抉擇。組件往往是獨立的，沒有依賴性。

通用組件可以處理多個用例，而靈活的組件可以調整和擴展以在各種環境中工作。可組合的組件可以組合起來創建新的模式；爲了可重用和可擴展，我們建立的每個模式都需要模塊化、可組合，並且需要兼有通用性和靈活性。

通常這些指南通常圍繞數字產品建立，一定會有小夥伴說，啊，我們家這個不是數字產品，你這個方法用不上。但其實無論具體產品如何，思維都是適用的。

如果說數字產品的組件庫是設計+代碼，那麼在工業設計中，有可能就是設計+材料和工藝；在視覺傳達設計中，如企業形象識別系統的樣式指南部分則是非常重要的部分，可以是設計+工藝，每個企業的袋子用的材質和工廠都能通過這種方式進行鏈接；一些人機交互設計中的非接觸式互動，如語言、手勢等，模式指南則就提升了重要程度；營銷的設計中，內容的指南就變得重要。

談談設計令牌：

協作中，共享的語言是關鍵。設計令牌（Design Token）是爲需要設計一致性的多個在線和本地產品而構建。較大的企業可能有多個子品牌，而這些子品牌若想要享受設計體系帶來的支撐，但每個子品牌又都需要不同的、品牌一致的外觀和感覺；於是Salesforce UX團隊針對這兩種情況推出了一種解決方案即設計令牌（Design Tokens）。

對設計和開發者而言，通過設計令牌標記的通用可視化語言，將改善設計者與開發人員間的交流，並且能支持個性化的定製，但又不失去整體觀。

設計令牌讓多品牌共享設計體系成爲可能，總的來說，使用設計令牌有以下特性：

增強靈活性和易維護性；
可以建立單獨的庫可以支持測試，和代碼跨版本進行發佈；
允許在多個團隊、產品和代碼庫之間共享代碼；
迫使獨立開發組件，這樣它們就不會侷限於僅一個用例；
爲強大的前端測試架構提供了基礎框架；
爲樣式指南奠定了基礎。

5. 內容裝載

所有內容製作完畢後，我們可以尋找合適的載體裝載這些內容。目前來說開發者的代碼往往可以通過在線獲取；而對於設計師，仍然需要建立設計主文檔，以儘可能囊括所有組件，並且適配現有設計軟件工具。這種方法很費效率，未來的設計體系發展中，也在嘗試打破這些現象。

目前，設計體系往往都是打破純文檔，以在線化的方式存在，但由於不同團隊預算有限，不一定每個團隊都能建立起自己的體系網站。總之，容易獲取是關鍵。

另外不管是文檔還是網站，都需要確立是否公開的問題，例如Airbnb的DLS建立在內部網站，不對外公開，也有些設計體系不公開源代碼，但公開設計資源。

6. 庫與工具建立

庫與工具（包含設計用資源、開發用資源、協同工具、學習教程等內容）。

上一步我們已經將內容進行了裝載，有些組件已經入庫了。現在進一步，我們可以將一些內容根據面向平臺的差別，而整合成面向設計者的資源文檔，以及在開源社區中建立模式庫，並放置在我們的載體中。

資源充足的團隊也可進一步建立定製化的協作工具或平臺等等，幫助設計體系進行推廣、分發、同步、質量管理、版本管理和更新等工作，而接下來就需要一個合適的流程來進行管控。

五、流程搭建：建立流程搭建與維護

設計體系存在一些通用的挑戰，如：

如何讓文檔與系統代碼保持同步？
如何處理重大變更？
如何避免性能下降？
如何建立更新的流程？
前端代碼如何進一步系統化？
設計者與開發者如何更好地協作？
······

因此我們需要組織流程的介入以幫助我們解決這些問題。

一個優秀的設計體系重要的是各個模塊間如何溝通交流而不是模塊內部的屬性的行爲，而且是與組織進行一定程度的綁定關係的，反映組織的文化。讓設計體系真正活起來的就算體系流程。

遵循敏捷開發原則的工程師，和遵循以用戶爲中心的設計師理念上的不同也容易造成在協作速度上的差異；協作工具的建立外，也需要一個合適的流程，進行統一。

統一的設計語言不應該只是一組靜態規則和單個原子。它應該是一個不斷發展的生態系統。——Karri Saarinen，Airbnb首席設計師

樣式指南是設計過程的產物。設計系統是一個活的、有資金支持的產品，有路線圖和待辦事項，服務於一個生態系統。—— Nathan Curtis，設計體系專家

通過定義清晰的流程，可以爲解決問題減少協作中的摩擦和不確定性，讓每個階段都有不同的目標和交付物。

——流程的價值

流程爲每一步提供了明確的期望，讓體系用戶可以專注於目前手頭的任務，而不用擔心下一步該做什麼。
標準化的流程可以每一步中建立數據，這些數據可以被引用並用於通知未來的迭代或修正和快速的測試使用。
流程建立了在產品創建過程中，每個相關團隊成員的角色和職責的理解——即是在正確的時間引入正確的人，使每個人的參與都有利於產出的質量。
一個可預測的過程將確保進展順利、高效和可預測，同時也提高質量和一致性。

——什麼樣的體系流程是好的流程？

總的來說，我們需要考慮對使用、定製、驗證、同步等各種情境，並形成清晰合理的流程，才能保證動態化的設計體系。

我們需要考慮以下的情境（Brad Frost,2019）：

常規使用；
使用中發現組件不存在或不符合要求；
對新組件進行原型化和審查；
進一步設計/開發和測試；
文檔化和發佈；
支持實際使用組件中發生新問題；

大圖看這個

在建立過程中，一張詳盡的路徑圖不管是內部保留還是公開，也是向自己的團隊和體系用戶表明狀態、展示價值的良好工具。這種版本控制方法，可以構建持續開發的文化。

當我們的設計體系1.0搭建完成後，設計體系團隊也有更多事情要完成；例如進一步建立知識共享的流程、公開推廣、更新、管理，甚至是輔助入職培訓。

當設計體系逐漸成熟，也會形成不同的層次，以支持不同子產品的獨立開發。分層也算是相比於設計令牌的另一種解決辦法，但也能同時去使用。

圖源自Nathan Curtis，Design System Tiers（2019-2）

接下來，我們再看一些知名設計體系的組織流程例子：

1. inVision

inVision的流程分爲6塊內容，4個驗證循環過程。

理解(Understand)：利用顧客研究獲取見解，以深入瞭解問題，並確定它如何與業務目標保持一致。PM領導這一階段，並與研究團隊合作進行訪談、收集數據，並進行競品研究。
探索(Explore)：設計團隊構思並探索數個可能的解決方案，並與產品和研究團隊合作生產線框圖、核心流程和用戶旅程。
定義(Define)：一旦確定了潛在的解決方案，產品團隊就努力讓每個人都知道成功是什麼樣的。這項工作的輸出對問題描述和成功地衡量規則。
設計(Design)：提煉解決方案是設計團隊的責任。他們與研究、產品和工程團隊合作，開發核心流程、原型，並確定技術需求。
構建(Build)：工程將設計和原型轉化爲現實。產品團隊協調質量保證、支持文檔以及銷售和營銷團隊。
學習(Learn)：觀察推出的解決方案的有效性。產品團隊與研究、設計和工程團隊合作，根據成功衡量標準收集見解，以此來指導下一步或再循環。

2. Fluent Design System

Fluent Design是一個集體的、開放的設計系統，可確保人員、團隊及其產品具有構建的基本組件和流程以建立跨平臺的連貫體驗。（Joseph McLaughlin，2019b）Fluent Design System的組織支撐流程中包含Fluent Process（流暢流程）的一種工作流程。

根據微軟全球開發者大會，我總結的流程圖片

流暢流程以共創（Co-creation）、連貫（Coherance）、創新（Innovation）作爲核心原則；在原則指導下，這種工作方法首先是和共創者參與的孵化，到和開發者與設計者的系統性開發，再到終端用戶參與下的大衆測試與評判，最後再到整個生態系統蔓延，這即爲一次流暢設計浪潮（Fluent Design Wave）循環；這種浪潮一般每半年在全球的開發者大會上發佈一次，以迭代流暢設計體系，加快體系的快速發展。(微軟開發者大會, 2019)

流暢設計體系（FDS）帶來的不僅是一個跨平臺的設計、編程和交互行爲的共享的用戶體驗框架集合，也是產品團隊跨學科工作的新方法；這種方法可以減少設計與開發間的鴻溝，簡化開發人員生態系統，讓各種合作伙伴都能從這種框架下受益，並且可以爲客戶提供全天全流程的無縫體驗。