B端設計實戰:從定制化需求到平臺通用型設計

5 評論 8470 瀏覽 78 收藏 10 分鐘

編輯導語:隨著平臺業務的逐漸增多,需要對其進行定制化的需求設計,業務需求多樣性與平臺能力統一性的矛盾該如何解決?本文就該矛盾展開分析,并提出解決的相應措施,確保平臺實現了通用一致的設計目的,一起來看下吧。

一、平臺提效設計的矛盾點

在開始闡述本次專題之前,我想先簡單介紹下我們的平臺業務背景,隨著字節教育前臺業務的不斷增多,前臺業務對題目、圖片、試卷等資源的需求量也越來越大,為了避免重復生產造成的資源浪費,題庫中臺生產能力應運而生,我們通過招募Freelancer或簽約供應商,來為各業務線提供教育資源的生產服務,因此對內部我們也通常稱呼為生產平臺。

下圖是我們的任務廣場頁,我們可以看到界面內羅列展示著各種各樣的任務,這些任務通常會由不同業務根據需求進行投放展示,從而供生產員們自由領取進行生產。

作為一個B端生產平臺,平臺定位決定我們要服務多業務,多業務必然會產生復雜多變的業務場景,從而衍生出多樣化的定制需求。

隨著接入生產平臺的業務不斷增多,我們發現了一個日趨顯著的問題,以同一個補答案的任務能力為例,我們會接收到3個存在差異的業務定制需求:

德國哲學家萊布尼茨曾說過:“世上沒有兩片完全相同的樹葉?!?/p>

我今天也想說:“中臺沒有兩個可直接復用的業務需求?!?/p>

從上面的業務需求例子中,我們可以發現不同業務對平臺能力的特性存在顯著差異化的訴求,而每次業務需求一旦出現新的定制點,就意味著要重新走一遍研發排期流程,即便走最敏捷的研發測試流程也需要1周時間,這對業務而言非常的不友善,下游的設計、前端、后端、測試也不得不在各個業務的定制需求中疲于奔命,逐漸背離了平臺快捷高效的初衷。

為了解決這個問題,平臺項目組內部進行反復探討,我們回歸到了一種經典的哲學思辨:

業務需求多樣性與平臺能力統一性的矛盾該如何解決?

為了解決這個矛盾,我們嘗試過一些不靠譜的方法:

  • 我們對業務妥協過,通過拉代碼分支的方式為業務支持各類定制邏輯,讓平臺能力變得冗雜且不通用,最終導致平臺的維護成本急劇上升;
  • 我們對業務強硬過,希望通過說明書或培訓讓業務先了解我們的平臺能力規則,再提出符合規則的需求,但收效甚微,也讓業務開始質疑平臺的服務能力。

通過各種踩坑后,最終我們達成了一個共識:

  • 首先,業務需求一定是多樣化的,這是業務背景差異性所決定的客觀現實;
  • 其次,平臺能力必須是統一的,這是基本原則,否則平臺將不再是平臺;
  • 最后,二者看似沖突但并非不可調和,辯證哲學針對這個話題已經給出了解答,只要我們能夠抓住業務需求多樣性的共性特征,我們就找到通用化設計的鑰匙。

二、從矛盾到通用的切入點

在開展設計前,我們需要明確下當前的設計現狀和設計原則:

作為B端生產平臺的設計師,我們需要:

  1. 為解決多業務的生產問題而設計;
  2. 為維持平臺能力的通用性而設計;
  3. 面臨復雜的業務場景和平臺邏輯,必須關注能力抽象、角色、權限等問題。

為此我們的設計方案,需要契合以下2點原則:

1. 基于通用場景抽象共性特征

為了確保設計能夠通用一致,我們首先基于多個業務針對平臺任務提出的定制需求,歸納了一個通用需求場景:

關鍵目的是契合業務特點,表現訴求是對平臺任務進行定制。

基于以上假設,我們重新梳理關鍵目的(業務特點),發現不同的業務背景間包含多個同類的業務屬性,我們可以將其抽象歸納為關鍵目的的共性特征。

我們繼續梳理表現訴求(定制任務),發現不同的業務定制需求中包含多個同類的任務特性,我們可以將其抽象歸納為表現訴求的共性特征。

通過抽象共性特性,我們可以將通用場景轉化為明確的設計機會點,業務屬性成為通用條件,任務特性成為通用結果。

2. 將共性特征轉化為平臺能力

將通用業務屬性錄入至平臺內,并為其內置常用的變量值,形成平臺配置能力的基礎條件。

如果業務認為我們抽象的業務屬性不夠或過多,我們依然支持業務在項目權限內對業務屬性和變量值進行增刪修改,而我們提前基于業務權限做了項目數據分隔,所有變更僅在單一業務數據內生效,不會影響到其他業務的屬性及變量值數據。

這些業務屬性將成為平臺的通用能力,用于服務更多的業務需求,達到通過配置設計實現定制效果的目的。

3. 用平臺配置設計實現定制

根據“不同業務屬性,定制不同任務特性”的場景思考進行配置設計,我們將基于業務增刪修改后的業務屬性作為任務配置的通用條件,任務特性則成為任務配置的通用配置項。

通過切換業務屬性條件實現匹配業務背景的對應目的,基于業務屬性條件可以實現配置更多定制的任務特性,而每次的規則配置將不再需要重復走研發流程,極大的提升了業務體驗,同時也幫助設計產研從重復性勞作中釋放,給予我們更多時間來進一步豐富和優化平臺體驗。

整個配置設計對業務而言,默認條件對應業務背景的關鍵目的,而配置項則對應業務的表現訴求,從心理模型上匹配了業務的需求邏輯,實現了清晰高效的設計目標;

對平臺而言,將定制點中的共性特性進平臺能力通用化,確保平臺配置的最大兼容性和復用性,實現了通用一致的設計目的。

通過以上方法,我們將業務配置流程平均耗時從研發流程10天降低至手動配置1天,整體流程提效90%以上。

#專欄作家#

愚者秦,微信公眾號:feather-wit,人人都是產品經理專欄作家。先后任職于愛奇藝、字節跳動的一枚體驗設計師,同時是兼職寫小說的斜杠青年,善于總結和抽象設計方法,熱衷于探索不同用戶場景下的產品策略。

本文原創發布于人人都是產品經理,未經許可,禁止轉載

題圖來自Unsplash,基于CC0協議

更多精彩內容,請關注人人都是產品經理微信公眾號或下載App
評論
評論請登錄
  1. 生物公司小底層覺得是不是就是提煉出通用配置通過變量轉化出適合場景的東東

    回復
  2. 通用的基礎是對于場景的精準把握,以及對用戶需求的深度理解。如果拋開場景業務去談通用,不僅毫無意義,還可能會誤入歧途。所以想做通用的話,先去把每類用戶、每類場景研究透,市場上的工具大多是功能堆砌,一到落地時一堆bug。而且通用化的前提是規范先行,開啟通用化,是需要有用戶基礎的,不然那就不是通用化,而是產品經理的個人YY。

    來自廣東 回復
    1. 而且場景有很多種 業務場景 和 用戶場景 項目中基本上是以業務場景為底層,用戶場景為感知層進行通用設計。

      回復
  3. 抽象出來,用高配置實現,這一步比較難

    來自浙江 回復
  4. 將所有業務場景屬性提煉出來,寫進平臺,通過平臺配置,且業務屬性可拓展,是這個意思嗎

    來自四川 回復