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

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

一、組件庫的應(yīng)用認(rèn)識

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

面向組件庫做設(shè)計！

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

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

二、如何面向組件庫做設(shè)計

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

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

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

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

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

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

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

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

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

2. 熟悉框架內(nèi)容

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

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

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

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

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

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

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

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

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

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

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

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

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

1. 柵格/響應(yīng)
2. 框架/版式
3. 色彩
4. 字體
5. 圖標(biāo)
6. 樣式
7. 控件/組件

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

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

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

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

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

樣式指應(yīng)用的圓角、投影、透明度等設(shè)計屬性，這些同樣根據(jù)官方的標(biāo)準(zhǔn)篩選制定就可以。

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

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

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

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

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

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

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

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

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

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

4. 確定交付模式

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

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

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

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

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

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

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

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

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

結(jié)尾

這次分享的內(nèi)容比較超綱，需要有一定經(jīng)驗才能理解，不要認(rèn)為只是設(shè)計層面需要搞那么麻煩。

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

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

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

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

今天的分享就到這邊結(jié)束。

我們下篇再賤~

歡迎關(guān)注作者的微信公眾號：「超人的電話亭」