關閉

關于B端系統的產品設計

解構和耦合之間的平衡,你達到了嗎?

過去的一年,負責的業務主要聚焦于平臺運營,隨著業務模式的成熟,也負責建設了許多營銷系統。

本文將以此前實際設計的案例與大家分享關于B端系統的產品設計。

為什么要設計系統?

關于系統,個人認為是將無序、散亂的業務抽象成中心化、標準化的有序服務。而中臺則在系統之上再上升一層,將系統的共性抽象成通用服務。

而中心化和標準化的動機又是什么呢?較高頻的動機有三條:

1) 業務模式足夠成熟

2) 高頻需求重復占用資源,且不具備復用性。

3) 舊有系統耦合性強,延展性弱。

在企業的早期階段,一些非高頻的共性需求并沒有可依賴的中臺系統。為了迅速上線及滿足業務的需求,大多會將其耦合于該系統之中。

但當其他系統有相同需求時無法復用,需要額外開發相同的邏輯。不僅重復消耗資源,后續的迭代難度也會不斷提升。

怎么設計一個系統?

01 明確產品定位,從業務流程梳理系統架構

通過需求分析所確定的產品定位,能夠明確系統要解決的核心問題是什么。而梳理業務流程,則作用在問題解決的深度。

理解業務流程目的是梳理系統架構,從而劃分系統的邊界。邊界清晰能夠讓系統各司其職,專注于自身的功能,并盡量提供可復用的能力。

以抽獎系統為例,輸出其系統架構:

對于抽獎系統而言,它應該專注于抽獎的規則,如:抽獎次數來源、中獎概率、限中次數等等。

對于抽出的獎品是什么,獎品怎么發放,應該由獎品管理、獎品發放系統去消化;而獎品發放所觸發的觸達則應該交由觸達系統。

什么時候應該將非核心需求抽象成中臺系統,什么時候又應該耦合呢?個人認為應從其需求頻次、強度以及投入產出比考慮。

02 確認中心化對象,輸出核心邏輯

在梳理了新系統與現有系統的耦合關系后,下一步則是確認中心化的對象,中心化的方式不同,其核心邏輯、功能框架也會不同。

以獎品管理系統為例,其中心化的方案可以有兩種,如下圖所示:

方案1以獎品作為中心,一個獎品將能夠被多個業務方所使用。因其層級較少,產品、技術設計會更為簡單,后續業務方的操作也更為輕便;

而方案2以獎品池作為中心,每個獎池的獎品相互獨立,雖然方案更為復雜,但優勢是其數據相互獨立,更有利于成本核算以及風控。

當中心化的方案確定,系統的的核心邏輯及數據模型也就初見雛形了。

03 梳理功能框架,定義最小單元

梳理功能框架相信大家都非常熟悉,本小節主要描述最小單元。最小單元,指無法繼續拆解的功能,其通用性的強弱也決定著系統的延展性。

以下將以前端配置化系統為例和朋友們分享,以下的示例分別是最基礎設計方式,以及有贊和筆者的設計方式:

1)固定組件、固定配置

第一種做法,是最基礎的做法。它的思路是對固定的組件進行固定的配置。

以抽獎活動為例:

上圖的兩種抽獎玩法對應著兩種前端樣式,左側是九宮格,右側是老虎機。這兩種樣式對應著頭圖、抽獎模塊、我的獎品及活動規則四個組件。

根據它們組件的共性,我們能抽象的最小單元是頁面頭圖、頁面底色、活動規則、抽獎按鈕的顏色、文字等內容。

由于共性不足,它們的最小單元已經無法延伸。當后續增加新的模板“大轉盤”時,我們就需要再次抽象并迭代,這種設計方案是非常不靈活的,而且最小單元很可能會再次減少。

最小單元共性越少,延展性越差,后續開發的工作量越多。

從九宮格的“我的獎品”、老虎機的“活動規則”來看,它們屬于各自的私有屬性,原則上而言我們也能夠設計成配置項,但從投入產出比、延展性來看顯得不太劃算。

2)有贊:多種組件、獨立配置

有贊的設計思路也是比較常見的設計思路,它的每個組件擁有獨立的配置項。

上圖分別是有贊中拼團、砍價組件對應的配置項,在圖片的紅框部分是商品模塊的配置,同樣是自動獲取商品類型,拼團組件的配置項比砍價多了一個排序規則。

這種設計方式的優點是該組件能夠很輕易的適配業務方的需求,靈活性能夠達到最高。缺點則是組件的特性沒有辦法復用,某個商品模塊或按鈕的特性是無法復用到其他組件的商品模塊或組件之中。

結合了上述的兩種設計思路,根據實際業務方的訴求,筆者設計的思路為:多種組件、共用配置。

3)多種組件、共用配置

這種方式的設計思路是:組件由模板與元素組成,模板決定元素的位置,元素負責視覺及交互的配置。

元素指的是:文字、圖片、線條。這個元素,也是本系統的最小單元。

其拆解示例如下圖:

商品組件由圖片、文字元素及按鈕組件組成,而按鈕組件由線條元素及文字元素組成。

關于元素的拆解思路如下圖:

通過這樣的解構,元素的交叉組合能夠形成不同樣式的組件。

當業務方有新的特性需求,只需要迭代元素的屬性,一次迭代所有的組件都能夠使用這個特性,即避免重復開發也保證了其復用性。產品、研發及測試的工作量的也大大減少。

除了視覺配置,另一部分則是交互的配置,其拆解如下:

最小單元在實際的設計過程中,還應權衡投入產出比,不應為了解構而解構。

04 數據統計規劃

數據統計,有兩點建議:定義清晰、數據獨立。后者與系統架構有關,由于系統之間的相互依賴,會有關聯的數據需要查詢。

個人的經驗是讓系統盡量只消化系統本身的數據,對于關聯的數據可以查詢數據源讓核心系統做整合,最粗糙的設計方式則是直接跳轉至關聯的系統查詢。

05 后續工作

1)角色與權限設計

根據組織架構以及權責范圍,系統的使用角色所對應的權限也不同,常見的權限有增、刪、改、查以及審批流。

2)版本計劃

版本的計劃。可以是對完整系統的分版本上線,也可以是對業務的預估推測系統后續需要延展的功能,這會非常影響系統的技術設計方案。

3)交互設計及文檔撰寫

寫在最后

隨著業務認知的提升、技能的熟練,產品設計的能力可能會達到瓶頸近期的想法是,面向價值設置需求優先級,不僅是企業、業務,還有支撐部門和自己。

以前喜歡做有難度的需求,但難度卻不代表價值,我想好的產品設計一定能幫助業務方帶來可視、可觀的數據成果。

給多方創造價值,才能夠自上而下的推動跨部門協作,持續獲得資源以及成長。

2條評論 添加新討論

2019年12月25日評論

很實用 都是干貨 就是組件配置那不是特別明白 組件-模版-元素之間的關系

回復
  1. 2020年03月22日評論 回復
登錄后參與討論
Ctrl+Enter 發表