編輯導語：B端產品的設計流程比較複雜，從業務調研到後面的產品原型設計，中間需要經歷較長的過程；並且B端產品的研發週期長、成本高，所以很多B端數字化產品要做低耦合設計；本文作者對此進行了一些思考以及分享經驗，我們一起來看一下。
B端產品設計有非常多的規則配置以及實際業務邏輯；在設計底層的權限，組織架構，規則配置時，需要考慮底層的設計邏輯以及邏輯實現的耦合邏輯。
我在做數字化項目時，在做複雜的業務規則邏輯時也踩過不少坑，分享下自己做幾個小功能時總結的小case，希望可以對做B端產品設計的同學有所幫助。
一、組織架構遇上審批流：數據庫設計時，最小顆粒度設計存儲內容成熟的數字化系統，組織架構和審批流跑不了。當你將身份，角色，門店範圍，門店類型（直營店，加盟店，合作店，獨立店等），審批規則等等這些信息混合在一起。
設計組織架構和審批流時，如何抽絲剝繭？找到最本質的邏輯規則設計合理的架構呢？如何通過低耦合的設計方式，提供簡單優雅的設計方案？
我的建議：通過梳理，將影響業務邏輯的因素，做成橫座標；每個因素上的狀態值（或者類型）做成縱座標；形成2維矩陣圖；然後試着做全集的場景和方案梳理。
這種方式很慢，但是你做到三分之一的時候就會慢慢發現規律，做到一半的時候就知道後面的邏輯，做到最後的時候，方案呼之欲出。
圖表是最能幫助你梳理思路的工具，我在之前的文章中也分享過幾個圖表。可以看下～ 參考類似：
↑用了一個小夥伴的圖↑
通過窮盡方案抽象出通用功能，做模塊化時保證不會耦合。
二、交互設計時，和技術溝通，避免因為交互流程的耦合影響技術方案的耦合在產品設計交互架構時，有時候會考慮不到實際的數據庫和技術實現方案，在設計時會出現頁面的實現方式有耦合邏輯，會導致技術的實現方案有耦合度；此時需要通過和技術團隊的溝通，找到這樣的隱形坑，優化設計方案，更新產品策略，降低耦合度。這就是我經常和技術説的“通過產品策略降低技術難度。”
什麼意思？產品經理通過業務場景的支持和技術方案實現的平衡，找到最優的解決方案。以此獲取產品的成功。
舉一個例子：最近在做一個在途庫存的計算器邏輯，在做一個批量編輯列表頁面時，交互的設計為了降低用户的操作繁瑣度，默認提供了打開即為編輯狀態的頁面，同時提供了單條刪除的操作，技術在實現時犯難了。
每一個列表數據都以數據ID為記錄；但是如果編輯和刪除操作同時存在的話，在存儲數據時，會出現超級大的計算量，無法確認到底是對哪個數據進行了操作；此時需要產品結合實際的業務場景找到平衡方案。
另外一個在配置角色和全新規則時，交互設計可能將門店-角色-權限做了耦合的交互設計；但是在底層設計數據結構時，不能根據產品的設計方案設計，而是需要通過角色-全新-門店建立最小顆粒度的數據結構。
一定避免因為交互頁面耦合邏輯導致數據結構的耦合設計，產生耦合後，想改就要動數據庫，想想都難受！
三、篩選邏輯：配置項目讀取配置，不要在代碼裏寫過濾邏輯在做企業數字化項目時，有的團隊為了控制成本，直接將客户的業務邏輯放在代碼裏，導致後面客户想要調整一個簡單的業務邏輯都非常困難。
我們在做數字化方案時，秉承的一個原則就是能做配置項目的，能做最小顆粒度配置的，絕對不在代碼裏寫死邏輯。
企業的業務變動是大概率事件，不能為了節約成本幫客户做一個“死板的系統”，而是要做成靈活可配置，靈活而優雅的系統。
四、結合場景：不要過分設計；不要因為要解耦合做的太零散，導致頁面配置時太瑣碎
這條是結合3來説～有時候我們不能為了靈活而過度設計，在不必要的環節設計成太多的配置項。
比如常見的很多信息化系統非常靈活，各種字段可配置，各種流程可配置，甚至是數據檔案都可以配置！
最後導致系統運行起來時，對人員的操作能力要求比較高，只有充分了解的業務和系統的功能才能配置成功。
在考慮系統的解耦合程度和用户的上手操作難度時，產品經理需要注意做權衡。
以上幾個點，是做數字化系統時，做B端產品設計時，解耦合需要注意的點，希望對大家有所幫助。
做B端產品設計很久，越發覺得B端產品經理與C端產品經理的相同和不同處。
關於B端產品的模型框架，我梳理成一個體系，分享給大家：
歡迎大家留言交流~
作者：邊亞南（bianyanan1024）；公眾號：邊亞南；北京華秉科技產品總監，原百度、搜狗用户體驗設計師。專注私域流量運營和數字化體系搭建。
本文由 @邊亞南 原創發佈於人人都是產品經理，未經許可，禁止轉載
題圖來自 Unsplash，基於 CC0 協議