編輯導語：“元件”是平臺級產品的組成之一，隨著業務發展，對“元件”的要求也不斷提高。那麼，如何建立和迭代一個優秀的元件庫呢？本文作者表達了自己的思考，一起來看看吧。

“元件”是平臺級產品非常重要的組成部分，設計元件不僅可以節約設計和開發成本，更是設計理念的約束性體現。但是，隨著平臺級產品業務場景的複雜度不斷增加，過往沉澱的設計元件的互動模式和視覺形式，卻跟不上業務發展的訴求。

因此，我們思考：如何建立和迭代一個優秀的元件庫——不僅能保持良好的普適性，解決全平臺產品的體驗一致性的問題；並且能夠保持各個業務線的特色和定製化需求，即所謂平臺級元件的“和而不同”。

一、升級元件庫的背景和目標

隨著近兩年業務的發展，早期沉澱的元件漸漸無法滿足業務訴求，一部分元件的使用率和覆蓋率很低。

因此我們決定對貝殼平臺元件進行一次全新的升級。我們的目標不僅是針對“基礎元件”進行最佳化，

保持其良好的通用性，達到“和”的目的

；更希望能夠承載業務線（二手房、新房和租房）更多體驗場景的需要，做到

服務於業務的“不同”。

為了更好的實現升級目標，我們思考了以下幾個問題：

1. 設計元件庫的使用人員有哪些不同的角色？他們的訴求是否有區別？

在我們眼裡，設計元件是對設計工作的一種管理，而設計工作從產出到落地的完整鏈條上，主要有三種角色的人群：

貝殼平臺設計師和各個業務線設計師：

平臺設計師窮舉元件使用場景的同時，提煉業務訴求，幫助業務線設計師透過元件更省時省力的高效完成設計工作。

開發團隊：

透過設計師的輸出，明確元件開發的具體框架和自由度（例如按鈕顏色是否支援不同業務自定義等）

產品團隊：

透過設計元件文件明確設計的標準，在各角色有共同標準的認知下，需求中可使用元件搭建的部分無需重複提需求，節約各方成本。

因此，設計師需要產出的並不是一份簡單的元件庫原始檔，而是一份以不同角色合作伙伴的視角，都能看得懂的設計元件表達文件。

給設計、產品和開發不同的檔案樣式

2. 元件真的是越多越好嗎？

我們給出的結論是：面面俱到反而無從下手。在做設計元件時，大多數同學都會有患得患失的心理，認為元件足夠多，就可以應對更多的使用場景，規範也足夠細緻和統一。

但是這是一個比較理想的狀態，過於低微的顆粒度下，設計反而會失衡。這裡的失衡是指，創新和規範之間的平衡被打破，顯然不是我們想要的。並且平臺級元件庫是具備再生和持續發展的生長能力的，因此不必一味追求數量。

3。 採用什麼方法可以合理的控制組件的質量和數量，挑選出通用度高的元件呢？

我們優先梳理了貝殼平臺流量TOP30的核心關鍵頁面，依據資料圈定範圍，然後進行元件的整理。

如下圖，我們發現使用率最高的前十名元件，按照降序排列依次為：tabs選擇>Navbar>房源卡片（業務通用元件）>經紀人展位（業務通用元件）>按鈕>通知與提示>彈層>搜尋框>操作選單>標準懸浮球。

貝殼平臺流量TOP30頁面元件應用情況

這樣，我們就可以按照以上優先順序，優先設計和程式碼化使用頻次較高的元件。

我們將貝殼原有元件庫的全部元件打散，重新定義後分成三大類別：

平臺基礎元件：

指不具有業務屬性的元件及基礎元件，例如：按鈕/表單/列表/搜尋欄/系統反饋彈層/操作欄/Navbar等。

業務通用元件：

指橫跨多業務，但在不同的業務場景中略有變化，有公共元件可提煉，例如：經紀人展位/房源卡片。

業務特性元件：

指只屬於某一業務應用範疇的元件，無公共元件可提煉，但是在單一業務線複用率較高。

元件的明確分類，可以幫助我們在日後每當有新增元件時，以統一的標準和原則進行歸納和整理。

二、最佳化業務通用元件

除了最佳化平臺基礎型別的元件外，我們還對其中使用頻率很高的業務通用元件——房源列表進行了最佳化。

房源列表是在貝殼平臺通常

以線性結構呈現的

。使用者透過

縱向掃讀

來獲取房源宏觀資訊，橫線瀏覽來了解單個房源條目的細節資訊並進行相關操作。它在二手房、新房、租賃、海外等等業務線，都會經常被使用到。

貝殼平臺原房源列表樣式，由於業務的發展，需要展示的資訊逐步增多，依次羅列在列表中，導致展示效率變低，無吸引使用者的亮點，最終導致使用者對房源列表的“決策效率降低”。

而想要提升決策效率，並且最佳化後的列表能夠在各個業務線使用，我們先要了解，在不同業務場景中，房源卡片都要展示哪些內容？這裡我們應用到了先前研究得出的結論——使用者瀏覽房源列表的心智模型。

使用者瀏覽房源的心智模型

在心智模型的指導下，我們進行了“元素窮舉”。

元素窮舉

得到了具體展示哪些元素後，我們開始思考，一個包容性強的列表底層結構應該是什麼樣子？經過幾次的反覆推敲和嘗試，我們得出如圖所示的三層結構：容器背板層、可互動操作層、內容展示層。

房源列表的三層結構

容器背板層：

它是承載列表內部所有內容的盒子，我們在這一層，定義了容器的形狀，圓角等屬性，使它成為一個統一的底層模版。

可互動操作層：

這一層放置的是使用者關於列表可進行的全部操作，例如關注，檢視VR圖片等。並且，我們針對具體每一種操作行為，定義了統一的互動方式。

內容展示層：

這一層涵蓋所有使用者可以檢視的具體資訊，包含房源標題、樓盤名稱、房源詳細資訊和價格的動態浮動變化資訊。

透過三個層次的劃分，我們可以清晰的定義每個層次的具體的職責是什麼，這有利於我們後期面對複雜業務場景和海量資訊內容時，可以更好的去歸納和組織資訊的呈現。

在完成了元素窮舉和結構分層之後，我們繪製了一個基礎框架模版，如下圖：

房源列表基礎框架

然後我們將不同業務線的具體細節資訊，嵌入模版中，設計成各個針對不同業務和不同場景使用的房源列表。帶著這樣的設計結果，我們和業務線的產品經理和設計師同學進行了一次深入的探討，並且確定可推行迭代的節奏。

三、資料與結果

綜合14天資料，二手房改版後，CTR 由原來的44。65%提升到51。35%。這對於房源列表來說，是非常難得的。

改版後的資料結果

四、總結

以上就是本文的全部內容，相信大家已經掌握了C端元件庫建立的基本方法，這裡我們總結一下元件庫的建立流程：

C端元件庫的建立流程

元件庫是每一位使用者體驗設計師，在日常工作中積累的設計資產。

元件要做到“和而不同”

，“和”是指用規範化的底層容器，將抽離出複用率高的元素包裹起來，形成體驗一致，互動一致的封裝模組。

“不同”是指，每條業務線可以根據自身具體的使用場景，去定義各自在內容展示層要展示的元素，保證了一定的自由度和各自生長的能力。

房源列表在貝殼平臺首頁已經上線有半年左右的時間了，透過改版，使用者使用房源列表時的決策效率有一定程度的提升，業務覆蓋也逐步擴大。在研發老師的協同下，實現了Native和Flutter元件的封裝，大大縮短了開發時長，從而提升了產品整體的研發效率。

希望能給同樣正在建立元件庫的設計師同學們帶來一些啟發，貝殼使用者體驗團隊也會繼續致力於更多業務特性元件的深挖，期待你的關注。

參考文獻：阿里巴巴 ——“表裡不一”的設計資產

本文由@貝殼KEDC 原創釋出於人人都是產品經理，未經許可，禁止轉載。

題圖來自Pixabay，基於CC0協議