“組件”是平臺級產(chǎn)品非常重要的組成部分，設(shè)計(jì)組件不僅可以節(jié)約設(shè)計(jì)和開發(fā)成本，更是設(shè)計(jì)理念的約束性體現(xiàn)。但是，隨著平臺級產(chǎn)品業(yè)務(wù)場景的復(fù)雜度不斷增加，過往沉淀的設(shè)計(jì)組件的交互模式和視覺形式，卻跟不上業(yè)務(wù)發(fā)展的訴求。因此，我們思考：如何建立和迭代一個(gè)優(yōu)秀的組件庫——不僅能保持良好的普適性，解決全平臺產(chǎn)品的體驗(yàn)一致性的問題;并且能夠保持各個(gè)業(yè)務(wù)線的特色和定制化需求，即所謂平臺級組件的“和而不同”。

升級組件庫的背景和目標(biāo)

隨著近兩年業(yè)務(wù)的發(fā)展，早期沉淀的組件漸漸無法滿足業(yè)務(wù)訴求，一部分組件的使用率和覆蓋率很低。

因此我們決定對貝殼平臺組件進(jìn)行一次全新的升級。我們的目標(biāo)不僅是針對“基礎(chǔ)組件”進(jìn)行優(yōu)化，保持其良好的通用性，達(dá)到“和”的目的;更希望能夠承載業(yè)務(wù)線(二手房、新房和租房)更多體驗(yàn)場景的需要，做到服務(wù)于業(yè)務(wù)的“不同”。

為了更好的實(shí)現(xiàn)升級目標(biāo)，我們思考了以下幾個(gè)問題：

1. 設(shè)計(jì)組件庫的使用人員有哪些不同的角色?他們的訴求是否有區(qū)別?

在我們眼里，設(shè)計(jì)組件是對設(shè)計(jì)工作的一種管理，而設(shè)計(jì)工作從產(chǎn)出到落地的完整鏈條上，主要有三種角色的人群：

貝殼平臺設(shè)計(jì)師和各個(gè)業(yè)務(wù)線設(shè)計(jì)師：平臺設(shè)計(jì)師窮舉組件使用場景的同時(shí)，提煉業(yè)務(wù)訴求，幫助業(yè)務(wù)線設(shè)計(jì)師通過組件更省時(shí)省力的高效完成設(shè)計(jì)工作。

開發(fā)團(tuán)隊(duì)：通過設(shè)計(jì)師的輸出，明確組件開發(fā)的具體框架和自由度(例如按鈕顏色是否支持不同業(yè)務(wù)自定義等)

產(chǎn)品團(tuán)隊(duì)：通過設(shè)計(jì)組件文檔明確設(shè)計(jì)的標(biāo)準(zhǔn)，在各角色有共同標(biāo)準(zhǔn)的認(rèn)知下，需求中可使用組件搭建的部分無需重復(fù)提需求，節(jié)約各方成本。

因此，設(shè)計(jì)師需要產(chǎn)出的并不是一份簡單的組件庫源文件，而是一份以不同角色合作伙伴的視角，都能看得懂的設(shè)計(jì)組件表達(dá)文檔。 

2. 組件真的是越多越好嗎?

我們給出的結(jié)論是：面面俱到反而無從下手。在做設(shè)計(jì)組件時(shí)，大多數(shù)同學(xué)都會有患得患失的心理，認(rèn)為組件足夠多，就可以應(yīng)對更多的使用場景，規(guī)范也足夠細(xì)致和統(tǒng)一。

但是這是一個(gè)比較理想的狀態(tài)，過于低微的顆粒度下，設(shè)計(jì)反而會失衡。這里的失衡是指，創(chuàng)新和規(guī)范之間的平衡被打破，顯然不是我們想要的。并且平臺級組件庫是具備再生和持續(xù)發(fā)展的生長能力的，因此不必一味追求數(shù)量。

3. 采用什么方法可以合理的控制組件的質(zhì)量和數(shù)量，挑選出通用度高的組件呢?

我們優(yōu)先梳理了貝殼平臺流量 TOP30 的核心關(guān)鍵頁面，依據(jù)數(shù)據(jù)圈定范圍，然后進(jìn)行組件的整理。如下圖，我們發(fā)現(xiàn)使用率最高的前十名組件，按照降序排列依次為：tabs 選擇>Navbar>房源卡片(業(yè)務(wù)通用組件)>經(jīng)紀(jì)人展位(業(yè)務(wù)通用組件)>按鈕>通知與提示>彈層>搜索框>操作菜單>標(biāo)準(zhǔn)懸浮球。 

這樣，我們就可以按照以上優(yōu)先級，優(yōu)先設(shè)計(jì)和代碼化使用頻次較高的組件。

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

• 平臺基礎(chǔ)組件：指不具有業(yè)務(wù)屬性的元件及基礎(chǔ)組件，例如：按鈕/表單/列表/搜索欄/系統(tǒng)反饋彈層/操作欄/Navbar 等。
• 業(yè)務(wù)通用組件：指橫跨多業(yè)務(wù)，但在不同的業(yè)務(wù)場景中略有變化，有公共元件可提煉，例如：經(jīng)紀(jì)人展位/房源卡片。
• 業(yè)務(wù)特性組件：指只屬于某一業(yè)務(wù)應(yīng)用范疇的組件，無公共元件可提煉，但是在單一業(yè)務(wù)線復(fù)用率較高。

組件的明確分類，可以幫助我們在日后每當(dāng)有新增組件時(shí)，以統(tǒng)一的標(biāo)準(zhǔn)和原則進(jìn)行歸納和整理。

優(yōu)化業(yè)務(wù)通用組件

除了優(yōu)化平臺基礎(chǔ)類型的組件外，我們還對其中使用頻率很高的業(yè)務(wù)通用組件——房源列表進(jìn)行了優(yōu)化。

房源列表是在貝殼平臺通常以線性結(jié)構(gòu)呈現(xiàn)的。用戶通過縱向掃讀來獲取房源宏觀信息，橫線瀏覽來了解單個(gè)房源條目的細(xì)節(jié)信息并進(jìn)行相關(guān)操作。它在二手房、新房、租賃、海外等等業(yè)務(wù)線，都會經(jīng)常被使用到。貝殼平臺原房源列表樣式，由于業(yè)務(wù)的發(fā)展，需要展示的信息逐步增多，依次羅列在列表中，導(dǎo)致展示效率變低，無吸引用戶的亮點(diǎn)，最終導(dǎo)致用戶對房源列表的“決策效率降低”。

而想要提升決策效率，并且優(yōu)化后的列表能夠在各個(gè)業(yè)務(wù)線使用，我們先要了解，在不同業(yè)務(wù)場景中，房源卡片都要展示哪些內(nèi)容?這里我們應(yīng)用到了先前研究得出的結(jié)論——用戶瀏覽房源列表的心智模型。 

△ 圖 3 用戶瀏覽房源的心智模型 

在心智模型的指導(dǎo)下，我們進(jìn)行了“元素窮舉”。 

得到了具體展示哪些元素后，我們開始思考，一個(gè)包容性強(qiáng)的列表底層結(jié)構(gòu)應(yīng)該是什么樣子?經(jīng)過幾次的反復(fù)推敲和嘗試，我們得出如圖所示的三層結(jié)構(gòu)：容器背板層、可交互操作層、內(nèi)容展示層。

△ 圖 5 房源列表的三層結(jié)構(gòu)

• 容器背板層：它是承載列表內(nèi)部所有內(nèi)容的盒子，我們在這一層，定義了容器的形狀，圓角等屬性，使它成為一個(gè)統(tǒng)一的底層模版。
• 可交互操作層：這一層放置的是用戶關(guān)于列表可進(jìn)行的全部操作，例如關(guān)注，查看 VR 圖片等。并且，我們針對具體每一種操作行為，定義了統(tǒng)一的交互方式。
• 內(nèi)容展示層：這一層涵蓋所有用戶可以查看的具體信息，包含房源標(biāo)題、樓盤名稱、房源詳細(xì)信息和價(jià)格的動(dòng)態(tài)浮動(dòng)變化信息。

通過三個(gè)層次的劃分，我們可以清晰的定義每個(gè)層次的具體的職責(zé)是什么，這有利于我們后期面對復(fù)雜業(yè)務(wù)場景和海量信息內(nèi)容時(shí)，可以更好的去歸納和組織信息的呈現(xiàn)。

在完成了元素窮舉和結(jié)構(gòu)分層之后，我們繪制了一個(gè)基礎(chǔ)框架模版，如下圖： 

然后我們將不同業(yè)務(wù)線的具體細(xì)節(jié)信息，嵌入模版中，設(shè)計(jì)成各個(gè)針對不同業(yè)務(wù)和不同場景使用的房源列表。帶著這樣的設(shè)計(jì)結(jié)果，我們與業(yè)務(wù)線的產(chǎn)品經(jīng)理和設(shè)計(jì)師同學(xué)進(jìn)行了一次深入的探討，并且確定可推行迭代的節(jié)奏。

數(shù)據(jù)與結(jié)果

綜合 14 天數(shù)據(jù)，二手房改版后，CTR 由原來的 44.65%提升到 51.35%。這對于房源列表來說，是非常難得的。 

總結(jié)

以上就是本文的全部內(nèi)容，相信大家已經(jīng)掌握了 C 端組件庫建立的基本方法，這里我們總結(jié)一下組件庫的創(chuàng)建流程： 

組件庫是每一位用戶體驗(yàn)設(shè)計(jì)師，在日常工作中積累的設(shè)計(jì)資產(chǎn)。組件要做到“和而不同”，“和”是指用規(guī)范化的底層容器，將抽離出復(fù)用率高的元素包裹起來，形成體驗(yàn)一致，交互一致的封裝模塊。“不同”是指，每條業(yè)務(wù)線可以根據(jù)自身具體的使用場景，去定義各自在內(nèi)容展示層要展示的元素，保證了一定的自由度和各自生長的能力。

房源列表在貝殼平臺首頁已經(jīng)上線有半年左右的時(shí)間了，通過改版，用戶使用房源列表時(shí)的決策效率有一定程度的提升，業(yè)務(wù)覆蓋也逐步擴(kuò)大。在研發(fā)老師的協(xié)同下，實(shí)現(xiàn)了 Native 和 Flutter 組件的封裝，大大縮短了開發(fā)時(shí)長，從而提升了產(chǎn)品整體的研發(fā)效率。

希望能給同樣正在建立組件庫的設(shè)計(jì)師同學(xué)們帶來一些啟發(fā)，貝殼用戶體驗(yàn)團(tuán)隊(duì)也會繼續(xù)致力于更多業(yè)務(wù)特性組件的深挖，期待你的關(guān)注。