產品工作流最佳化：搭建元件庫做高ROI

“元件庫”這一事物近兩年已在網際網路行業中流行起來，它的主要價值大家都應該清楚：能快速搭建前端頁面、減少設計與開發溝通成本、統一體驗規範等等。為了滿足中小企業的需求，越來越多的開源元件庫誕生，但開源代表著通用，無法滿足業務特色需求，於是不少企業也開始做起了自己的元件庫。

搭建元件庫的成本很高，因此需避免兩種結果：一是做得很全或能力很強大，卻用不上；二是沒滿足自身業務需求，白做了。那如何搭建自身業務元件庫能“投入產出比”更高呢？

元件化專案整體流程圖

一、前期準備

在搭建元件庫之前，首先要做好充分的準備，而這前期準備需要分為兩條線並行走。

一條線是瞭解業務的開發現狀和問題，相互溝通設計側和開發側對於元件庫的核心訴求，同時和開發團隊探索搭建方案。另一條線是設計側全面走查頁面，對介面內容進行梳理與歸納，然後制定設計規範。

1. 瞭解業務現狀

清楚業務開發現狀和問題，瞭解核心訴求，才知道該如何著手，而縱觀愛奇藝移動端的業務狀況：1）在長年的版本迭代中，功能和內容不斷增加，新舊樣式和頁面積累繁多；2）開發人員分工細化，不同地方實現方式也有所差異，沒有較為統一的規範；3）平臺中的細分業務較多，各自獨立維護。

這樣的背景，導致線上存在較多相似內容沒有統一、同樣的內容在不同地方重複實現、改一個內容需多處單獨修改等情況。設計的開發還原整體較為耗時，從而影響使用者體驗的快速迭代最佳化。

2. 介面走查&設計規範制定

要搭建元件，前提也得把元件的設計方案定好，而元件的基礎則是完整的設計規範。

全面走查了400+個頁面內容後，我們對介面內容進行歸納梳理、增刪減改及打磨最佳化，最後制定了愛奇藝移動端的設計規範。關於設計規範該如何定義，那又是一篇長文了，這裡就不展開說明。

在介面內容梳理和規範的制定過程中，我們也能更深入的瞭解各業務和各角色的訴求，並且發現哪些內容複用性更高，從中判斷應該搭建哪些元件。

3. 核心訴求

從平臺方角度對體驗統一及效率提升的核心需求，結合公司內各業務方的常規需求考慮，愛奇藝移動端元件庫需要達到的主要目標為：

• 透過元件進行規範控制，減少隨意的組合方式，減少不必要的細微差異；

• 元件需滿足業務的內容及品牌差異，同時支援規範更新時的統一調整；

• 具備雲端動態統一調整，以及從各維度的進行元件查詢與管理的能力。

二、元件搭建

透過整體的頁面走查和需求討論，除了常規的顏色和控制元件圖示等基礎內容，我們發現複用性高的元件，主要分為實現基礎功能的“基礎元件”（如彈窗、選單、toast等），和展示業務內容的“業務元件”（內部稱之為card）兩大類。由於基礎元件的需求情況相對簡單，業界上的定義也比較一致，而card元件更能體現愛奇藝業務上的特點，因此下面主要針對card元件進行闡述。

1. 選擇合適的顆粒度，定義組合關係和框架型別

提到建立元件庫，大家基本都會想到原子設計理論，即以“原子-分子-組織-模版-頁面”的組織方式去搭建。以這樣的方式去制定設計規範是合適的，規範的制定能更嚴謹和全面，但到具體使用在業務中的元件庫，就得根據實際情況去考慮顆粒度了。

元件的組成元素顆粒度越細，規範也許能更好的落到細節，但組合後的結果能千變萬化，從整體上看反而會有很多不規範的可能性。同時，因為由共同元素組成的元件和元件間會產生耦合關係，在改動元素的時候容易牽一髮而動全身，從而產生不可控性。

因此我們在搭建card元件時，並沒有把card內的所有元素都做成引用關係，主要是以“block-card”的顆粒度來做複用。即我們定義不同的block模組和card結構，card由不同的block組成，業務方透過呼叫card元件來完成頁面設計。

2. 元件可快速呼叫，同時具備擴充套件性和相容性

為了方便檢索和快速呼叫，card元件需有名稱和明確的對應內容，因為一個card自身如果能容納過多的變化，那在具體呼叫時就不清晰。但如果一個card內的可變性太少，那結果會需要搭建特別多的card來滿足需求，且card間的相似度會很高。

在平衡card元件的擴充套件性和明確性後，最終我們除了定義每個card的框架結構，還定義框架內的每個模組可內建幾個常用模組以進行變化。

各類Card框架舉例示意圖

Card支援符合框架的多個block內建

在元件的使用中，我們還會發現有兩類業務需求：一種是直接複用元件，希望改版時能同時生效；另一種是希望能使用元件，但是區域性根據業務品牌需求而調整，且調整部分不受元件改版的影響。

針對前者需求，直接複用元件即可，元件定義了內容的全集，在使用時可支援區域性元素/模組的顯隱。而針對後者，我們設計了一種“元件派生”的關係（可理解為“父子”關係），可讓業務方做區域性調整，調整部分不會因元件後續的樣式改版而被覆蓋，而未調整的部分也能隨原元件的更新而更新。這樣既保證了框架和樣式的統一性，解決了設計改版時“一改全改”的痛點，同時也滿足了業務的品牌差異性需求。

Card元件使用舉例

3. 搭建元件後臺，統一管理

整體的元件庫搭建方式是：平臺設計側定義元件內容 - 前端搭建元件樣式 - 後端搭建元件管理平臺。元件管理平臺負責的是元件的上線和管理，能讓開發和業務方在呼叫元件時更合理規範，且方便後續維護和檢索。

在元件的實際使用流程中，以前業務側想複用已有內容方式，都是直接說和線上某處一樣，然後開發複製貼上線上程式碼。現在是平臺產品和設計側選擇合適的元件，然後讓開發透過元件後臺去進行上線與分發管理，保證複用的內容只能以元件方式被使用。

元件後臺也支援分業務管理，垂線業務可考慮根據自己的需求，在平臺上搭建自己的元件庫，進行獨立維護和管理。

規範和明確了呼叫關係，在元件管理平臺上我們就能夠查詢各元件的使用情況，在後續的設計迭代中也能明確知道修改元件的影響範圍，為設計決策和影響效果提供了保障。

4. 透過sketch外掛打通設計與開發環節

只有將設計工具和開發程式碼打通，才能更好的提升效率和實現效果。因此，我們也讓開發同學自研sketch外掛，讓外掛提供自動化標註、一鍵換算字高、元件命名直接檢視、darkmode顏色key值換算、設計稿轉程式碼等能力，而這些能力對非元件化需求也有提效作用。

三、提升元件覆蓋度和複用度以提效

在不影響需求滿足和設計效果的前提下，只有在方案設計中儘可能使用元件，才可能真正透過元件庫來提效。而除了在新的需求中使用元件，還需要將已有頁面內容都儘量替換成元件，才能在改版中能夠“一改全改”以提效。

線上內容哪些可替換成元件，首先是設計師們在前期的大量走查常用介面過程中，梳理可替換內容。後續則透過開發團隊針對二三級頁面，對樣式程式碼和元件進行相似度的掃描，對掃描結果中相似度高的進行人工判斷能否使用元件，或是有較高複用性的樣式則需搭建新元件。

四、元件化成果

經過一個季度的元件搭建與替換，card元件在我們自身業務的線上覆蓋率達43%，在使用元件的需求中“設計-開發-測試”整體提效約40%，端上整體的體驗統一效果提升約25%。

對各種頁面走查和設計規範的打磨，和開發同學每週一次從下午到晚上的方案“暢談”，像產品經理一樣做排期將元件落地，以平臺方的姿態和各業務方的溝通交涉……在整個元件化專案中，設計側作為owner，對方案的細緻探討和打磨、與業務方百折不撓的溝通、以及和開發側良好深入的配合，最終才能實現這樣的成果。

Last but not least，元件化雖是提效和統一體驗的好方式，但在設計過程中我們也不能過度強化元件的使用，喪失了設計創新的可能性，而是透過對產品價值的深入認知、對設計方案的全域性審視來進行決策，以實現兩者間的平衡和價值最大化。