踩了4次坑,終于搞清楚B端數(shù)字化產(chǎn)品為什么要做低耦合設(shè)計
編輯導(dǎo)語:B端產(chǎn)品的設(shè)計流程比較復(fù)雜,從業(yè)務(wù)調(diào)研到后面的產(chǎn)品原型設(shè)計,中間需要經(jīng)歷較長的過程;并且B端產(chǎn)品的研發(fā)周期長、成本高,所以很多B端數(shù)字化產(chǎn)品要做低耦合設(shè)計;本文作者對此進(jìn)行了一些思考以及分享經(jīng)驗,我們一起來看一下。
B端產(chǎn)品設(shè)計有非常多的規(guī)則配置以及實際業(yè)務(wù)邏輯;在設(shè)計底層的權(quán)限,組織架構(gòu),規(guī)則配置時,需要考慮底層的設(shè)計邏輯以及邏輯實現(xiàn)的耦合邏輯。
我在做數(shù)字化項目時,在做復(fù)雜的業(yè)務(wù)規(guī)則邏輯時也踩過不少坑,分享下自己做幾個小功能時總結(jié)的小case,希望可以對做B端產(chǎn)品設(shè)計的同學(xué)有所幫助。
一、組織架構(gòu)遇上審批流:數(shù)據(jù)庫設(shè)計時,最小顆粒度設(shè)計存儲內(nèi)容
成熟的數(shù)字化系統(tǒng),組織架構(gòu)和審批流跑不了。當(dāng)你將身份,角色,門店范圍,門店類型(直營店,加盟店,合作店,獨立店等),審批規(guī)則等等這些信息混合在一起。
設(shè)計組織架構(gòu)和審批流時,如何抽絲剝繭?找到最本質(zhì)的邏輯規(guī)則設(shè)計合理的架構(gòu)呢?如何通過低耦合的設(shè)計方式,提供簡單優(yōu)雅的設(shè)計方案?
我的建議:通過梳理,將影響業(yè)務(wù)邏輯的因素,做成橫坐標(biāo);每個因素上的狀態(tài)值(或者類型)做成縱坐標(biāo);形成2維矩陣圖;然后試著做全集的場景和方案梳理。
這種方式很慢,但是你做到三分之一的時候就會慢慢發(fā)現(xiàn)規(guī)律,做到一半的時候就知道后面的邏輯,做到最后的時候,方案呼之欲出。
圖表是最能幫助你梳理思路的工具,我在之前的文章中也分享過幾個圖表??梢钥聪隆?參考類似:
↑用了一個小伙伴的圖↑
通過窮盡方案抽象出通用功能,做模塊化時保證不會耦合。
二、交互設(shè)計時,和技術(shù)溝通,避免因為交互流程的耦合影響技術(shù)方案的耦合
在產(chǎn)品設(shè)計交互架構(gòu)時,有時候會考慮不到實際的數(shù)據(jù)庫和技術(shù)實現(xiàn)方案,在設(shè)計時會出現(xiàn)頁面的實現(xiàn)方式有耦合邏輯,會導(dǎo)致技術(shù)的實現(xiàn)方案有耦合度;此時需要通過和技術(shù)團(tuán)隊的溝通,找到這樣的隱形坑,優(yōu)化設(shè)計方案,更新產(chǎn)品策略,降低耦合度。這就是我經(jīng)常和技術(shù)說的“通過產(chǎn)品策略降低技術(shù)難度?!?/p>
什么意思?產(chǎn)品經(jīng)理通過業(yè)務(wù)場景的支持和技術(shù)方案實現(xiàn)的平衡,找到最優(yōu)的解決方案。以此獲取產(chǎn)品的成功。
舉一個例子:最近在做一個在途庫存的計算器邏輯,在做一個批量編輯列表頁面時,交互的設(shè)計為了降低用戶的操作繁瑣度,默認(rèn)提供了打開即為編輯狀態(tài)的頁面,同時提供了單條刪除的操作,技術(shù)在實現(xiàn)時犯難了。
每一個列表數(shù)據(jù)都以數(shù)據(jù)ID為記錄;但是如果編輯和刪除操作同時存在的話,在存儲數(shù)據(jù)時,會出現(xiàn)超級大的計算量,無法確認(rèn)到底是對哪個數(shù)據(jù)進(jìn)行了操作;此時需要產(chǎn)品結(jié)合實際的業(yè)務(wù)場景找到平衡方案。
另外一個在配置角色和全新規(guī)則時,交互設(shè)計可能將門店-角色-權(quán)限做了耦合的交互設(shè)計;但是在底層設(shè)計數(shù)據(jù)結(jié)構(gòu)時,不能根據(jù)產(chǎn)品的設(shè)計方案設(shè)計,而是需要通過角色-全新-門店建立最小顆粒度的數(shù)據(jù)結(jié)構(gòu)。
一定避免因為交互頁面耦合邏輯導(dǎo)致數(shù)據(jù)結(jié)構(gòu)的耦合設(shè)計,產(chǎn)生耦合后,想改就要動數(shù)據(jù)庫,想想都難受!
三、篩選邏輯:配置項目讀取配置,不要在代碼里寫過濾邏輯
在做企業(yè)數(shù)字化項目時,有的團(tuán)隊為了控制成本,直接將客戶的業(yè)務(wù)邏輯放在代碼里,導(dǎo)致后面客戶想要調(diào)整一個簡單的業(yè)務(wù)邏輯都非常困難。
我們在做數(shù)字化方案時,秉承的一個原則就是能做配置項目的,能做最小顆粒度配置的,絕對不在代碼里寫死邏輯。
企業(yè)的業(yè)務(wù)變動是大概率事件,不能為了節(jié)約成本幫客戶做一個“死板的系統(tǒng)”,而是要做成靈活可配置,靈活而優(yōu)雅的系統(tǒng)。
四、結(jié)合場景:不要過分設(shè)計;不要因為要解耦合做的太零散,導(dǎo)致頁面配置時太瑣碎
這條是結(jié)合3來說~有時候我們不能為了靈活而過度設(shè)計,在不必要的環(huán)節(jié)設(shè)計成太多的配置項。
比如常見的很多信息化系統(tǒng)非常靈活,各種字段可配置,各種流程可配置,甚至是數(shù)據(jù)檔案都可以配置!
最后導(dǎo)致系統(tǒng)運行起來時,對人員的操作能力要求比較高,只有充分了解的業(yè)務(wù)和系統(tǒng)的功能才能配置成功。
在考慮系統(tǒng)的解耦合程度和用戶的上手操作難度時,產(chǎn)品經(jīng)理需要注意做權(quán)衡。
以上幾個點,是做數(shù)字化系統(tǒng)時,做B端產(chǎn)品設(shè)計時,解耦合需要注意的點,希望對大家有所幫助。
做B端產(chǎn)品設(shè)計很久,越發(fā)覺得B端產(chǎn)品經(jīng)理與C端產(chǎn)品經(jīng)理的相同和不同處。
關(guān)于B端產(chǎn)品的模型框架,我梳理成一個體系,分享給大家:
歡迎大家留言交流~
作者:邊亞南(bianyanan1024);公眾號:邊亞南;北京華秉科技產(chǎn)品總監(jiān),原百度、搜狗用戶體驗設(shè)計師。專注私域流量運營和數(shù)字化體系搭建。
本文由 @邊亞南 原創(chuàng)發(fā)布于人人都是產(chǎn)品經(jīng)理,未經(jīng)許可,禁止轉(zhuǎn)載
題圖來自 Unsplash,基于 CC0 協(xié)議
學(xué)習(xí)收藏了,今天就當(dāng)一回課代表吧。搭建私域流量運營,當(dāng)然必須要有工具。給大家推薦一款由【人人都是產(chǎn)品經(jīng)理】【起點課堂】旗下獨立研發(fā)的私域流量運營工具——糧倉·企微管家。糧倉·企微管家是一款基于企業(yè)微信的一款營銷型SCRM系統(tǒng)。集裂變獲客、留存促活、銷售變現(xiàn)、客戶管理于一體的私域增長閉環(huán)系統(tǒng)。覆蓋企業(yè)客戶運營的生命周期,助力企業(yè)私域流量運營,提升售前/售后服務(wù)能力。還可以免費開始使用哦~ http://996.pm/M0A06
寫得很好,加上案例更通俗易懂!
標(biāo)題深,內(nèi)容淺。B端系統(tǒng)解耦要從邏輯,研發(fā)兩方面結(jié)構(gòu)。將產(chǎn)品線的發(fā)展規(guī)律,管理差異化,系統(tǒng)平臺支撐方面進(jìn)行邏輯梳理。技術(shù)方面要進(jìn)行模塊化微服務(wù)。做到客戶,合同,付款,服務(wù),服務(wù)評價五個維度的數(shù)據(jù)閉環(huán)。模塊間數(shù)據(jù)傳輸,模塊內(nèi)部邏輯判斷。不用狀態(tài)傳輸,邏輯+邏輯判斷。
怎么理解不用狀態(tài)傳輸,用邏輯判斷?能否舉個例子