如何打造“和而不同”的C端組件庫
編輯導語:“組件”是平臺級產(chǎn)品的組成之一,隨著業(yè)務發(fā)展,對“組件”的要求也不斷提高。那么,如何建立和迭代一個優(yōu)秀的組件庫呢?本文作者表達了自己的思考,一起來看看吧。
“組件”是平臺級產(chǎn)品非常重要的組成部分,設計組件不僅可以節(jié)約設計和開發(fā)成本,更是設計理念的約束性體現(xiàn)。但是,隨著平臺級產(chǎn)品業(yè)務場景的復雜度不斷增加,過往沉淀的設計組件的交互模式和視覺形式,卻跟不上業(yè)務發(fā)展的訴求。
因此,我們思考:如何建立和迭代一個優(yōu)秀的組件庫——不僅能保持良好的普適性,解決全平臺產(chǎn)品的體驗一致性的問題;并且能夠保持各個業(yè)務線的特色和定制化需求,即所謂平臺級組件的“和而不同”。
一、升級組件庫的背景和目標
隨著近兩年業(yè)務的發(fā)展,早期沉淀的組件漸漸無法滿足業(yè)務訴求,一部分組件的使用率和覆蓋率很低。
因此我們決定對貝殼平臺組件進行一次全新的升級。我們的目標不僅是針對“基礎組件”進行優(yōu)化,保持其良好的通用性,達到“和”的目的;更希望能夠承載業(yè)務線(二手房、新房和租房)更多體驗場景的需要,做到服務于業(yè)務的“不同”。
為了更好的實現(xiàn)升級目標,我們思考了以下幾個問題:
1. 設計組件庫的使用人員有哪些不同的角色?他們的訴求是否有區(qū)別?
在我們眼里,設計組件是對設計工作的一種管理,而設計工作從產(chǎn)出到落地的完整鏈條上,主要有三種角色的人群:
貝殼平臺設計師和各個業(yè)務線設計師:平臺設計師窮舉組件使用場景的同時,提煉業(yè)務訴求,幫助業(yè)務線設計師通過組件更省時省力的高效完成設計工作。
開發(fā)團隊:通過設計師的輸出,明確組件開發(fā)的具體框架和自由度(例如按鈕顏色是否支持不同業(yè)務自定義等)
產(chǎn)品團隊:通過設計組件文檔明確設計的標準,在各角色有共同標準的認知下,需求中可使用組件搭建的部分無需重復提需求,節(jié)約各方成本。
因此,設計師需要產(chǎn)出的并不是一份簡單的組件庫源文件,而是一份以不同角色合作伙伴的視角,都能看得懂的設計組件表達文檔。
給設計、產(chǎn)品和開發(fā)不同的文件樣式
2. 組件真的是越多越好嗎?
我們給出的結(jié)論是:面面俱到反而無從下手。在做設計組件時,大多數(shù)同學都會有患得患失的心理,認為組件足夠多,就可以應對更多的使用場景,規(guī)范也足夠細致和統(tǒng)一。
但是這是一個比較理想的狀態(tài),過于低微的顆粒度下,設計反而會失衡。這里的失衡是指,創(chuàng)新和規(guī)范之間的平衡被打破,顯然不是我們想要的。并且平臺級組件庫是具備再生和持續(xù)發(fā)展的生長能力的,因此不必一味追求數(shù)量。
3. 采用什么方法可以合理的控制組件的質(zhì)量和數(shù)量,挑選出通用度高的組件呢?
我們優(yōu)先梳理了貝殼平臺流量TOP30的核心關鍵頁面,依據(jù)數(shù)據(jù)圈定范圍,然后進行組件的整理。
如下圖,我們發(fā)現(xiàn)使用率最高的前十名組件,按照降序排列依次為:tabs選擇>Navbar>房源卡片(業(yè)務通用組件)>經(jīng)紀人展位(業(yè)務通用組件)>按鈕>通知與提示>彈層>搜索框>操作菜單>標準懸浮球。
貝殼平臺流量TOP30頁面組件應用情況
這樣,我們就可以按照以上優(yōu)先級,優(yōu)先設計和代碼化使用頻次較高的組件。
我們將貝殼原有組件庫的全部組件打散,重新定義后分成三大類別:
平臺基礎組件:指不具有業(yè)務屬性的元件及基礎組件,例如:按鈕/表單/列表/搜索欄/系統(tǒng)反饋彈層/操作欄/Navbar等。
業(yè)務通用組件:指橫跨多業(yè)務,但在不同的業(yè)務場景中略有變化,有公共元件可提煉,例如:經(jīng)紀人展位/房源卡片。
業(yè)務特性組件:指只屬于某一業(yè)務應用范疇的組件,無公共元件可提煉,但是在單一業(yè)務線復用率較高。
組件的明確分類,可以幫助我們在日后每當有新增組件時,以統(tǒng)一的標準和原則進行歸納和整理。
二、優(yōu)化業(yè)務通用組件
除了優(yōu)化平臺基礎類型的組件外,我們還對其中使用頻率很高的業(yè)務通用組件——房源列表進行了優(yōu)化。
房源列表是在貝殼平臺通常以線性結(jié)構(gòu)呈現(xiàn)的。用戶通過縱向掃讀來獲取房源宏觀信息,橫線瀏覽來了解單個房源條目的細節(jié)信息并進行相關操作。它在二手房、新房、租賃、海外等等業(yè)務線,都會經(jīng)常被使用到。
貝殼平臺原房源列表樣式,由于業(yè)務的發(fā)展,需要展示的信息逐步增多,依次羅列在列表中,導致展示效率變低,無吸引用戶的亮點,最終導致用戶對房源列表的“決策效率降低”。
而想要提升決策效率,并且優(yōu)化后的列表能夠在各個業(yè)務線使用,我們先要了解,在不同業(yè)務場景中,房源卡片都要展示哪些內(nèi)容?這里我們應用到了先前研究得出的結(jié)論——用戶瀏覽房源列表的心智模型。
用戶瀏覽房源的心智模型
在心智模型的指導下,我們進行了“元素窮舉”。
元素窮舉
得到了具體展示哪些元素后,我們開始思考,一個包容性強的列表底層結(jié)構(gòu)應該是什么樣子?經(jīng)過幾次的反復推敲和嘗試,我們得出如圖所示的三層結(jié)構(gòu):容器背板層、可交互操作層、內(nèi)容展示層。
房源列表的三層結(jié)構(gòu)
容器背板層:它是承載列表內(nèi)部所有內(nèi)容的盒子,我們在這一層,定義了容器的形狀,圓角等屬性,使它成為一個統(tǒng)一的底層模版。
可交互操作層:這一層放置的是用戶關于列表可進行的全部操作,例如關注,查看VR圖片等。并且,我們針對具體每一種操作行為,定義了統(tǒng)一的交互方式。
內(nèi)容展示層:這一層涵蓋所有用戶可以查看的具體信息,包含房源標題、樓盤名稱、房源詳細信息和價格的動態(tài)浮動變化信息。
通過三個層次的劃分,我們可以清晰的定義每個層次的具體的職責是什么,這有利于我們后期面對復雜業(yè)務場景和海量信息內(nèi)容時,可以更好的去歸納和組織信息的呈現(xiàn)。
在完成了元素窮舉和結(jié)構(gòu)分層之后,我們繪制了一個基礎框架模版,如下圖:
房源列表基礎框架
然后我們將不同業(yè)務線的具體細節(jié)信息,嵌入模版中,設計成各個針對不同業(yè)務和不同場景使用的房源列表。帶著這樣的設計結(jié)果,我們和業(yè)務線的產(chǎn)品經(jīng)理和設計師同學進行了一次深入的探討,并且確定可推行迭代的節(jié)奏。
三、數(shù)據(jù)與結(jié)果
綜合14天數(shù)據(jù),二手房改版后,CTR 由原來的44.65%提升到51.35%。這對于房源列表來說,是非常難得的。
改版后的數(shù)據(jù)結(jié)果
四、總結(jié)
以上就是本文的全部內(nèi)容,相信大家已經(jīng)掌握了C端組件庫建立的基本方法,這里我們總結(jié)一下組件庫的創(chuàng)建流程:
C端組件庫的創(chuàng)建流程
組件庫是每一位用戶體驗設計師,在日常工作中積累的設計資產(chǎn)。
組件要做到“和而不同”,“和”是指用規(guī)范化的底層容器,將抽離出復用率高的元素包裹起來,形成體驗一致,交互一致的封裝模塊。
“不同”是指,每條業(yè)務線可以根據(jù)自身具體的使用場景,去定義各自在內(nèi)容展示層要展示的元素,保證了一定的自由度和各自生長的能力。
房源列表在貝殼平臺首頁已經(jīng)上線有半年左右的時間了,通過改版,用戶使用房源列表時的決策效率有一定程度的提升,業(yè)務覆蓋也逐步擴大。在研發(fā)老師的協(xié)同下,實現(xiàn)了Native和Flutter組件的封裝,大大縮短了開發(fā)時長,從而提升了產(chǎn)品整體的研發(fā)效率。
希望能給同樣正在建立組件庫的設計師同學們帶來一些啟發(fā),貝殼用戶體驗團隊也會繼續(xù)致力于更多業(yè)務特性組件的深挖,期待你的關注。
參考文獻:阿里巴巴 ——“表里不一”的設計資產(chǎn)
本文由@貝殼KEDC 原創(chuàng)發(fā)布于人人都是產(chǎn)品經(jīng)理,未經(jīng)許可,禁止轉(zhuǎn)載。
題圖來自Pixabay,基于CC0協(xié)議
你好,想咨詢下在第一部分提到了:篩選流量高的關鍵頁面后,發(fā)現(xiàn)了“使用率最高的前十名組件”想知道這個組件的使用率是怎么具體的判定出來的排序的呢?
這個設計理念很好欸!值得借鑒收藏,數(shù)據(jù)有最好的說服力
文章條理清晰,外行人又學到了C端組件庫建立的基本方法!以后要是自己做設計也不會是無頭蒼蠅了