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

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

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

1.語言構成

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

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

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

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

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

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

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

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

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

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

2.語言特性

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

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

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

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

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

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

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

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

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

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

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

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

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

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

總結一下

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