市面上的「真」·「偽」設計系統

多圖預警！流量預警！請在 Wifi 下閱讀

看完大約需要 16 分鐘

原子設計系統（下均稱為設計系統）這個詞應該已經流行很久了，像螞蟻金服最近出的 Ant Design 3.0 也說是基於「設計系統」進行構建的。(如果你沒有了解過原子設計系統，那麼我建議先去對原子設計系統做一個初步的了解。因為這篇文章並不是原子設計系統的科普文)

雖然設計系統這個概念出現了很久，但是從設計師的角度來看，業界仍然存在大量的「偽」設計系統。為什麼這麼說？

設計系統是從 Style Guide 之上發展出來的一個設計方法論。所以設計系統其實並不是解決了「設計風格」這個問題，而是在嘗試解決 Style Guide 在實踐中存在的諸多問題。

先來看看我們傳統運用 Style Guide 中存在的問題。

當明確一個設計需求後，我們根據 Style Guide 進行規範化的設計，輸出對應的一系列組件，如果 Style Guide 中沒有明確定義的時候，可能就會自己創建一些樣式，最後交付開發，可能等到產品完全上線後，才會根據之前的設計結果修訂 Style Guide 或者組件庫。

整個實踐模式如下圖所示：

這種流程存在諸多問題，比如組件庫和 Style Guide 的更新往往因為項目迭代速度快而滯後；新創建的組件與之前的 Style Guide 存在衝突；更新組件庫和 Style Guide 又要花費不少時間…

（當然我這邊說的基本都是中小型公司，像 BAT 這樣的大公司不能包含在內——一旦人多了之後，任何設計上問題就都只變成管理的問題了…）

而正是因為這種實踐模式存在諸多問題，效率上有待提升， Brad Frost 才會提出設計系統這個概念。（值得一提的是，Brad Frost 在 2013 年提出設計系統這個概念的時候， 他的團隊只有 4 個人。我想也正是因為團隊小，才更加需要效率的提升吧。）

設計系統提出的一個實踐模式是先設計系統，而後根據設計系統來完成業務與組件庫。如下圖所示：

這個好處不言自明，組件庫與業務線可以同步更新，一次修改，便可以多端響應。完美解決 Style Guide 模式中存在的種種問題。

但是問題又來了，怎麼樣才可以實現這種實踐模式呢？用程序員的話說，設計系統應該抽象哪些內容，然後再分別讓業務與 Style Guide 繼承呢？

答案就是：模塊化，組件化，原子化 。這也是為什麼設計系統被稱為原子設計的原因。

基於前面提到的，設計系統中必須做到的一點是：當你改動任何一個原子，你有自信其他所有依賴於這個原子的部件全部自動更新。只有滿足了這一點，設計系統設想中的效率、解放生產力才會真正實現。

（我個人猜測，Brad Frost 應該受到過 React 的啟發，因為 React 作為前端模塊化開發的鼻祖，其開源時間為 2013年5月，與文章中提到的 2013 年吻合，同時 Brad Frost 是前端開發者，想必很了解React。）

設計系統的落地關鍵

好了，理論的部分講完了，接下來是落地的關鍵。也只有到了這個地方，才能夠鑒別各種所謂的「設計系統」到底是不是真的設計系統。

還記得我們之前怎麼說的嗎？修改設計系統中的任何一個原子，整個系統都應該能夠被響應到。

那麼在 Sketch 中有什麼方式可以達到這樣的效果？對，分享樣式 與 嵌套符號。

只有合理利用了這兩個功能，才能真正達到設計系統的效果。如果在 Sketch 中沒有實現樣式共享，仍然只是 Style Guide，算不上一個真正的設計系統—— 沒法全局響應就意味著沒法執行「先設計系統，後業務與組件庫」的流程。

讓我們來看下現在風頭正盛的 Ant Design 組件庫。

可以看到，隨便選取的一個顏色並沒有任何共享樣式，這就意味著如果我去修改這些顏色，組件的樣式並不會跟著改變。

在查看完組件中的顏色、字體後均沒有對應的共享樣式後，基本可以斷定 Ant Design 的 Sketch 文件並沒有構成真正意義上的設計系統。

憑我的主觀判斷，這麼做的原因可能有兩個：

第一個是 Ant Design 團隊內部有一套設計系統更新的工具，可以快速對 Sketch 已存在的原子進行更新，但是並不會以共享樣式的方式保存。而因為種種原因，這個工具沒有對外發布；

第二個是 Sketch 文件發布之初就沒有想過原子層面的顏色、字體等還會被替換，因此沒有去設置共享樣式。我個人認為這種可能性會更大一些。

但是不管我如何去揣測，一個無法全局更新的 Sketch 文件，哪怕具有再多的組件，對於設計師來說，直接使用價值也是非常有限的。 因為設計師沒法把這麼多組件直接、快速地復用到自己的業務場景中，那麼這些所謂的「設計系統」往往就變成了單純的「參考圖」，缺少工程使用價值。

實際上， Ant Design 對於開發者來說價值巨大，我個人在做開發的時候用起來也非常爽。但是對於設計師來說，真正的工程價值可能就只有「設置行間距的時候總是多個 16px 就好」之類的經驗了。

（知乎上對 Ant Design 予以好評的絕大部分都是開發者，而不是設計師。可見一斑）

「偽」設計系統

那除了 Ant Design 之外，還有哪些「偽」設計系統呢？我從全網找到了大概了10來份設計系統的 Sketch 文檔，一一做了檢查與測試。（其中有半數收費，大約花了我快 200 刀，可能也沒什麼人比我更無聊的了…）

1. IBM 的 Carbon Design

2.Shopify 的 Polaris

3.Salesforce 的 Lightning Design System

4.Atlassian Design Language

以上都是大公司的 Sketch 文檔。可以看到，基本上放出來的設計系統都是「偽」設計系統，對原子做過良好定義的很少。我想究其原因還是因為不會考慮到供其他設計師「復用」這些資源供自己的項目使用吧。我更願意把它們當成是披著「設計系統的皮」的 Style Guide。

PS：更多的設計系統可以從 http://StyleGuide.io 這個網站上找，我不過是挑選了其中知名的一些了下測試。

「真」設計系統

我相信接下來的內容大家可能會更加關心，真正稱得上設計系統的有哪些呢？ 因為只有這些設計系統才能幫助提升我們日常工作的效率，讓生活變得更加愉悅。

1. UXPT

UXPT 全稱 UXPower Tools，應該是市面上真正的設計系統中最完整的一家了，同時有 Web 、移動端的設計系統，均可響應原子操作。

我在前文提到的原子級的顏色、字體、陰影樣式等等這些都可以自定義，而且一次修改，所有組件能夠同步修改。

拿修改顏色舉個例子：

UXPT 利用 Style Stacks? 的方式實現了一次修改顏色，多端修改的需求。簡單來說就是下圖所示的樣子。

（而令我非常震驚的是，他們還為此申請了專利…非常感慨設計界的基礎設施和理念遠遠比不上開發界…）

扯遠了，再回過來說，另外還有幾個很不錯的特性，比如內容自適應、自定義符號等等。

還有裝逼的開箱即用的 Style Guide ，既有白天模式，還有黑夜模式。

這個設計系統好是好，不過移動端 + PC 的合集要 80 刀，還有稍微有點貴，在 Gumroad 上賣。（上過的人都知道這是一個被 Qiang 了的網站）。

2. Frames

我個人認為它最大的優勢就是提供了近百個模板網站的模板頁，可以非常迅速地出展示頁面。

Frames 中還提供了一些可視化的圖表，但是這部分的設計和復用性都不是特別出眾。

哦對了，最後忘說了，這個設計系統賣 48 刀，也是在 Gumroad 上。

3. Rojcyk 的 iOS Blueprint

iOS Blueprint 是一個專註於 iOS 的設計系統。在業界知名度蠻高的，連 Sketch 官方都有報道它。

同時它的使用指南做的非常呆萌。

除了基本的 Library 之外，也提供了一些預先通用的模板，比如登陸註冊、忘記密碼等等。改個顏色改個名字基本上就開箱即用了。

這個設計系統便宜一些，Gumroad 上賣 20 刀。

4. Cabana

Cabana 是針對 Web 端的一個設計系統，我個人感覺它最大的特色是利用了 8 點網格系統（懂的人都懂這是啥，不懂就自己去查）。官網上這個特性也是第一個展示。這樣一來在進行排版布局的時候能夠很好地節省時間與精力。

此外它還提供了一些圖像處理的濾鏡，可以對圖片進行快速處理。

我個人雖然不大喜歡 Cabana 的風格，不過修改與自定義對於設計系統來說卻是小菜一碟。設計系統之所以為設計系統，就是能夠通過原子層面的調整，讓頁面呈現完全不一樣的效果。

Cabana 在 Gumroad 上賣 48 刀。

5. janlosert 的 Nested Symbols & Auto-Updating Styleguides

這個設計系統是網上已有的設計系統中唯一免費的存在。（我個人猜測作者可能是從 UXPT或者 Cabana 修改過來的。因為其中一些標註什麼的都一樣…）

這個設計系統和其他相比，功能上其實沒有什麼特別的。可能最大的特點就是「免費」吧。

PS: 這個作者還配套提供了一份 React 的組件代碼，在 Gumroad 上賣 9 刀。不過這些和廣大設計師朋友就沒有什麼關係了…

6. Predix

Predix 算是個大公司出品的設計系統（終於有大公司的身影了），但是仍然是這些設計系統裡面最不友好的一個。因為它沒有提供自定義的「介面」，如果要去自定義就要自己找相應的 Symbol 。

7. UIT

我厚著臉皮把自己基於 UXPT 修改的設計系統貼了上來。UIT 主要的貢獻是做了本地化處理以及提供了 Button 樣式設計的自定義。

UIT 基於 UXPT 修改，所以也沒法商用，一開始做出來也就是為了學習一下設計系統的設計流程…

我想以上這些設計系統對於小公司、獨立設計師以及新人的幫助會非常大。

一方面設計系統已經完成了大部分組件的定製，在實現業務中就不需要多考慮按鈕圓角要多大，行間距要留多少，可以更加聚焦於業務邏輯本身，節省時間精力。

另一方面，設計系統具有原子級的樣式自定義能力，我們可以針對不同需求高效地產出對應的設計系統，然後快速復用組件。

剛入行的新人也可以通過這套設計系統去學習與研究設計的邏輯與其遵守的規範，了解一些背後的設計理念。

最後再說些別的感想吧。

其實我個人對 Ant Design 的期望還是蠻高的，科學的設計方法與對細節的把控我都非常讚賞。不過可能也是因為期望越大失望也越大，AntD 對於開發者來說非常友好，開箱即用，但是從拿到的 Sketch 文件來看，團隊似乎並沒有考慮過如何幫助非 AntD 的設計師提升工作效率，解放生產力。不知道還沒有發布的 Kitchen 會有哪些驚艷的表現呢。

另外，如果 AntD 要成為設計界的 Bootstrap ，可能未來需要做的就是能夠完成原子與分子間的綁定，讓設計師也能夠享受到「開箱即用」的體驗。（我對此非常期待呢）

相比起來，Airbnb 在「解放設計師生產力」這條路上走的會更遠一些。（這可能跟創始人是設計師有關。）有興趣的童鞋可以去翻一翻他們設計團隊一篇叫 Sketch Interface 的文章，他們甚至在探索機器學習與設計系統的結合，最終達到繪製原型圖就能直接生成業務界面的目的。

之前在研究設計系統的時候，看到 Airbnb 的 Alex Schleifer 說的這句話，感觸很深刻：

Here』s the simple truth: you can』t innovate on products without first innovating the way you build them.

翻譯過來大致就是：這是一個很簡單的真理——如果不在方法層面有所創新，你就不可能在產品上有所創新。

我想我們研究設計系統也是如此，改變我們原有的設計思想、設計方式，我們才能夠以更加高效，更加優雅地姿態去創造全新的產品吧。

在前端開發中有個詞叫做「技術選型」，如果大公司的設計系統能提供原子層面的自定義，說不定等到未來設計界也會出來一個「設計選型」這樣的詞吧。真是期待那一天呢。