如何用UI設(shè)計將組件化設(shè)計升級的一些思考

什么情況下做組件化設(shè)計

組件化設(shè)計在前期有較大的整理、設(shè)計與開發(fā)成本，并不是所有項目都適合，在驅(qū)動組件化設(shè)計及升級之前，我們需要對項目現(xiàn)狀有比較清晰的評估和認(rèn)知。

1. 是否存在多人協(xié)同的情況？

如果只是 1 個設(shè)計 + 1 個前端之類的配置，很多細(xì)節(jié)體驗問題靠面對面口頭溝通也能解決，但如果項目中有多個設(shè)計師或多個前端，沒有統(tǒng)一的組件規(guī)范的話，就容易造成樣式混亂、重復(fù)設(shè)計開發(fā)一類的問題。這時推動組件化設(shè)計是一件有必要的事情。

2. 產(chǎn)品是否進(jìn)入相對成熟的階段？

組件化設(shè)計會考慮很多對于細(xì)節(jié)的打磨和規(guī)范，對于從 0 到 1 的產(chǎn)品，有時候最基礎(chǔ)的業(yè)務(wù)/用戶價值都還很模糊，快速上線驗證迭代更加重要，一個 60 分的 MVP 可能就夠用了；而渡過這一階段、產(chǎn)品形態(tài)又未完全固化的時候，就需要更多對于體驗細(xì)節(jié)的關(guān)注和打磨，組件化設(shè)計時機(jī)相對成熟。

3. 線上組件體驗是否影響核心業(yè)務(wù)指標(biāo)？

發(fā)起組件化設(shè)計升級之前，線上通常已經(jīng)積累了一部分「能用」的組件，但是組件基礎(chǔ)體驗不佳，造成用戶誤判概率大、操作效率低、滿意度低等情況，有些會影響到核心業(yè)務(wù)指標(biāo)，所以需要升級優(yōu)化。

 

組件化設(shè)計有什么好處

1. 思考角度更全面

如果只是跟著某一個具體業(yè)務(wù)場景出方案，我們可能只會考慮組件在當(dāng)前場景能否滿足訴求，而沒有跳出來看全局，后續(xù)組件在其他場景里可能有被「濫用」的風(fēng)險。而在組件化設(shè)計過程中，我們需要更完整地走查和整理所有已有 & 潛在業(yè)務(wù)場景，全鏈路考慮解決方案。

以我們最近設(shè)計的一個「圖片」組件為例，這個組件在好幾個場景都會被用到。最開始接到的是其中一個場景下的業(yè)務(wù)需求，用戶可以瀏覽自己之前上傳的圖片、定位具體問題在哪，當(dāng)時處理得比較簡單，就是常見的固定尺寸居中裁剪展示縮略圖。結(jié)果后面業(yè)務(wù)方把這個組件復(fù)用到其他地方，就出現(xiàn)了問題：被復(fù)用的是一個圖片審核的場景，用戶需要瀏覽業(yè)務(wù)給出的若干圖片，判斷是否符合要求，而這些圖片可能非常奇葩，可能是一張很長的圖片然后頂部有文字，裁剪后文字默認(rèn)是看不到的，對于「圖中是否有文字」一類問題用戶就可能誤判。在前一場景里我們注重的是瀏覽效率、幫助用戶快速定位，圖片本身由用戶上傳也不會存在「裁剪誤判」一類問題；而在后一場景里我們注重的是準(zhǔn)確率、減少用戶誤判，不能簡單復(fù)用前一場景的方案。

具體到方案設(shè)計階段，需要平衡的因素也很多，準(zhǔn)確率、效率、可用性、美觀度、一致性等，要考慮很多極端場景下的展示效果是否會有問題，制定相應(yīng)的處理規(guī)則等，這個過程比較累，但有助于我們進(jìn)行更完整全面的思考，產(chǎn)出更能靈活適應(yīng)不同場景的方案。

2. 細(xì)節(jié)打磨更充分

在做業(yè)務(wù)需求的時候，因為時間、優(yōu)先級等原因，我們可能更注重整體的流程體驗的通暢，而不會花太多精力去打磨其中某一小塊的創(chuàng)新動效等細(xì)節(jié)。即使做了，在開發(fā)評估優(yōu)先級時也會往后排甚至直接砍掉。

但如果單獨拎成一個組件去優(yōu)化，組件化的設(shè)計交付節(jié)奏一般由設(shè)計師自行把控，而不是和業(yè)務(wù)需求一樣受制于業(yè)務(wù)方，我們也會有更多的時間來進(jìn)行充分的打磨，加入更多人性化思考、微交互創(chuàng)新、動效細(xì)節(jié)等，捆綁交付給開發(fā)。

3. 想法落地更容易

好的想法無法落地是困擾過很多設(shè)計師的問題，具體原因我之前的文章也有思考過，除去業(yè)務(wù)價值之外，開發(fā)成本也是影響我們將想法變?yōu)楝F(xiàn)實的重要因素。而我近期解決這個問題的一個嘗試，就是將之前的想法「化整為零」，把原先完整的設(shè)計優(yōu)化方案肢解成好幾個組件的組合，然后按優(yōu)先級去推動每個組件的優(yōu)化，直到將所有組件都優(yōu)化完畢。這樣的一個好處是在開發(fā)資源節(jié)奏緊張的時候，可以更好地見縫插針推動迭代，適用于在已有完整線上方案的基礎(chǔ)上進(jìn)行體驗優(yōu)化。

 

組件化設(shè)計流程

具體的組件化設(shè)計升級流程我總結(jié)成了下圖：

1. 類目梳理

這一階段主要是整理和歸類線上組件，和利益相關(guān)方討論補充（未來會上哪些新業(yè)務(wù)，現(xiàn)有的組件能否滿足訴求），配合業(yè)務(wù)發(fā)布節(jié)奏，評估具體組件優(yōu)先級和迭代計劃。

組件整理完畢后，具體優(yōu)先級評估和業(yè)務(wù)方一起進(jìn)行，我們主要從以下幾個維度進(jìn)行考慮：核心業(yè)務(wù)/體驗指標(biāo)影響面、近期是否有用到組件的新業(yè)務(wù)發(fā)布、前端與后端開發(fā)成本。明確優(yōu)先級后錄入到在線協(xié)作工具，將每一個組件建成一個獨立任務(wù)，像日常需求那樣，方面隨時更新、抄送和管理追蹤。

2. 場景走查

把自己變成產(chǎn)品的深度用戶，完整體驗走查線上 APP，繪制用戶行為鏈路，并和業(yè)務(wù)方溝通了解后續(xù)計劃，將組件的所有的當(dāng)前/潛在應(yīng)用場景總結(jié)出來，盡可能不遺漏場景。

與此同時，也要關(guān)注每類場景的具體特征，真實數(shù)據(jù)下的展現(xiàn)情況，了解最復(fù)雜、最奇葩的數(shù)據(jù)是怎樣的，在方案設(shè)計階段盡可能考慮周全。

3. 問題分析

分析線上已有組件的體驗現(xiàn)狀如何，每類場景下需要解決的核心問題是什么，無法兼顧時如何取舍。比如前面提到的「圖片」組件，在 A 場景下效率更重要，B 場景下防誤判更重要，要解決的核心問題不同，產(chǎn)生的方案也會有差異，這些都是在設(shè)計具體方案之前需要明確的。

有時我們會發(fā)現(xiàn)想解決的問題無法都兼顧到，產(chǎn)生不了最理想的方案，這時就要對問題優(yōu)先級有個明確判斷，比如優(yōu)先考慮效率提升，美觀可以次要一點，這樣方案設(shè)計階段可以在幾種解決方案中作出最合適的決策。

4. 方案設(shè)計

完整考慮組件對所有場景的適應(yīng)，是否能解決每類場景下的核心問題，特殊狀況下如何展示等。

在這一階段還有一點我覺得比較重要，就是融入更多自己對于人性化、創(chuàng)新細(xì)節(jié)的思考，而不滿足于沿用各種設(shè)計指南里早就用濫了的「通用方案」。比如一個語音播放組件，按照常規(guī)思路就是簡單地做一下播放、暫停幾種狀態(tài)的展示，但如果代入場景更深入地思考一下，比如用戶第二次點擊「播放」時，會不會是因為之前語速太快、沒聽清楚？可不可以在第二次點擊時適當(dāng)調(diào)慢速度幫助用戶聽清？這些細(xì)節(jié)可能很小、難量化、甚至根本不會被用戶注意到，但卻是我們作為 UX 設(shè)計師應(yīng)有的態(tài)度。

5. 標(biāo)準(zhǔn)量化

對于組件級的優(yōu)化，我們也需要跟蹤其上線后的具體效果，可以通過定量和定性兩部分來看，在發(fā)布之前明確埋點機(jī)制。定量方面我們考慮的是推動業(yè)務(wù)建立之前沒有的灰度機(jī)制，通過灰度 50% 對比同一業(yè)務(wù)內(nèi)容下組件優(yōu)化前/優(yōu)化后的關(guān)鍵數(shù)據(jù)指標(biāo)（比如點擊次數(shù)、完成時長等），減弱全量覆蓋機(jī)制下因為業(yè)務(wù)內(nèi)容本身變化造成的干擾；定性則主要關(guān)注輿情系統(tǒng)（內(nèi)部輿情工具、應(yīng)用內(nèi)社區(qū)、App Store 等）里的用戶反饋，也可以考慮達(dá)到一定覆蓋面后發(fā)放問卷進(jìn)行滿意度/NPS 調(diào)研等。

6. 效果驗證

通過定量/定性數(shù)據(jù)追蹤組件優(yōu)化是否達(dá)到效果，如果不理想則進(jìn)一步分析原因，迭代改進(jìn)設(shè)計方案。

 

最后是幾點心得提煉

• 學(xué)會優(yōu)先級管理，完整設(shè)計提案被說沒開發(fā)資源，那就拆成一塊塊組件見縫插針推動。
• 不用修 BUG 心態(tài)對待日常發(fā)現(xiàn)的體驗問題，納入所有場景綜合考慮。
• 能完美平衡訴求固然好，但更多時候我們需要取舍決策，要清楚「什么最重要」。
• 「習(xí)以為?！沟奈幢厥亲詈玫?，多一點自己對于人性化、創(chuàng)新細(xì)節(jié)的思考。