對于跨端產品，有些設計師會集中精力關注 C 端的設計，而對 B 端的內容配置部分則比較輕視。而當 C 端用戶看到配置得亂七八糟的內容時，卻不會覺得這是 B 端用戶的鍋，只會吐槽產品設計本身不合理，作為跨端產品設計師，應該為完整的全鏈路體驗負責。

對于很多內容型產品，C 端用戶見到的界面里，有相當一部分并非直接出自設計師之手，而是 B 端的商家、運營們配置的結果，而如果沒有對 B 端用戶的內容配置進行合理的規范約束、引導和審核，讓其自由發揮的話，最終在 C 端的呈現效果將完全不可控，影響到產品的整體視覺印象和使用體驗。

我目前負責的一塊業務在這方面就存在比較嚴重的遺留問題，這個業務的主要模式是商家和運營在 B 端發布帶薪任務，C 端用戶申領和完成任務來賺取薪酬。而業務的 B 端任務配置等環節目前幾乎沒有任何約束可言，比如信息展示區域，B 端用戶隨便找個第三方編輯器寫好 HTML 內容再往配置表單里一扔，就直接呈現給了 C 端用戶，于是各種千奇百怪的字號、配色、對齊等問題紛紛出現。除了 C 端的展示效果失控以外，B 端編輯的代碼門檻（需要一定HTML和JSON基礎）、大量數據重復編輯成題目的低效等問題，對 B 端用戶本身也很不友好，影響到 B 端未來向更多外部商家開放的可行性。

在這樣的問題背景下，我們在重新設計 B 端整體的任務發布流程時，對其中任務配置（包括信息展示與題目）這個關鍵一環進行了重點優化，基于組件化的設計思路，完整走查已有和潛在的業務用例，從中抽象出適用于各種業務場景、可靈活拼裝組合的可視化組件/模塊，并約束好最終映射到 C 端的樣式規范，達到降低 B 端配置門檻和規范 C 端呈現效果的兩大設計目標。因為業務場景很多、橫跨 PC/移動兩個平臺，涉及到的背后邏輯也很復雜，在適配業務場景時還要考慮到兼容性、技術可行性等，設計經歷了一波三折的碰撞才接近定稿，以下就具體講講我對內容配置場景下的進行組件化設計過程中遇到的挑戰和思考。

完整用例走查與分層抽象歸納

復雜多元的業務場景是對于組件化設計較大的挑戰之一，為此我們花了一段時間體驗 C 端各種類型的線上任務、收集用戶反饋截圖等，并在前端和運營的幫助下整理出了相對完整的用例列表，除此之外也結合和業務方了解到的后期擴展計劃，將還未開發上線的潛在新業務場景納入一并考慮。這個過程會耗費一定時間，但卻是組件化設計前期非常必要的步驟，直接影響到組件的覆蓋面和可擴展性。

在業務用例收集到一定程度后，開始對內容維度自上而下分層進行歸納，抽象出各類展示/題目組件，和不同組件的構成、樣式與附加邏輯（有點類似HTML、CSS和JS的關系），對信息結構逐漸形成清晰的理解。

在不同維度的內容層級梳理清楚后，便基于此搭建 B 端配置頁面的布局框架，這個過程讓配置步驟從毫無重點優先級（比如在一個表單里同時混雜了構成、樣式與邏輯相關的配置項，低頻的邏輯配置操作出現在前置顯眼位置）變為自上而下層層遞進（激活框架-添加組件-插入構成元素-更改樣式-設置附加邏輯），關聯信息配置的聯動映射關系也更清楚。

基于梳理出來的組件樣式類型與邏輯配置項，又可以進一步定義映射到 C 端組件的視覺與交互規范，而 B 端用戶只能基于規范已有的內容進行有限的選擇（比如定義某段文本屬于「標題樣式」還是「正文樣式」），不能隨心所欲地自定義控制樣式（如隨意更改文本的字號、顏色）等。

大量級數據的編輯效率提升

前面梳理內容層級時，構成部分我拆成了常量（手動輸入的數據）和變量（本地上傳的數據），而變量這個概念的引入則和大量級（1K+、1W+）數據導入的業務場景緊密相關。

舉個例子，如果 1 個 B 端用戶想通過任務發放收集 1000 條不同文本的語音朗讀數據，如果沒有變量（本地上傳的數據）的概念，就意味著他需要手動選擇或復制 1000 次文本朗讀組件，而每次更改的只有朗讀對象這一個字段。但如果選擇從本地導入這 1000 條文本的表格數據并統一命名為變量 text，編輯朗讀對象時插入這個叫 text 的變量，則只需要編輯 1 次文本朗讀組件就夠了，系統會根據變量值的個數自動生成 1000 個任務發放給 C 端用戶，大大提升了任務配置效率。

這里對于設計的挑戰在于怎么讓選擇和插入變量的過程更直觀、易用。在產品之前的配置流程里，是通過讓用戶輸入 $content.image 或者 {{text}} 一類的字符串來實現變量的插入，這個過程存在一定的學習成本（為了區分于普通輸入文本，字符串的格式通常需要設計得比較復雜和特殊），對用戶也不夠直觀；而市場上其他一些競品則是提供下拉選擇框，讓用戶從中選擇導入的變量名，這需要用戶記住自己導入的每一個變量和其對應的值具體是什么（不能預覽變量內容），也無法滿足常量和變量靈活組合展現的業務需求（比如插入字段「品牌名：阿迪達斯」，其中品牌名為常量，阿迪達斯為變量）。

我們最終的方案是在編輯文本或其他多媒體內容時，提供一個插入變量的入口，點擊顯示導入的變量列表，并帶有變量第一個值內容的預覽信息，插入后變量以標簽而非字符串的方式展現在編輯區域，可以進一步配置樣式和附加邏輯。這個過程完全可視化、可以提前預覽內容，也能滿足手動輸入的文本常量和插入的文本變量靈活組合成段落的需求。

平衡B端/C端、PC/移動的所見即得編輯模式

為了進一步提高配置過程的直觀性，降低 B 端用戶學習配置的成本，我們在設計配置表單時引入了所見即得的概念，并探索了多種不一樣的設計模式。這里的主要挑戰在于多端、多平臺的平衡，兼顧 B 端配置的效率和 C 端展示的直觀，并用一套方案來適應 PC/移動任務的配置。

方案一是類似下圖這樣的預覽視圖 + 表單，也是非常常見的一種移動端組件配置界面設計模式，編輯表單的過程中可以實時預覽組件在 C 端的最終呈現效果，兼顧了編輯效率和直觀性。

方案二是將編輯和預覽功能整合，拖拽組件到和 C 端展示效果完全一樣預覽視圖里，并在當前視圖下直接編輯 C 端可見的組件字段，而在 C 端不直接可見的一些配置（如添加選項）、包括變量插入等則在側邊欄完成。方案二在直觀性上比方案一更有優勢，但樣式配置與邏輯配置、變量插入的操作區割裂開來（側邊欄不全是低頻操作），編輯效率上有所不及。

方案一和方案二是早期的兩版設計方案，但是它們卻都存在一個缺陷，就是我們的產品 C 端是跨平臺的，一部分任務是移動視圖，另一部分任務卻要到 PC 端完成，還有一部分任務可以跨兩個平臺。對于 PC 端任務的配置，方案一這種左右分欄展示的方式就不太合適，需要重新進行設計，方案二也需要設計兩種預覽視圖，而開發并不愿意再額外做一套 PC 端任務的配置方案，于是重新考慮新的設計。

最終方案是在方案二的基礎上改進而得，其實設計方案二的時候我們落入了一個思維陷阱，就是直觀感受組件在 C 端的展現效果?≠ 編輯的視圖需要做成和 C 端完全一樣，事實上，只需要讓 B 端用戶知道自己配置的內容在 C 端展現的一個大概位置順序，不出現上面配置一段文本內容，下面出現說明「請朗讀以下（實際應為以上）文字」的情況就夠了；而 C 端組件在 PC/移動的展示雖然樣式上有差異（比如標題居左和居中，選項用圓點和用按鈕），但結構順序是一致的（比如選擇組件都是標題-說明-選項），在 B 端只需要設計一套結構順序一致的表單，就可以同時映射到 PC 和移動。

設計方案二時的第二個思維陷阱，是將 C 端可見信息與不可見信息配置的完全分離，這樣雖然能更好地讓 B 端用戶代入 C 端視角感受自己配置的內容的展現效果，但卻割裂了 B 端用戶的操作區域，如果從 B 端用戶視角來看，如果要設計兩塊操作區域的話，按照高頻操作/低頻操作來劃分是更合理的做法。

意識到這一點后，我們將一部分?C 端不可見但高頻的配置項（比如插入數據）移到了頁面中央的編輯視圖區域，并且在編輯視圖被激活的狀態下展示，失焦則隱藏；另一部分 C 端可見但低頻的配置項（比如圖片上傳的數量限制說明）移到了頁面右側的附加操作區域，編輯視圖下只展示高頻、關鍵信息，和最終 C 端效果存在差異，但不會因為這些差異影響到用戶配置的過程和結果。而如果用戶想完全預覽在 C 端的效果的話，則在之后提供額外的預覽試做入口，除了樣式也可以體驗題目之間的跳轉邏輯等。以此來兼顧配置的效率與直觀性，最終效果類似下圖（不方便直接放設計稿，找了個類似的問卷網截圖）：

考慮兼容性

最后提一下兼容性的問題，因為內容展示區域之前是完全沒有組件化，通過第三方編輯器寫好 HTML 插入的方式，在設計組件化后的方案時也要考慮到先兼容之前已有的線上任務展現，再逐步完成遷移。

基于兼容性的考慮，改進了第一版相對徹底的組件化配置方案，即選擇文本/圖片/視頻等組件然后進行拼裝，引入富文本框（當然，可選樣式做了嚴格的限制，不能隨意調整字號顏色尺寸等），在富文本框中支持插入組件，而老版本的任務則通過富文本框的代碼模式進行兼容。

總結

對于跨端產品，有些設計師會集中精力關注 C 端的設計，而對 B 端的內容配置部分則比較輕視，甚至直接讓產品經理代勞完成 B 端的設計。然而，雖然?B 端的內容配置看上去不起眼、用戶量有時也很有限，但配置的不合理卻直接影響到 C 端很多頁面的最終體驗，我們也不能指望所有的 B 端用戶都能像自己一樣具備一定的審美和摳細節能力，或者依賴實質約束性不大的配置規范文檔。而當 C 端用戶看到配置得亂七八糟的內容時，卻不會覺得這是?B 端用戶的鍋，只會吐槽產品設計本身不合理，作為跨端產品設計師，應該為完整的全鏈路體驗負責。

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

題圖來自?Pexels，基于?CC0?協議