B 端底層設計師生存存在的困境有不少，團隊不專業(yè)，需求不清晰，流程不規(guī)范之類的問題大家沒少吐槽。而我們今天分享的，是一個大家更關心的問題，即：團隊使用第三方 B 端組件庫，還要設計師有什么用？

今天的分享不是只從邏輯層面來解答，還要進入到實際操作的角度來分享，應該做什么。

一、組件庫的應用認識

要面對這個問題，就要了解為什么團隊要使用第三方組件庫，以及使用組件庫的優(yōu)缺點。

B 端討論的第三方組件庫通常是指別人開發(fā)的前端框架，通過提前開發(fā)好各類前端組件和樣式的代碼，讓其它程序員直接調用，可以快速制作可視、精美、可交互的前端頁面。簡單來說就是做了套素材，方便其他人直接調用（CSV 大法好）。

目前最主流的 B 端組件庫有下面這些：

它們都是由大廠團隊開發(fā)，且都是開源免費的項目。因為國內沒有開源的風氣，只有大廠有這個人力資源和成本來制作。而它們之所以愿意做，當然不是用愛發(fā)電做慈善，而是為了通過免費的工具來捆綁不同的團隊和開發(fā)者，擴大行業(yè)影響力。

既然大廠都做好了，小團隊奉行拿來主義也是天經地義的。因為一套項目中的前端樣式和基礎組件元素實在太多了，一個個手打可能幾周過去了，一個完整的頁面還是功能都還沒做出來。

而國內 B 端項目的基本價值觀是 —— 先讓業(yè)務跑通了，后面再優(yōu)化細節(jié)和體驗。效率優(yōu)先，就不會給充足的時間讓前端自己去重寫、搭建基礎框架。

但選用組件庫并不真的只是找了一套免費的素材那么簡單，還需要對該組件庫使用的語言、語法、架構、邏輯有足夠的理解，才能正確使用它。

換個角度，只要選擇了一套組件庫，那么項目的開發(fā)方式就被這套組件庫捆綁，程序員需要順著這套組件庫的規(guī)則做開發(fā)，才能實現(xiàn)項目的交付。

這個過程并不輕松，因為多數成熟組件庫隨著跟新和迭代越來越龐大（臃腫），規(guī)則越來越復雜，一方面需要花很多時間學習，另一方面面向不同的項目都需要花費額外的時間做適應。而且調用組件看著簡單，但是想要改它們，難度往往比重做一個新的還麻煩。

雖然用了別人寫的代碼，但最終用下來有沒有節(jié)省大量時間是存疑的。所以很多項目的前端工程師還是疲于奔命的狀態(tài)，并不會因為用了第三方庫就有閑暇和設計師打磨細節(jié)和體驗。

這里就要講到界面樣式的問題了，組件庫自帶了組件的樣式，可以直接拼湊出不同的頁面，這個過程理論上是可以略過設計環(huán)節(jié)的，程序員直接根據產品需求或者原型開發(fā)就行了。

但素材總歸是素材，參考就只是參考，想要覆蓋所有現(xiàn)實情況是不可能。不同頁面會包含的組件不一樣，復雜組件需要做調整才能滿足項目需要，或者想要的組件這里面干脆就沒有得另外找或獨立開發(fā)。

就像網上找一套再全的圖標設計素材，也很難覆蓋整套項目所需的所有圖標，往往還要額外修改或者繪制。

為了應對這種問題，這些開源組件庫的官方除了源代碼外，還會提供相應的設計素材，讓設計師可以自己調用這些設計資源做出新的組合或修改新的樣式，再讓程序員進行開發(fā)。

理想很豐滿，但實踐起來也就聊勝于無，甚至可以用 "雞肋" 來形容。最深層次的矛盾，就是設計資源里的"組件"和源代碼中的"組件"是割裂的。

即組件的開發(fā)和設計是不同步的，雖然這些框架都是大廠發(fā)布的，但說到底它們不是直接產生經濟效益的產品，對它的維護力度不會太高。而設計資源的維護尤其復雜，比如結合軟件的組件、變體功能做一個完整的組件，就包含了海量的設計圖層設置：

而設計軟件之間又不能直接互通（導入可以忽略），假設提供了 Figma 的版本，那即時、Sketch、Mastergo、Pixso、Axure 等版本，每做一個就多一倍的工作量……這就是為什么主流框架提供的設計資源總是不全的原因。

除了要制作的版本多以外，需要更新和迭代的頻率也很高。如果有看過這些開源組件庫的更新日志，你們就會發(fā)現(xiàn)它們一直再"偷偷摸摸"地更新和迭代。

這些更新代碼部分肯定已經先做好了，但不代表設計資源也會同步更新（包括規(guī)范說明），因為這些工作量太大了，所以設計資源的最后更新時間往往遠遠落后于線上版本，設計和代碼間存在大量差異。

以 Arco 為例，目前 24 年 9 月底更新到 2.64，而 Figma 的設計資源版本是 23 年 7 月的 2.5.1。

Ant 目前則更新到 v5.2，而官方設計組件庫還停留在 21 年的 v4.0 的版本，對設計資源的維護基本放棄治療靠第三方來補充了……

因為兩者不同步，所以即使開發(fā)就根據設計的組件調用相同的代碼，也可能會得到不同的結果。即使程序員一開始想跟著設計稿做，也會因為兩者內容不相同而慢慢失去耐心。

到最后就更容易演變成，設計做設計的，開發(fā)做開發(fā)的，于是設計就成為一個被孤立得環(huán)節(jié)，開發(fā)不根據設計稿完成工作，那么設計存在的價值是什么？自娛自樂嘛？

這種結果由各方面客觀因素導致，但不代表它是合理的、高效的，只是把問題和矛盾進行轉移，這個問題不是不能解決，我們會在下面解釋。

但進入細節(jié)前我們要先確定核心理念，那就是在使用了第三方組件庫的項目中，整個項目的前端工作流、開發(fā)方式都要順應這套組件庫的特性，不能只是前端程序員順應了，而設計師是游離在體制外的干擾因素……

設計工作要融入到使用組件庫的流程中去，才能和程序員形成高效、默契的配合，總結成一句話即：

面向組件庫做設計！

很多人可能認為完全用框架的內容做設計毫無難度和價值，且這種方式沒辦法得到積累和進步。這問題不是只有設計才有，對前端工程師來說也一樣，大家殊途同歸。但問題是，有些前端和設計，即使給了成熟的組件庫，他們也做不好啊……

真實的項目工作是"解決問題"，完成工作的需求讓項目能按要求交付，和根據個人的喜好以及最符合自己利益的方式去完成是截然不同的。

二、如何面向組件庫做設計

面向組件庫做設計和傳統(tǒng)的設計模式會有很大的出路，因為開發(fā)不會完全根據設計稿來做，所以要啟用不同的協(xié)作方式，包含以下四個要素：

1. 建立協(xié)作共識
2. 熟悉框架內容
3. 構建項目規(guī)范
4. 確定交付模式

1. 建立協(xié)作共識

面向組件庫做設計不是設計師自己一個人的事，是需要和前端深度配合、協(xié)作才能實現(xiàn)的結果，所以前期建立共識是最重要的一環(huán)，要讓前端有這個配合的意愿。

最好在項目前期能和前端工程師單獨溝通，確定后續(xù)配合的方式，以及需要他們完成哪些額外的工作，包括但不限于下面這些：

1. 確定組件庫差異
2. 建立項目專屬規(guī)范
3. 確定新組件開發(fā)流程
4. 確定界面實現(xiàn)流程

在這件事上很多設計師喜歡說前端、開發(fā)領導不重視設計，壓根不理你，溝通沒有用之類得話。除了少數極端的情況，多數前端在項目前期是有意愿把項目做好的，只是很多項目中設計師的工作成為了前文提過的游離在體系之外的干擾……

所以想要實現(xiàn)這個目標，就要提前表明后續(xù)要結合框架的特性做設計，為了提供給前端更可行和易于開發(fā)的方案，節(jié)省雙方的時間，提高最終的交付質量。

真正的職場協(xié)作是共贏的模式，而不是符合理論上的流程就只管自己做的爽，不管下游死活。只有雙方確定一個共贏的認識，才會往這個方向推進，而不是先預設對方有義務一定要盡心配合你的工作……

2. 熟悉框架內容

第二步熟悉框架，這個熟悉不單指看完官方的規(guī)范和資源庫內容，還要去了解代碼實現(xiàn)出來的真實組件樣式和交互是什么樣的，有哪些東西是官方說明沒寫或者不一樣的。

因為不同項目用的組件庫不同，版本也不一樣，沒有人可以幫你整理出相關的結論，只能靠你自己去調研和分析。

而組件庫內容很多，肯定不可能全部檢查到，所以挑一些核心的組件進行檢查即可。比如柵格、側邊欄、表格、表單、選擇器、彈窗等，其它次要組件即使有差異問題也不大。

檢查的方式需要程序員配合，得讓他們做一些簡單的頁面，把指定的組件在頁面里羅列出來（花不了幾分鐘）。如果前端程序員對這套框架足夠熟悉，也可以讓他們直接指出哪些組件和規(guī)范中的內容是有出入的，并展示給你看。

除了組件外，還有樣式部分也需要關注，包括色彩、字體、圖標等，最好都讓前端程序員給你解釋下實際應用的邏輯，以及存在的問題。

這個階段的任務就是了解框架的真實樣式和規(guī)則，是需要前端工程師配合的，幫助設計師建立對這套組件真實應用結果的認識。

了解越深入，那么后續(xù)工作的開展就會越順利。

3. 構建項目規(guī)范

這里要再老生常談一點，那就是組件庫里展示的設計規(guī)范是 —— 這套組件庫內包含的設計要素使用說明，具體想要怎么用設計者自己決定。

比如這些組件庫都提供了相關的色卡，但這幾百個顏色不可能每個都會在項目里使用，或者按鈕也提供了幾十種樣式，不會你的項目"正好"全都能用上吧？

所以就算跟著組件庫設計，也要從中篩選出符合項目需要的元素內容做項目設計。而這些篩選出來的東西，自然就是項目的設計規(guī)范，是一個范圍被縮小且更明確的設計標準。

我們需要創(chuàng)建一個新的項目規(guī)范文檔，并把規(guī)范內容和信息補充進去。如果對項目規(guī)范內容有什么的基本認識不夠了解的可以看之前的分享：

規(guī)范的內容主要會包含下面這些要素：

1. 柵格/響應
2. 框架/版式
3. 色彩
4. 字體
5. 圖標
6. 樣式
7. 控件/組件

首先柵格/響應，就是框架要使用的柵格系統(tǒng)和響應式模式。官方的說明里只解釋了柵格的應用邏輯，但并沒有制定具體的參數，如果項目確定要啟用柵格和響應式，那么前期就要定出具體的參數。

框架/版式即頁面的排版方法，包括主要頁面的布局形式、間距參數的應用等等。這些也要盡可能從官方提供的類型中選擇，并確定下來。

色彩則是項目中用的主要顏色內容，除了有品牌色的強制要求，否則建議項目內所有顏色的應用從官方的色卡里選，并且色彩的命名和記錄不要使用 16 進制代碼，而是使用組件庫中色彩的專屬命名。

字體同理，只有強制需要使用其它字體的英文、數字可以獨立定義，否則完全從組件庫規(guī)范里篩選出來即可。

圖標部分，雖然部分框架會提供自己的圖標庫，但往往項目中需要的圖標無法全部滿足，所以可以評估是否要使用官方的圖標作為基礎圖標，復雜的功能、導航、裝飾圖標另做。

樣式指應用的圓角、投影、透明度等設計屬性，這些同樣根據官方的標準篩選制定就可以。

而控件/組件部分則是最復雜的部分，它們的整理是在項目推進的過程中逐一添加的。簡單的控件可以完全使用官方的樣式來完成，但是稍微復雜的組件就另當別論了。

一方面創(chuàng)建這些組件要根據真實的樣式來實現(xiàn)，另一方產品功能的實現(xiàn)，往往都包含對原有組件的調整，設計師需要在真實樣式的基礎上做出符合開發(fā)邏輯的改動。

比如表格組件，對不同列有排序的要求，但使用的組件庫里的表格沒有這個功能，那就只能選擇把排序做成表單形式放到表格外部去。

所以，對應組件在制作中就需要和前端溝通設計的可行性，不是只從組件庫里挑出來就可以。

而組件的不同狀態(tài)，可以選擇性的制作，對于樣式、內容改動很小的組件，只要置入默認的模式即可，其余的遵照系統(tǒng)默認的設置。而改動大的那些，則要把所有狀態(tài)都制作出來，才能被正確的開發(fā)。

對于自定義組件同理，當官方組件實在滿足不了功能需求，需要設計一些新的組件時，也要把所有狀態(tài)都制作出來，且要和開發(fā)溝通一遍開發(fā)的可行性。

整套設計規(guī)范的定義不止是樣式的篩選，還有非常重要的命名方式以及 DesignToken 的應用，如果不了解的可以看我之前的掃盲：

在獨立設計的項目規(guī)范內我不推薦使用太復雜的 DesignToken，但在面向組件庫設計時這些東西就需要一個不落。因為開發(fā)調用樣式和組件是需要使用 DesignToken 完成的，所有應用了官方原來的樣式和控件、組件都要在命名中和原來保持一致。

而非組件庫內的樣式、組件，則建議使用一套新的命名體系，和原來的命名隔離開，更容易識別和維護。這也需要和前端工程師商量，讓他們來定義 Token 的命名規(guī)則最好，我們只要執(zhí)行這個標準即可。

盡可能讓程序員在前期對這些標準組件做一次定義，和規(guī)范中的組件樣式同步，而不要放在后續(xù)一個個改，才能保證更高的效率。

4. 確定交付模式

定義完規(guī)范，就要在正式的界面設計中進行應用。在面向規(guī)范進行設計時，設計稿不是作為一個標準的、讓開發(fā)還原的樣式，而是一個應用了哪些樣式和組件的示意。

因為還包含一系列的組件篩選和挑選、變更，以及交互邏輯，設計師出圖的結果就是幫程序員指定了"具體的組件類型和樣式"，遠勝過產品給的粗糙原型圖，這可以節(jié)省掉程序員得根據產品原型的空缺腦補這些內容的時間精力。

作為一個示意，程序員核心關注得是頁面的內容，以及排列、交互的方式。我們在這里使用規(guī)范里的樣式和組件庫，他們同樣也是在開發(fā)過程中調用這些內容和 Token。所以頁面交付最重要的東西除了文字信息就是對規(guī)范的復用，保證組件和樣式的命名都是準確可用的。

在設計標注中，也只要圍繞在自定義樣式和組件這些新增內容做標注即可，確保前端不會漏看和理解錯誤。

如果最終實現(xiàn)的效果和開發(fā)的差異很大，我們要檢查的是項目規(guī)范代碼內的準確性，而不是光扣一個頁面的樣式。

同時，以開發(fā)結果為導向的設計，往往也不用過于細致，因為組件里有什么設計、細節(jié)都是規(guī)范階段定好的，不用把時間過多的花在單一頁面的樣式優(yōu)化上。反正一開始我們就有預期實現(xiàn)的結果和設計不一定是完全匹配的，糾結細枝末節(jié)不如去找源頭有效。

實現(xiàn)以上的工作流程，就是面向組件庫設計的方法，這可以極大的增加前端實現(xiàn)界面的速度和完成度，也能大幅度減少設計和前端之間的矛盾。

在你們真正理解完這套流程和邏輯時，就會明白與其稱它為面向組件庫設計，不如叫面向結果做設計。

設計師是為了在有限的時間里結合前端工程師實現(xiàn)最優(yōu)的落地結果，而不是在有限的時間里讓你做出最好的設計圖……

結尾

這次分享的內容比較超綱，需要有一定經驗才能理解，不要認為只是設計層面需要搞那么麻煩。

實際上對多數使用組件庫的前端來說完成項目也是一團亂麻，它們的實際工作內容就是 —— 用一套別人寫的規(guī)定特別多局限性還很大的代碼，硬套進當前的項目里！一些復雜業(yè)務和需求要怎么實現(xiàn)是沒底的，只能見招拆招寫一點是一點。

真實的產品團隊開發(fā)流程就是充滿了混亂和熵增的草臺班子，大家都在摸黑過河，新人會幻想一套童話書里才有得流程并指望大家按這套說明書實踐，而成熟的開發(fā)和設計要根據現(xiàn)場的碎片建立不同的秩序。

最后說一點，這類項目很多都有給設計師名額，就是因為管理層、開發(fā)意識到前面提過的各類設計問題，但最后人招來了發(fā)現(xiàn)大多數設計師沒辦法解決，反而制造出更多的問題，積累更多的矛盾……

想要增長和獲得專業(yè)積累，就停止抱怨開始實踐和嘗試，你們也可以把這套方案發(fā)給你們的前端，再和他們共同討論可行性。

作者：超人的電話亭