原標題：踩了4次坑，終於搞清楚B端數字化產品爲什麼要做低耦合設計

B端產品設計有非常多的規則配置以及實際業務邏輯；在設計底層的權限，組織架構，規則配置時，需要考慮底層的設計邏輯以及邏輯實現的耦合邏輯。

我在做數字化項目時，在做複雜的業務規則邏輯時也踩過不少坑，分享下自己做幾個小功能時總結的小case，希望可以對做B端產品設計的同學有所幫助。

一、組織架構遇上審批流：數據庫設計時，最小顆粒度設計存儲內容

成熟的數字化系統，組織架構和審批流跑不了。當你將身份，角色，門店範圍，門店類型（直營店，加盟店，合作店，獨立店等），審批規則等等這些信息混合在一起。

設計組織架構和審批流時，如何抽絲剝繭？找到最本質的邏輯規則設計合理的架構呢？如何通過低耦合的設計方式，提供簡單優雅的設計方案？

我的建議：通過梳理，將影響業務邏輯的因素，做成橫座標；每個因素上的狀態值（或者類型）做成縱座標；形成2維矩陣圖；然後試着做全集的場景和方案梳理。

這種方式很慢，但是你做到三分之一的時候就會慢慢發現規律，做到一半的時候就知道後面的邏輯，做到最後的時候，方案呼之欲出。

圖表是最能幫助你梳理思路的工具，我在之前的文章中也分享過幾個圖表。可以看下～ 參考類似：

↑用了一個小夥伴的圖↑

通過窮盡方案抽象出通用功能，做模塊化時保證不會耦合。

二、交互設計時，和技術溝通，避免因爲交互流程的耦合影響技術方案的耦合

在產品設計交互架構時，有時候會考慮不到實際的數據庫和技術實現方案，在設計時會出現頁面的實現方式有耦合邏輯，會導致技術的實現方案有耦合度；此時需要通過和技術團隊的溝通，找到這樣的隱形坑，優化設計方案，更新產品策略，降低耦合度。這就是我經常和技術說的“通過產品策略降低技術難度。”

什麼意思？產品經理通過業務場景的支持和技術方案實現的平衡，找到最優的解決方案。以此獲取產品的成功。

舉一個例子：最近在做一個在途庫存的計算器邏輯，在做一個批量編輯列表頁面時，交互的設計爲了降低用戶的操作繁瑣度，默認提供了打開即爲編輯狀態的頁面，同時提供了單條刪除的操作，技術在實現時犯難了。

每一個列表數據都以數據ID爲記錄；但是如果編輯和刪除操作同時存在的話，在存儲數據時，會出現超級大的計算量，無法確認到底是對哪個數據進行了操作；此時需要產品結合實際的業務場景找到平衡方案。

另外一個在配置角色和全新規則時，交互設計可能將門店-角色-權限做了耦合的交互設計；但是在底層設計數據結構時，不能根據產品的設計方案設計，而是需要通過角色-全新-門店建立最小顆粒度的數據結構。

一定避免因爲交互頁面耦合邏輯導致數據結構的耦合設計，產生耦合後，想改就要動數據庫，想想都難受！

三、篩選邏輯：配置項目讀取配置，不要在代碼裏寫過濾邏輯

在做企業數字化項目時，有的團隊爲了控制成本，直接將客戶的業務邏輯放在代碼裏，導致後面客戶想要調整一個簡單的業務邏輯都非常困難。

我們在做數字化方案時，秉承的一個原則就是能做配置項目的，能做最小顆粒度配置的，絕對不在代碼裏寫死邏輯。

企業的業務變動是大概率事件，不能爲了節約成本幫客戶做一個“死板的系統”，而是要做成靈活可配置，靈活而優雅的系統。

四、結合場景：不要過分設計；不要因爲要解耦合做的太零散，導致頁面配置時太瑣碎

這條是結合3來說～有時候我們不能爲了靈活而過度設計，在不必要的環節設計成太多的配置項。

比如常見的很多信息化系統非常靈活，各種字段可配置，各種流程可配置，甚至是數據檔案都可以配置！

最後導致系統運行起來時，對人員的操作能力要求比較高，只有充分了解的業務和系統的功能才能配置成功。

在考慮系統的解耦合程度和用戶的上手操作難度時，產品經理需要注意做權衡。

以上幾個點，是做數字化系統時，做B端產品設計時，解耦合需要注意的點，希望對大家有所幫助。

做B端產品設計很久，越發覺得B端產品經理與C端產品經理的相同和不同處。

關於B端產品的模型框架，我梳理成一個體系，分享給大家：

歡迎大家留言交流~