年少時，經常聽到身邊的同事聊一些名詞概念，羨慕之余猶豫羞于提問，導致我經常會陷入其中無法自拔，痛苦不已；過了這么多年，大多數概念都隨著工作的原因慢慢被理解和消化，或逐漸消失或不再提及。但唯獨，“設計系統”這個詞陰魂不散，反反復復的出現在我的面前，特別是在面試這個場景下，幾乎每一場都會有這個詞被提到。

也可能是每個候選人的認知不同，對設計系統的理解略有不同，有的朋友會認為設計系統是玄學，大話一套套的，根本沒卵用；也有的朋友會把設計系統和設計規范劃了等號。其實怎么理解跟輸出環境有很大的關系，不同的產品在不同的階段一定程度上對設計系統的依賴是有一定偏向性的，這就會導致設計師的認知偏差；

也源于最近做 B 端稍微多一些，不如今天就以 toB 產品為例來嘮嘮我認知下的設計系統是什么以及如何幫助設計落地執行的。

理論上來講，設計系統分為兩個大部分，一部分是指導思想，另一部分是實際產出；前者去指導后者執行，二者的關系像極了競技運動中的教練安排的“戰術”和球員場上的“執行動作”，如果用一張圖來表示，大概就是這么個事：

通過上面這張圖不難發現其實設計規范也就僅僅是系統中的一部分而已，核心在設計語言的定義上，這是一個復雜的推理過程，需要對業務和設計同時有很深的理解，牽扯到很多虛虛實實結合的部分，我試圖總結了一些平時的思考來重點說一說這幾個模塊。

1. 語言構成

需要強調的是，要設計一套“設計語言”，首先需要聚焦到“語言”這個詞上，通常我們認知里的語言無非是一套溝通方式，因為我們對他習以為常，所以并沒有更進一步的了解，我試圖去查了下語言的來源，以及為什么世界上會出現這么多語言之類的問題，搜過出來的結果很多很復雜，但概括來說就是支撐一套語言的核心分為“語言特性”以及“語言構成”這兩大部分。

第一塊，詞匯：ta 的作用是讓你表達出想法，就好比如果你跟我一樣 English is not good 的情況下，還嘚嘚瑟瑟的出國游玩，一定也經歷過用“蹦單詞+比劃”的方式去問路、點菜吧，典型的通過 word 的方式傳遞信息。

另一趴，語法，ta 會讓你更順暢的表達出自己的想法，通過對詞匯的重組和編排，信息傳遞的有效性被大大增加，你可以通過“主動賓”來陳述觀點或表達疑問，盡可能的豐富此刻你的所思所想。就像上面的例子，按照語法規則稍微調整一下，看起來就順暢多的多了~

那么如果映射到設計上，顯而易見，組件庫對應詞匯，交互流程對應語法；所以你會發現當我們不斷迭代產品的時候，我們無非就是想把產品當做一件事情講清楚罷了。

但需要注意的是，設計師喜歡用更多的組件去表達想法這個事本無可厚非，但千萬別過于執著，因為很多“組件”針對性極強，通用和復用的價值不高，這就像我們經常聽到的網絡詞匯一樣，一旦過了生命周期，這些詞就像成了過眼云煙，大概率不會再有用處。所以針對這種情況（之前的文章也有提到過），我建議要在組件的分類上下功夫，建立不同類型的分類幫助你應對不同的場景，也可以有效的避免組件庫的肥胖癥：

再就是當一套組件被創造出來，ta 需要遵循一定的規則形成一個完整的頁面，跟我們造句幾乎一模一樣；所以這個時候充當語法的交互流程就至關重要。現實情況下，往往交互形態是千變萬化的，經常性的會因為業務場景的不同創造一些流程出來；但如果是基于語言的背景下，我們需要盡可能的抽練一些標準化的規則形成語法，我們稱之為“設計模式”：

這段鬼話理解起來太麻煩了，我試著翻一下大概就是：“為了避免重復造輪子，就搞了幾個通用的流程，以保證產品開發流程的效能問題”，嗯，就這么個意思...

以 material design 為例，官方給出了很多規則，我仔細看了看，重新編組和分類了下：

我從中挑了搜索這個比較通用的模式來簡單講下；拋開組件的“點”思維，需要我們定義的是“信息交互”的“線性”流程，我試著把其中的每個環節提煉了出來，抽練了一個流程出來：

通過上圖也許你會發現“模式”注重的是流程節點的體驗感知（用戶跟產品交互的一來一往），并注重封裝成標準化方案。另外有一點，我把整個搜索的過程分為了 2 個小線程——輸入行為和消費行為，這是為了以后團隊協作更好的理解這條模式的運作方式，以及之后的拓展，舉個例子：產品經理決定加一個歷史搜索（就是顯示用戶過往的搜索結果），這個時候設計師就可以把這個功能當做一個拓展包，直接扔到這個主干里來：

綜上，模式最重要的起點和終點（可以理解成為目標和結果），那么中間的過程就是可以被隨意定制和改變的，這也是模式的靈活性。

另外，toB CRM 鼻祖 salesforce 在自己的設計網站上公布了他們的設計模式，給出了一些特定的場景下的解決方案，不過寫的相對更偏組件流程一些：

總的來說呢，設計模式在互聯網設計的發展上，一定程度把交互設計師的價值充分利用了，因為 ta 的存在，讓設計系統不再是 UI 設計師的專屬，更不是幾個顏色和字號就可以被定調的，ta 的作用一直都是幫助一款產品在成為優秀產品的道路上，傳遞出更“別具一格”且“優雅”的信息；

PS . 插個有的沒的的小話題，一個很好玩的事，如果你細心琢磨的話，也許會發現其實組件本身也是帶有一定的潛在交互，這種交互不需要你特意安插，天生就有，就好比一個按鈕擺在那，在沒有任何引導的情況下，正常人也知道點一點。所以映射到語言里，語法貌似并不是必要的（當然 ta 的存在是為了設計系統更完整，產品更好），比如這個爛大街的梗：

這種現象是著名的“貝葉斯理論”，利用相關信息總結出未知信息，也就是說我們的大腦是可以通過殘缺的信息來補足未知的信息的，人類的大腦真的是奇奇妙妙啊~

2. 語言特性

相比構成，特性這個就好理解多了，相當于設計原則這類的，我們需要通過一定的規則約束對語言有一個明確的指向；比如現代漢語就具備適應性、開放性兩大特征。

同樣的，設計系統在被不斷使用和執行的路上需要有明確的引導，一方面幫助現有產品應對迭代的需求，另一方面保證組件、模式的不斷擴容滿足各種適應性場景，與之匹配的就是“設計原則”了。

但不得不說，作為面試官我個人不是很喜歡作品集里描述設計原則的時候就 3 個詞：“簡潔”“高效”“清晰”。并不是討厭這三個詞，而是當我追問候選人為什么是這三個的時候，我得到的回復基本是 Material Design（或其他大廠的設計系統）就是這么寫的亦或是其他很蒼白的回答，這無疑是暴露了對設計系統的認知殘缺，是一個非常掉分的互動過程。其實，當 google、IBM、salesforce 在對外宣講他們的設計原則的時候，也許就只有兩個字“清晰”，但背后或許有非常多的思考，甚至超乎你我的想象。

但...異乎尋常的是，AntDesign 的設計原則寫的很"深奧"，憑我的功力真的看不出背后的東西，也不知道如何指導設計（也許他們是在探索設計哲學吧哈哈哈哈）：

在我設計過 B 端產品里，我更希望盡可能的把設計原則按照不同角色視角的方式去劃分，舉個例子：

假設現在我們正在為一款工具類 SaaS 系統做設計（0-1 階段），這個時候最好確定一個方向來綜合考慮業務訴求、產品訴求、設計訴求和最重要的用戶訴求（這基本包含了從生產到實用這條流程線上的所有角色），ta 們分別承載著不同角色的不同期望，互相成就又彼此制約；所以需要從 4 個角色的不同角度分別提取訴求：

當我們對上述各方訴求梳理清楚后，首先要精準的概括和整理這些內容的權重和占比（需要注意的是，雖然允許多個原則存在，但也要有一定的側重和比例，這種做法在順暢的環節上不會有所建樹，但在多個原則沖突的情況下為了保全大局，順應占比最大的原則是相對穩妥的選擇，一定程度上可以幫助設計師規避掉不必要的糾結或撕逼的過程）；再然后基于當下的情況產出相應的原則，形成整套設計系統的王炸：

但在實際操作中，高度整合后的設計原則雖然指明了方向，但缺失了可衡量性，這就會導致“認知偏差”的情況，因為每個人對圖例中的“高效”或“靈活”理解不同，會對同一個事物有不同的理解，就跟“小馬過河”這個典故一樣，小松鼠覺著水很深，小馬卻覺著也就那樣；也正是基于此，需要設計師們在此基礎上拆分明確的細則，幫助整個團隊建立統一認知：

到這一步基本上設計系統就被定了調了，我們可以明確對一個設計進行評判和衡量，以“清晰”為例，我們有個 B 端產品里面有個表單填寫的頁面，需要用戶提供一些個信息，前兩天，團隊一個設計師做了個方案是把表單新開 tab，但產品覺著不夠清晰，反而覺著蒙版的形式更清晰。他就很疑惑，明明信息獲得了更好的展示咋就不清晰了？

說到底，是我們在做設計定義的時候，對“清晰”的認知就是偏薄的，這個案例里面顯然第一個方案對信息的展示更加充分明了，但在這個場景下“清晰”并不僅僅指的是信息呈現，產品經理希望用戶透過浮層能確認當前處在哪一步（或哪個頁面）也同樣是一個維度；從這個 case 里，你會發現，定義一個原則真的不僅僅是搬運一個名詞這么簡單，所有的原則和特性必須遵循易于操作且合理，這樣才是一條合格且優秀的原則。

ps . Salesforce 的 Lightning 設計系統是我最喜歡的 design system 之一，原因很多，其中很重要的一條是因為他們真的是把“美”作為一個很重要的原則：

嗯~nice，非常符合設計師的三觀，也很真實，很實在哈哈哈哈~

唉媽...啰嗦了一大頓，終于講到了設計規范了，作為設計系統的中樞，設計規范承接了指導思想和設計落地兩者，更像一本說明書，我挑了個點重點說一下（前面費了太多口舌了，實在是沒有力氣再寫下去了哈哈哈哈）；

色彩體系的定制往往是重災區，最常見的做法是把顏色用色塊的方式一字排開，一排叫做品牌色，一排叫做輔助色，還有一排是灰度：

這種定義存在很大的風險，就跟菜譜一樣只告訴你需要哪些食材，不告訴你配比一樣，做出來的菜大概率是一塌糊涂，難以下咽。所以如果你正在建設一套團隊協作級別的設計規范，務必要把“協作”當做最重要的事，用比例的方式來告訴你的隊友他們應該怎么做：

同理，其他的模塊，比如字號，間距，圖標，我都建議盡可能的“場景化”，讓設計規范有一定的代入感，這樣會大大提高設計的效能和品質。

拋出這個問題，是因為經常在不同的場合聽到“設計系統是扼殺設計師的創造力”之類的觀點；我個人是很難以認同這個的，對 design system 的最大誤解就是限制設計師的想象力。首先設計系統本身就是一個龐大且復雜的設計觀集合，需要調動整個團隊的想象力和創造力，最終達到一個統一共識才有可能被實施和執行；其次，創造力并不全是設計個 btn 或者彈窗，真正能展示創造力的是像樂高一樣，通過零件（組件）拼裝成各種各樣的令人嘆為觀止的創意，那才是我理解的創造力：

另外從系統性思維上講，如果在不考慮資源的情況下，我倒是挺支持每一位設計師都自己去設計一套設計系統，因為在我們平時看來，2/3 年經驗的設計師和 10 年的設計師他們的產出物或許不會差太多，但對設計觀架構的能力千差萬別，前者依賴感覺和直覺素養做事，后者更靠縝密的邏輯和推理來做事；我更喜歡后者多一些，并不是因為他們講起自己作品的時候聽起來多么高大上，而是因為依據推理方法可以時刻保持輸出的穩定性。

如果你了解 NBA 的話，你一定知道美職籃里天賦最高的運動員 - 麥迪，他有過 35 秒 13 分驚為天人之作，把心理素質和身體極限展示的淋漓盡致，但就整個職業生涯來說，并不算特別突出，對比同時代的科比來說，他的個人/團隊成就都還顯得差點意思；天賦不算頂級的科比通過不斷的自我訓練和戰術研究能夠保持 20 年的穩定輸出，贏得了 5 個總冠軍戒指，成為了我們這一代球迷心目中的“神”。

我無意詆毀這兩大巨星，也無意內卷，只是想說，做事，終究不能托付給“天賦”和“靈感”，勤奮和努力在一定程度上也許可以幫你飛到更高。

上點小福利吧

盡管我一直堅持輸出設計觀點，但我發現好多朋友練就了 “一看就會，一用就廢” 的日常技能，所以準備了文中提到的 salesforce 公司的 Lightning Design System 源文件，希望鐵子們在學會理論的同時也能手活跟上，眼高手低不可取，眼手雙高真牛 B！附件下載！

總結一下

在各種社區我都能經常看到很多朋友問設計師該怎么進步，按我的理解可能會粗分為 3 步，第一步先把技法練扎實，第二步具備系統性思維可以推導復雜大型項目并合理調動資源，最后是開闊的視野能帶領團隊看到未來；設計系統正處在第二階段，是一個綜合性能力的體現，既包含“上層建筑”也涉及到“經濟基礎”，同時不分職能的推動著設計團隊不斷發展和進步；總的來說，還是重在日常的實踐和積累，厚積才能薄發吧~

歡迎關注作者微信公眾號：「負能量補給站」