在旁聽一些分享、復盤、匯報時發現很多設計師總把設計系統掛在嘴邊，但談來談去都還是“組件”那套，什么設計模式、原子設計、design token 講來講去最后都是在講“組件”。設計系統或者設計語言就像人類的自然語言，是一個由字、詞、句、語法組成的溝通系統，只有組件就好像只有字詞，無法達到理想的溝通效果。這也是為什么我們總說設計系統（或組件）是為了提高生產效率、降低溝通成本，而實際上使用時卻常常成為設計絆腳石的原因之一。這次，我們想認真地、系統地、深入地來聊聊設計系統。

以下內容參考《設計系統》、部分網絡文章（文末附）及個人工作經驗，如有異議，歡迎探討

更多設計系統探討：

設計系統（Design System）是為了實現數字產品而組織起來的一套相互關聯的模式和共享實踐。設計系統由設計原則（Design Principal）、模式（Pattern）、組件（Component）和指令（Token）組成，它們可以被簡單地歸類為下圖：

下面分別講講這幾個概念：

一、設計原則（Principle）

設計原則指的并不是對比、對齊、強調、重復...而是團隊對于好設計的理解，這里的團隊包括了產品、開發等與產品的創建直接相關的人，目的就是讓團隊內部對于什么是好的設計有一致的標準，并提供一些可執行的指南。換句話說，我們也可以稱設計原則為設計理念，因此：

1. 設計原則的受眾是同事

設計原則是為同事而寫，尤其是設計師、產品經理、開發人員、內容運營等與產品的創建直接相關的人員，而非用戶視角。當團隊內對于好設計的理念達成共識，就可以力往一處使，減少許多爭論。所以當你不知道如何建立自身產品的設計原則時，不妨做做“用戶調研”，收集一下設計原則的“用戶”——即團隊成員對于自身產品的理解和愿景，然后試著總結一下什么樣的原則能夠遵循產品的定位，傳遞產品的精神，實現產品的愿景。

2. 提供可操作的建議

我們很常見到這樣的原則：“簡單的”“易用的”“令人愉悅的”，這樣的原則就如“上次見面還是上次”一樣是正確的廢話，我們總不會認為復雜的、無用的、令人煩躁的是好的設計吧？將正確的廢話變得正確需要提供可操作的、能實際幫助解決設計問題的指導。例如，如果我們只說設計要“簡單”，那什么是簡單呢？蘋果公司的設計原則中就有簡潔性（Simplicity）這一條，并且在原則中提供了實用建議：“專注產品的核心需求，消除不必要的細節，只保留最基本的元素”。因此當產品或設計師做設計的時候，就可以思考每一個元素是否是必要的，一定要加上這個邊框嗎？不加可以不可以呢？再比如，我們說設計原則是“一致的”，那怎么做才能做到一致的呢？Airbnb 的設計原則給出了實用了建議：“每一個小設計都應該是更大的整體的一部分，應該在系統規模上產生積極的影響，不應該是特殊的或異常的”。因此當產品或設計師做設計的時候，就可以思考這個設計在今后的產品發展中是否可被復用，現有的設計系統中是否已有設計樣式可以解決這個需求？

3. 設計原則是有觀點的，且要平衡沖突的價值觀

好的設計原則應該是有觀點的。例如在如何處理“一致性”問題上，我們上文提到 Airbnb 的觀點是不應該有異常和特殊值，而 Medium 在設計原則中對一致性問題提出了不一樣的觀點：“適當的而不是一致的（Appropriate over Consistent）：如果它更適合操作系統、設備或上下文場景，我們愿意打破一致性”。這兩個原則代表的觀點很難說孰是孰非，但都能表示清楚各自在對待某個設計問題時候的處理方式，這種方式可以幫助我們在日常設計中提供解決思路：當某個需求需要你做一個新的設計時，如果你在 airbnb 工作，那你就得謹慎思考這個新的設計是否可被現有設計系統里某個組件替代，或者這個新設計可以成為一個新的組件被復用，而如果你在 Medium 工作，那你只需要確認這個新的設計在當前的需求場景中是合適的就可以。換句話說，設計原則不應該是和稀泥的，今天追求一致性，明天追求差異化，好的設計原則應該能在實際工作中幫助我們確定優先級和平衡點。例如 Lightning 的設計原則是“清晰、高效、一致、美觀”且強調這些原則按優先級排序。因此當“美觀”與“高效”沖突時，Lightning 的設計師應該選擇“高效”，在任何時候“清晰”應該始終放在第一位。按照這種方式建立原則可以讓團隊在做設計決策時明確哪些東西應該優先考慮。

4. 將原則與真實案例結合起來

一千個讀者眼中有一千個哈姆雷特，即使是文學大師寫的原則仍然有許多種解讀方式。避免誤解的做法是將原則與實際案例結合起來，例如：

你可以從你的產品中尋找可以體現設計原則的地方，再將這些真實的例子和原則放在一起，幫助團隊更好地理解設計原則。

二、設計模式（Pattern）VS 設計組件（Component）

之所以模式和組件一起講，是因為這兩個概念經常被混淆，事實上很多一線的互聯網公司也沒有明確區分這兩個概念，而蘋果和 Material design 設計官網上有對 Pattern 和 Compinent 做出區分。

我們先來說說模式和組件分別是什么：

①模式（Pattern）是一種用于解決特定設計問題的可復現、可復用的方案；

②組件（Components）是一系列基礎原件；

單純看概念可能有些難理解，我們舉個例子進一步說明，比如 loading 是一種模式，在蘋果官網中，對 loading 模式的定義是：“在加載內容時使用，避免顯示空白或靜態頁面，這可能會讓人們認為您的應用或游戲運行緩慢或死機”，在這個定義中設計問題被明確為加載時的空白或靜態頁面，那么可復用的解決方案是什么，蘋果是這么建議的：

③盡快顯示內容：預加載內容，或在內容尚不可用的地方顯示占位符，并在加載時替換這些元素；

④清楚地傳達內容正在加載以及可能需要多長時間才能完成：對于加載時間超過 1、2 分鐘的情況，使用進度指示器來顯示內容正在加載

⑤....

在組件（component）部分，蘋果對進度指示器的設計又做出了說明，包含了 loading 條、全頁面加載、下拉刷新加載和條形指示器與旋轉指示器。也就是說，模式為問題提供解決方案，方案中會使用到組件。如果以建房子為例，模式就是設計圖紙，組件就是磚。

當然，無論是加載模式還是 toast 組件，都是互聯網的古早設計了。不同的產品在發展過程中會產生不同的模式和組件。我們在很早的一篇文章中提過直播的發展史，這么多年來，直播間也早已可以被提煉為一種模式，我們可以發現雖然市面上的直播間設計各不相同，但模式確實趨同的：

在這個直播間模式的設計圖紙下，當業務想要拓展直播類目，例如電商直播，我們需要為電商直播增加購物車時，就清楚需要加在互動操作區；當直播間需要增加互動能力，例如投票時，就清楚功能會出現在直播間活動區，當我們要對在線觀眾新增榜單時，就自然而然地把功能設置在觀眾席區。

這也就回到了為什么說模式要和產品聊，因為模式包含了對特定業務的理解，一旦設計和產品達成共識，可以免去在方案討論中的許多無意義的爭論。比如，如果產品和設計都認可直播間活動區應該置于直播間左上角，那么新加入團隊的產品就知道不能在直播間的右上角或右下角把投票能力做大做強。一方面避免了功能在頁面中毫無邏輯的堆砌，另一方面也能讓用戶形成穩定的認知，當產品上線新功能或用戶需要尋找什么功能時，可以順著使用產品過程中形成的思路找到。

順著這個案例講，我們也可以把直播間的評論消息氣泡做成組件，消息氣泡一般由直播等級、用戶昵稱、和評論信息組成：

但是只定義到這里是不夠的。作為設計方案里的磚， 需要具備靈活性和穩定性，才能便于我們復用組件節約成本。其中的靈活性體現在對組件的變體的設計（例如：支持兩行評論情況、有無直播等級情況、直播等級圖標可替換）、組件的各種交互狀態（例如：是否存在點按狀態、可點擊或不可點擊態）、對機型、字符長度、明暗模式的適配方式（例如，昵稱最多展示到 7 個字、小機型一行最多 12 個字）...穩定性體現在組件中不支持被修改的部分，例如：間距、字色、動畫等，可以減少一些由“設計師 A 覺得間距 2 好看，設計師 B 覺得間距 4 好看”引起的爭論，也讓開發有據可依。我們需要定義清楚組件里的每一個細節，才能保證設計一致性，提高開發效率， 減少重復工作量。

設計好直播間評論氣泡組件，當其他場景有需要的時候，就可以使用組件搭建方案，我們已經非常熟悉了，就不贅述了。

在大團隊中一般由平臺設計組負責整理諸如 loading 模式、toast 組件這種基礎的設計語言，由跟進具體業務的設計組例如直播設計組負責整理諸如直播間模式、評論氣泡組件這類垂直領域下的設計語言。

我們試著做個簡單的總結，設計模式是針對常見設計問題的解決方案，是一種思想和方法，設計組件是解決單點問題的基礎元素，是具體的應用工具。

三、設計指令（Token）

Design Token，可以被翻譯為“設計符號”、“設計令牌”或“設計記號”，我習慣翻譯為設計指令，它是指在設計系統中的某些具體設計數值，例如顏色（品牌色、警告色、輔助色）、字體（正文字體、標題字體）、間距等。它可以將各種設計元素標準化、系統化，且給每個取值一個功用，讓元素更加具有目的性或者意向性，比如當我們想“彰顯重要性”時，我們使用品牌色。同時也便于這些元素在不同的設計項目中被共用和重復使用。具體怎么用？舉個例子，假如產品的品牌色是#3D7FFF，那么我們就會有一條設計指令是 Brand Coler=#3D7FFF。當我們輸出標注或者開發實現時，不需要擔心設計師 A 記錯品牌色為#3D7FFC，也不需要擔心開發 B 手抖把品牌色打成#3D8FFF，只要統一語言、引用語言，就可以達到一致。

設計指令（Token）在實現上的另一個好處是，當我們要進行品牌設計升級的時候，能減少很多工作量。品牌設計是由許多小的、重復的設計點堆砌成的，例如大圓角設計可以給人年輕、包容的感受，小圓角設計給人正式、官方的感受。

因此，當我們需要進行品牌升級的時候，往往需要對全平臺重復使用到的基礎設計元素如圓角、顏色、間距進行全面修改，此時如果我們使用設計指令（Token），只需要修改指令對應的數值即可實現，而如果使用普通標注方式，就需要遍歷所有頁面逐一修改。我們僅拿 token、彈窗、及卡片信息流場景舉例，來感受下工作量差異。不同標注方式如下圖所示：

當需要進行改版工作時，不使用 token 的情況需要在所有場景中逐一修改圓角和色值，但使用 token 的情況只需要修改指令對應的數值，如下圖所示：

感受到工作量差異了嗎？日常開發可不止圓角與遮罩兩種變量，設計、開發、走查工作量將指數級翻倍。參考一下 Lightning 定義的一套 token，包含了以下幾類屬性：

不同的產品可以結合自身業務特點和 CSS 中的屬性值定義自己的 token 范圍和具體取值。總之，token 的使用有利于品牌塑造，幫助設計與開發更好地溝通，解決多端統一和設計還原問題。

小結

設計原則（Principle）、設計模式（Pattern）、設計組件（Component）、設計指令（Token），從概念到落地，無論是原子設計、設計規范還是其他概念理論，設計系統基本就是由這四個層級組成的（雖然可能不同的產品或理念對這四個層級的叫法不一，但劃分范圍大差不差都能被這四個層級包含進去）。設計系統看似給設計制定了限制與邊界，實際上因為設計是主觀的，對好的設計的理解也是主觀的，所以有邊界的設計比無邊界的設計更好做。以上只是設計系統靜態的部分，動態部分還包含了如何維護、迭代、在團隊中運轉起來，篇幅有限，下次再聊。

歡迎關注作者微信公眾號：「白話說交互」