最近在推動手頭負責的一個 C 端移動產(chǎn)品的組件化體驗升級，這個產(chǎn)品因為復雜業(yè)務場景和一些歷史遺留問題，許多最基本的組件線上樣式與交互體驗都可以用「慘不忍睹」來形容，而對業(yè)務組件做系統(tǒng)整理和重新設計優(yōu)化，也是項目組普遍認可的事情。雖然才起步不久，但也在過程中積累了一些對于組件化設計升級的思考和心得，在此總結一下，歡迎補充。

什么情況下做組件化設計

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

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

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

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

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

3. 線上組件體驗是否影響核心業(yè)務指標

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

組件化設計有什么好處

1. 思考角度更全面

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

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

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

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

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

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

3. 想法落地更容易

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

組件化設計流程

具體的組件化設計升級流程我總結成了下圖：

1. 類目梳理

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

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

2. 場景走查

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

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

3. 問題分析

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

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

4. 方案設計

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

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

5. 標準量化

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

6. 效果驗證

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

最后是幾點心得提煉

學會優(yōu)先級管理，完整設計提案被說沒開發(fā)資源，那就拆成一塊塊組件見縫插針推動。

不用修 BUG 心態(tài)對待日常發(fā)現(xiàn)的體驗問題，納入所有場景綜合考慮。

能好平衡訴求固然好，但更多時候我們需要取舍決策，要清楚「什么最重要」。

「習以為常」的未必是最好的，多一點自己對于人性化、創(chuàng)新細節(jié)的思考。

分享文章：移動產(chǎn)品的組件化設計
當前鏈接：http://jinyejixie.com/news29/168979.html

成都網(wǎng)站建設公司_創(chuàng)新互聯(lián)，為您提供外貿建站、建站公司、域名注冊、網(wǎng)站改版、企業(yè)網(wǎng)站制作、定制開發(fā)

廣告

聲明：本網(wǎng)站發(fā)布的內容（圖片、視頻和文字）以用戶投稿、用戶轉載內容為主，如果涉及侵權請盡快告知，我們將會在第一時間刪除。文章觀點不代表本網(wǎng)站立場，如需處理請聯(lián)系客服。電話：028-86922220；郵箱：631063699@qq.com。內容未經(jīng)允許不得轉載，或轉載時需注明來源： 創(chuàng)新互聯(lián)