ToB設計系統 ——在平淡中開花結果

0 評論 5997 瀏覽 24 收藏 22 分鐘

編輯導語:產品設計師可能會因為其負責的業務項目差異而對設計系統有不一樣的理解。那么,什么是設計系統?本篇文章里,作者結合他的業務理解,以ToB產品為例,對設計系統的定義構成、設計規范等方面進行了分析,讓我們來看一下。

年少時,經常聽到身邊的同事聊一些名詞概念,羨慕之余猶豫羞于提問,導致我經常會陷入其中無法自拔,痛苦不已。

過了這么多年,大多數概念都隨著工作的原因慢慢被理解和消化,或逐漸消失或不再提及。但唯獨,“設計系統”這個詞陰魂不散,反反復復地出現在我的面前,特別是在面試這個場景下,幾乎每一場都會有這個詞被提到。

也可能是每個候選人的認知不同,對設計系統的理解略有不同,有的朋友會認為設計系統是玄學,大話一套套的,根本沒卵用;也有的朋友會把設計系統和設計規范劃了等號。

其實怎么理解跟輸出環境有很大的關系,不同的產品在不同的階段一定程度上對設計系統的依賴是有一定偏向性的,這就會導致設計師的認知偏差;也源于最近做B端稍微多一些,不如今天就以toB產品為例來嘮嘮我認知下的設計系統是什么以及如何幫助設計落地執行的。

一、設計系統構成

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

toB設計系統 - 在平平淡淡中開花結果

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

1. 語言構成

需要強調的是,要設計一套“設計語言”,首先需要聚焦到“語言”這個詞上。

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

toB設計系統 - 在平平淡淡中開花結果

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

toB設計系統 - 在平平淡淡中開花結果

另一趴,語法,ta會讓你更順暢地表達出自己的想法,通過對詞匯的重組和編排,信息傳遞的有效性被大大增加,你可以通過“主動賓”來陳述觀點或表達疑問,盡可能地豐富此刻你的所思所想。

就像上面的例子,按照語法規則稍微調整一下,看起來就順暢多的多了~

toB設計系統 - 在平平淡淡中開花結果

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

但需要注意的是,設計師喜歡用更多的組件去表達想法這個事本無可厚非,但千萬別過于執著,因為很多“組件”針對性極強,通用和復用的價值不高,這就像我們經常聽到的網絡詞匯一樣,一旦過了生命周期,這些詞就像成了過眼云煙,大概率不會再有用處。

所以針對這種情況(之前的文章也有提到過),我建議要在組件的分類上下功夫,建立不同類型的分類幫助你應對不同的場景,也可以有效地避免組件庫的肥胖癥。

toB設計系統 - 在平平淡淡中開花結果

再就是當一套組件被創造出來,ta需要遵循一定的規則形成一個完整的頁面,跟我們造句幾乎一模一樣;所以這個時候充當語法的交互流程就至關重要。

現實情況下,往往交互形態是千變萬化的,經常性地會因為業務場景的不同創造一些流程出來。但如果是基于語言的背景下,我們需要盡可能地抽練一些標準化的規則形成語法,我們稱之為“設計模式”。

toB設計系統 - 在平平淡淡中開花結果

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

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

toB設計系統 - 在平平淡淡中開花結果

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

toB設計系統 - 在平平淡淡中開花結果

通過上圖也許你會發現“模式”注重的是流程節點的體驗感知(用戶跟產品交互的一來一往),并注重封裝成標準化方案。

另外有一點,我把整個搜索的過程分為了2個個小線程——輸入行為和消費行為,這是為了以后團隊協作更好地理解這條模式的運作方式,以及之后的拓展。

舉個例子:產品經理決定加一個歷史搜索(就是顯示用戶過往的搜索結果),這個時候設計師就可以把這個功能當做一個拓展包,直接扔到這個主干里來。

toB設計系統 - 在平平淡淡中開花結果

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

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

toB設計系統 - 在平平淡淡中開花結果

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

PS:插個有的沒的的小話題,一個很好玩的事,如果你細心琢磨的話,也許會發現其實組件本身也是帶有一定的潛在交互,這種交互不需要你特意安插,天生就有。就好比一個按鈕擺在那,在沒有任何引導的情況下,正常人也知道點一點。

所以映射到語言里,語法貌似并不是必要的(當然ta的存在是為了設計系統更完整、產品更好),比如這個爛大街的梗:

toB設計系統 - 在平平淡淡中開花結果

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

2. 語言特性

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

toB設計系統 - 在平平淡淡中開花結果

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

但不得不說,作為面試官我個人不是很喜歡作品集里描述設計原則的時候就3個詞:“簡潔”“高效”“清晰”。并不是討厭這三個詞,而是當我追問候選人為什么是這三個的時候,我得到的回復基本是Material Design(或其他大廠的設計系統)就是這么寫的亦或是其他很蒼白的回答,這無疑是暴露了對設計系統的認知殘缺,是一個非常掉分的互動過程。

其實,當google、IBM、salesforce在對外宣講他們的設計原則的時候,也許就只有兩個字“清晰”,但背后或許有非常多的思考,甚至超乎你我的想象。

但……異乎尋常的是,AntDesign 的設計原則寫的很”深奧”,憑我的功力真的看不出背后的東西,也不知道如何指導設計(也許他們是在探索設計哲學吧哈哈哈哈)。

toB設計系統 - 在平平淡淡中開花結果

在我設計過B端產品里,我更希望盡可能地把設計原則按照不同角色視角的方式去劃分。

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

toB設計系統 - 在平平淡淡中開花結果

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

再然后基于當下的情況產出相應的原則,形成整套設計系統的王炸:

toB設計系統 - 在平平淡淡中開花結果

但在實際操作中,高度整合后的設計原則雖然指明了方向,但缺失了可衡量性,這就會導致“認知偏差”的情況,因為每個人對圖例中的“高效”或“靈活”理解不同,會對同一個事物有不同的理解。

就跟“小馬過河”這個典故一樣,小松鼠覺著水很深,小馬卻覺著也就那樣;也正是基于此,需要設計師們在此基礎上拆分明確的細則,幫助整個團隊建立統一認知。

toB設計系統 - 在平平淡淡中開花結果

到這一步基本上設計系統就被定了調了,我們可以明確對一個設計進行評判和衡量。

以“清晰”為例,我們有個B端產品里面有個表單填寫的頁面,需要用戶提供一些個信息。前兩天,團隊一個設計師做了個方案是把表單新開tab,但產品覺著不夠清晰,反而覺著蒙版的形式更清晰。他就很疑惑,明明信息獲得了更好的展示咋就不清晰了?

toB設計系統 - 在平平淡淡中開花結果

說到底,是我們在做設計定義的時候,對“清晰”的認知就是偏薄的。這個案例里面顯然第一個方案對信息的展示更加充分明了,但在這個場景下“清晰”并不僅僅指的是信息呈現,產品經理希望用戶透過浮層能確認當前處在哪一步(或哪個頁面)也同樣是一個維度。

從這個case里,你會發現,定義一個原則真的不僅僅是搬運一個名詞這么簡單,所有的原則和特性必須遵循易于操作且合理,這樣才是一條合格且優秀的原則。

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

toB設計系統 - 在平平淡淡中開花結果

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

二、設計指南規范

啰嗦了一大頓,終于講到了設計規范了。

作為設計系統的中樞,設計規范承接了指導思想和設計落地兩者,更像一本說明書,我挑了個點重點說一下(前面費了太多口舌了,實在是沒有力氣再寫下去了哈哈哈哈)。

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

toB設計系統 - 在平平淡淡中開花結果

這種定義存在很大的風險,就跟菜譜只告訴你需要哪些食材,不告訴你配比一樣,做出來的菜大概率是一塌糊涂,難以下咽。

所以如果你正在建設一套團隊協作級別的設計規范,務必要把“協作”當做最重要的事,用比例的方式來告訴你的隊友他們應該怎么做。

toB設計系統 - 在平平淡淡中開花結果

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

三、為什么要做設計系統

拋出這個問題,是因為經常在不同的場合聽到“設計系統是扼殺設計師的創造力”之類的觀點;我個人是很難以認同這個的,對design system的最大誤解就是限制設計師的想象力。

首先設計系統本身就是一個龐大且復雜的設計觀集合,需要調動整個團隊的想象力和創造力,最終達到一個統一共識才有可能被實施和執行。

其次,創造力并不全是設計個btn或者彈窗,真正能展示創造力的是像樂高一樣,通過零件(組件)拼裝成各種各樣的令人嘆為觀止的創意,那才是我理解的創造力。

toB設計系統 - 在平平淡淡中開花結果

另外從系統性思維上講,如果在不考慮資源的情況下,我倒是挺支持每一位設計師都自己去設計一套設計系統,因為在我們平時看來,2/3年經驗的設計師和10年的設計師他們的產出物或許不會差太多,但對設計觀架構的能力千差萬別。前者依賴感覺和直覺素養做事,后者更靠縝密的邏輯和推理來做事。

我更喜歡后者多一些,并不是因為他們講起自己作品的時候聽起來多么高大上,而是因為依據推理方法可以時刻保持輸出的穩定性。

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

toB設計系統 - 在平平淡淡中開花結果

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

四、總結一下

在各種社區我都能經常看到很多朋友問設計師該怎么進步,按我的理解可能會粗分為3步。

第一步先把技法練扎實,第二步具備系統性思維可以推導復雜大型項目并合理調動資源,最后是開闊的視野能帶領團隊看到未來。

設計系統正處在第二階段,是一個綜合性能力的體現,既包含“上層建筑”也涉及到“經濟基礎”,同時不分職能地推動著設計團隊不斷發展和進步??偟貋碚f,還是重在日常的實踐和積累,厚積才能薄發吧~

#專欄作家#

負能量補給站,微信公眾號:負能量補給站,人人都是產品經理專欄作家。專注設計觀點輸出和資源共享。

本文原創發布于人人都是產品經理,未經許可,禁止轉載

題圖來自?Unsplash,基于 CC0 協議

更多精彩內容,請關注人人都是產品經理微信公眾號或下載App
評論
評論請登錄
  1. 目前還沒評論,等你發揮!