「習以為?！沟奈幢厥亲詈玫?，多一點自己對于人性化、創新細節的思考

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

什么情況下做組件化設計

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

01 是否存在多人協同的情況？

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

02 產品是否進入相對成熟的階段？

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

03 線上組件體驗是否影響核心業務指標？

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

組件化設計有什么好處

01 思考角度更全面

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

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

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

02 細節打磨更充分

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

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

03 想法落地更容易

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

組件化設計流程

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

01 類目梳理

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

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

02 場景走查

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

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

03 問題分析

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

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

04 方案設計

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

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

05 標準量化

對于組件級的優化，我們也需要跟蹤其上線后的具體效果，可以通過定量和定性兩部分來看，在發布之前明確埋點機制。

定量方面我們考慮的是推動業務建立之前沒有的灰度機制，通過灰度 50% 對比同一業務內容下組件優化前/優化后的關鍵數據指標（比如點擊次數、完成時長等），減弱全量覆蓋機制下因為業務內容本身變化造成的干擾；定性則主要關注輿情系統（內部輿情工具、應用內社區、App Store 等）里的用戶反饋，也可以考慮達到一定覆蓋面后發放問卷進行滿意度/NPS 調研等。

06 效果驗證

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

最后是幾點心得提煉

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

本文由人人都是產品經理專欄作家 @鴻影（微信公眾號：?鴻影的設計思考錄） 原創發布于人人都是產品經理?。未經許可,禁止轉載。