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