文章正文字數3137，閱讀預計需要10分鐘，本篇文章大綱如下：
1.前言
2.為什麼要做組件化平臺
3.組件化平臺的設計原則
4.組件化平臺的設計流程
5.組件化平臺的難點
6.如何制定自身業務的組件
7.組件化平臺的迭代和維護
1.前言
後臺作為支持前臺業務的管理系統，它起到管理業務數據和管理前臺內容的作用。
當公司業務規模的擴張時，後臺的設計和開發需求也隨之擴大。
大部分公司的後臺的用戶人數少，可能就那麼幾個管理員使用，亦或特定的幾百人使用，所以絕大部分B端後臺設計不像C端產品擁有廣泛的使用人群（大規模商業化B端產品除外），公司也就不會投入大量的設計資源和開發資源在後臺上面。
下圖為ant design後臺範例。
B端後臺設計1.0時代，設計師將需求原型製作成視覺稿，在這一過程中，不太考慮組件樣式的複用，組件樣式一直在重複造輪子，組件各種樣式和狀態需要浪費設計師大量的時間和精力，這種工作流程低效，且拉低整個產品的上線週期。
B端後臺設計2.0時代，B端後臺設計不像C端那樣具有品牌調性，後臺組件交互形式和視覺樣式具有高度的通用性，所以組件可以重複使用。
設計師只要將高複用性的組件做成設計規範，設計師接到需求，即可直接拼組件搭建界面，不需要再設計新的組件樣式，這種工作流程極大的提升了設計人效，以前需要一週完成的設計，現在只需要2天就可以完成。
B端後臺設計3.0時代。開發將設計師的製作的組件以代碼的形式進行封裝，打造成一個組件化平臺。
PM用設計師製作的元件庫直接搭建界面，原型完成之後，交互設計師review原型之後，對可優化的點進行優化，就可以交給開發，開發根據原型，直接進行代碼的拼接修改調整即可完成後臺網站的搭建。
一個後臺網站用常規的設計流程，在設計1.0時代上線週期如果需要40天，那麼在設計2.0時代只需要30天，在設計3.0時代（組件化平臺）的情況下使用只需要10天。
組件化平臺最大的價值是進行提效。將人力釋放。開發有更多的時間進行代碼的優化，提高代碼質量，設計師有更多的時間優化設計細節、優化流程和熟悉業務。開發和設計不再被各種業務所追趕，擁有時間提升業務能力和專業能力。
2.為什麼要做組件化平臺
組件化平臺具有3大特點分別為：定製化、高效性和迭代性，這3大特點決定了需要做組件化平臺。
定製化
最大的組件化平臺是ant design，其次是element ，既然有了ant design和element。為什麼我們還要做自己的組件化平臺呢？
原因在於我們自己的組件化平臺可根據業務需求，對平臺做定製化組件，這樣可以更好的服務公司業務。
有些複雜或者特殊的業務，需要的組件樣式或功能在ant design、element 並沒有，基於這種情況，所以需要做自己的組件化平臺。
高效性
高效複用於團隊和公司業務後臺，節約設計和開發資源。避免設計師在設計過程中重複做各種組件樣式和狀態，浪費大量時間。避免開發基於新的設計樣式寫代碼，提高人效。
將人力用在更有價值的地方，而不是這種重複的搬磚工作中。
迭代性
組件化平臺貼近公司業務，不斷擴展組件類型，使得組件化平臺服務於公司業務，後期基於業務需求不斷的迭代組件樣式。使得組件化平臺成為一個真正有意義的提效平臺。
3.組件化平臺的設計原則
這裡的設計原則指的是在設計整個設計平臺需要明確的一系列原則，而這些原則都是在後續設計組件決策過程中的依據。
有了明確清晰的原則，對於構建整個組件化平臺具有極大的意義。
兼容性
為什麼ant design、element 兩個網站很成功，很多公司後臺在使用，其中一個核心原因就是他們的代碼兼容性好、bug少。所以在構建組件化平臺時候，需要開發花大氣力優化組件代碼兼容性。避免代碼兼容性差導致業務組使用率低。
通用型
後臺網站，因為信息量大，用戶使用時間長且頻繁，所以對於視覺設計來說，需要審美耐看，多看不膩，避免花哨的設計元素破壞用戶對於信息的獲取。
對於交互來說，後臺網站設計已經基本固化，目前市面看到的組件設計幾乎就是組件的最優設計形態。
所以在設計組件交互時候，可以參考目前主流產品（ant design、element）組件交互設計。
擴展性
在設計組件之前，需要熟悉後臺常用的使用場景，知道通用的組件類型有哪些。
前期要儘量減少組件類型的冗餘，方便組件功能和設計的後續擴展。前提也是要保證上線的組件可以覆蓋絕大部分場景，避免組件化平臺的不可用。
在設計過程中一種類型的組件各種狀態做完整，避免後續改動。一種組件後續可增加其他類型，方便業務使用。這樣可以很好的保證組件化平臺健康而良性的發展。
4.組件化平臺的設計流程
組件化平臺在設計過程中，流程有原型設計、原型評審、視覺設計、視覺稿確認和最終的走查驗收。
原型設計
前期需要交互設計完成對組件類型進行分類，常見的分類是基於功能分類。即相同功能的組件分為一組。
將所有組件分類完成，可生成了一個組件化平臺內容目錄。接下來就是對每個組件進行定義和功能類型設計。
在設計功能類型時，需要參考ant design、element等知名網站，以及結合自己的B端經驗和現有業務具體情況，確定哪些組件類型可以先設計，哪些組件類型放在後面設計。和開發私下確認每個組件類型是否有遺漏或多餘的組件類型。
原型評審
拉上所有開發一起評審，評審基於一個分類和開發討論確定所有對細節。確保整體交互細節統一，交互效果和規則無問題。下圖為select組件部分內容。
視覺設計
視覺設計師前期需要花大量的時間用於探索視覺風格和對應的視覺規則，例如顏色規範、字體的顏色、字號、行高和柵格規則等。保證視覺風格使用合理。在視覺元素確定之後，再設計組件。
視覺稿確認
視覺設計基於交互稿，完成視覺設計，完成後，和交互設計師一起確認，當視覺稿沒有問題後，發送給前端開發。
走查驗收
交互和視覺設計師對線上開發的組件效果進行走查，形成走查報告，併發給前端開發，並和前端開發開會討論，形成最終的走查報告，將前端開發修改後的問題，從走查報告中刪掉，這樣可以保證線上問題逐步修改完成。
5.組件化平臺的難點
在組件化平臺的過程中存在3個難點：1.設計師要明確前端實現邏輯；2.組件類型設計取捨；3.視覺全局規劃。
前端實現邏輯
明確前端demo展示和代碼配置的區別，組件demo展示的交互樣式可以在代碼中展示，也可以在代碼中移除。如下圖所示，含有可刪除的圖標，其他前端使用時可以在代碼中刪除。
明確前端demo展示和前端可更改的範圍。例如block組件，其他前端複用代碼時，可以自定義設置其寬度以適應各種不同的頁面內容設計。
組件類型設計
選擇常用組件類型，儘量不上功能兼容性差的組件。前期平臺儘量不上低頻類型的組件。
例如對於選擇器的多選樣式，我選擇了選項前加複選框，而不是用目前ant design的選項被選中後勾號放在後面。
這種選擇有兩個理由：1、用戶未選擇，很難判斷這個選擇器是單選還是多選。2、選項前加複選框，和之後做樹展示保持一致，樣式上可以複用。
下圖為上線平臺樣式：
下圖為ant design樣式：
視覺全局規劃
組件種類眾多，每個組件對應的類型也眾多，組件化平臺需要考慮所有組件的兼容性，所以在定義顏色、顏色四態和元素間距時候，需要全局平衡，儘量減少規則太多，導致組件化平臺設計規則紊亂。
以顏色為例，基於360品牌色調，確定了主色基調，通過對多種因素（例如各種不同素質的顯示屏）的綜合考量並進行試驗，結合顏色具有的三個特性，並從視覺的角度定義輔助色。
關於按鈕：按鈕狀態遵循了“狀態可感知”原則，快速的讓用戶瞭解自己處於何種狀態，基於這種情況，將按鈕5個狀態清晰的表現出來。
6.如何制定自身業務的組件
設計團隊如果已經做了很多後臺業務，那麼只需要將所有對後臺業務對組件進行梳理、分類、將存在重疊組件類型進行刪除。形成屬於自己業務的組件庫。
7.組件化平臺的迭代與維護
配合業務進行組件化平臺的迭代和維護，使組件化平臺在迭代中不斷髮展成長，在這個迭代和維護過程中，設計師是產品經理的角色，讓設計師和組件化平臺一起成長髮展。
end
閱讀更多 PMTalk產品經理社區 的文章
