2022-1-5 資深UI設計者
在大型B端產品中，不可避免的出現各種配置，配置如同一個個控制閥，決定著業(yè)務的走向，并實現saas產品的千人千面，以滿足不同客戶的訴求，適應不同行業(yè)的業(yè)務場景。但在隨著產品的發(fā)展，配置項也越來越多，逐漸變的不可設計與維護。給什么做的配置？配置是如何生效的？好的配置具有什么特點？如何確定配置的維度？針對這些問題，筆者就以自身的工作經驗，來給大家說一下如何進行復雜B端系統(tǒng)的配置功能設計。
在開始配置之前，我們要想清楚，我們到底在為什么在做配置。
軟件系統(tǒng)是現實世界的抽象，在《THINK IN UML》一書中，表述了現實運行的機制：人驅動系統(tǒng)、事體現過程、物記錄結果、規(guī)則控制運行。由于我們不可能利用一套固定的規(guī)則滿足所有客戶的業(yè)務場景，故我們需要支持規(guī)則可調整，調整規(guī)則的功能，就是配置功能。
我們習慣用用例（use case）的方法來抽象現實世界的需求，一個完整的用例定義由參與者、前置條件、場景、后置條件構成，其中：
那么當我們翻譯成UML的語言時，配置就是定義前置條件和后置條件的系統(tǒng)功能。
那么當我們判斷輸入物滿足什么條件時，還是分兩類：
當我們分析會產生哪些影響時，我們可以分三類：
在復雜的B端系統(tǒng)中，我們往往發(fā)現一個業(yè)務無法用一個用例就描述清楚，導致配置設計還是無法進行，如這個業(yè)務場景：
ERP將商品資料同步到OMS，OMS加工后，同步至各商城。
由于用例體現了參與者的愿望，用例的執(zhí)行結果應對參與者來說是可觀測和有意義的，那么顯然，同步商品資料到各商城，對于業(yè)務的起點ERP來說，并不是其愿望，也不可觀測，但是不存在沒有參與者的用例，用例不應該自動啟動。由于參與者可以是非人的，換句話說，參與者可以是用戶的一個指令，或者是上游系統(tǒng)的通知，故我們往往將用例根據參與者的不同進行拆分。以筆者參與的OMS產品為例，我們根據長期的實踐，習慣根據參與者的不同，劃分為三種不同的用例。不同種類的用例，配置一般影響的類別也不一樣：
我們可以整理出下圖：
上文我們了解了在給什么在做配置，那么一個好的配置應該滿足什么條件呢？
第一：配置邏輯自洽
1、根據輸入物屬性識配自己的規(guī)則時，規(guī)則之間不能相互沖突；
我們拿商品價格策略配置舉例：
當我們識別商品的價格屬性去適配規(guī)則時，我們應使用MECE分析法，按照完全窮盡，相互獨立的原則，將屬性的枚舉值整理出來，當無法完全窮盡時，應設置默認規(guī)則；
2、配置與配置之間不能互相沖突；
我們仍拿商品價格策略配置舉例：通過識別商品的價格、所屬平臺、所屬門店等屬性去適配規(guī)則時，可能會出現同一個商品同時滿足多個配置的情況；
這種情況下，我們需要先判斷多個配置是否可以疊加：
可以疊加：當對實體類進行配置設計時，一般策略是可以疊加的。在這種情況下，可以增加配置疊加規(guī)則，如設置上限\下限：加價策略都是以輸入的原價為基準進行加價，累次加價不能超過原價的8%
不可以疊加：需要增加策略沖突時的應用規(guī)則
第二：配置變更有跡可循：重要的業(yè)務配置，需要提供配置變更日志查詢，記錄配置修改人與修改時間
第三：配置影響的前后數據對應：如果配置影響的是實體類的修改，則應在數據庫中記錄時，需記錄數據原值和配置影響后的數據，不應在同一個字段，用配置影響后的數據直接覆蓋原數據。實體類的新增則不需要；
第四：高拓展性：系統(tǒng)的能力建設是持續(xù)的，配置的設計可以延續(xù)標準的工作流程不斷拓展新增；
第五：配置規(guī)則可理解：需要提供必要的功能指引，配置規(guī)則的入口和操作方式需要符合用戶的認知；
第六：不同維度的繼承關系清晰：在不同維度設計同一個配置時，需要理清楚是否要繼承父輩維度的配置，一般要支持可配置是否要繼承繼承父輩維度的配置，以免造成修改此維度的配置后， 又因為繼承了父輩維度的配置，導致修改配置不生效；
我們發(fā)現，存在配置需要對輸入物的多個屬性進行識別以決定應用哪個規(guī)則的情況，那么我們配置的維度如何設計呢？
當我們只有一項配置時，我們當然可以如下設計：
但是如果我們每次新增一個配置，就長出一個新頁面，很快就會發(fā)現：
用戶操作成本高，需要從大量的配置中，找到對應的配置進行操作；
配置設計拓展困難，每次新增配置，就要做一個新的頁面；
這時，我們可以查看一下系統(tǒng)的領域模型，找到輸入物的共同屬性，來組織配置功能的架構：
這時我們發(fā)現，雖然輸入物繁多，業(yè)務場景各不相同，但是他們都有一個共同的父類：渠道店鋪。如果此時，渠道店鋪作為輸入物的一個屬性，參與配置規(guī)則生效的匹配，則可以將渠道店鋪這個屬性抽離出來，作為配置管理的維度，如：
這樣做的好處是，用戶可以在一個頁面，完成多個配置，而不用不停的切換頁面。
我們也可以看到，渠道店鋪可以繼承渠道、渠道商家、商家、店鋪的配置，我們可以根據真實的業(yè)務訴求，以盡量減輕用戶配置負擔為目標，靈活的選擇配置的對象。
當某個用戶在配置時，一個屬性不同的枚舉值對應的規(guī)則一樣，例如期望所有美團渠道的店鋪都適用自動打印配置時，我們到最小的配置維度【渠道店鋪】去一個一個配置，無疑還是增加了用戶的操作成本。這時我們就可以考慮將其父類作為配置的維度，子類繼承父類的配置規(guī)則。
確認配置的入口，我們一般這么做：
STEP1: 根據配置操作人確認在哪個系統(tǒng)上做配置；
STEP2: 根據業(yè)務用例上的參與者劃分不同的配置模塊；
STEP3: 根據配置維度，聚合配置功能；
STEP4: 易用性改造
以下為筆者負責的OMS系統(tǒng)中配置功能的統(tǒng)計（數據已脫敏）：
關于易用性改造，我們一般做以下事情：
在業(yè)務或數據相關頁展示配置入口；
利用接近原則，在業(yè)務或數據相關頁展示配置入口。利用接近原則是一個心理學名詞，指對于彼此接近的事物，人們總會下意識地將他們建立某種關聯性，并視為一個整體去看待。這么設計可以減輕用戶的認知成本。例如：
將業(yè)務流程中配置形成SOP；
如一個商家的系統(tǒng)進行初始化時，需要進行履約相關配置、庫存價格策略配置、前臺作業(yè)系統(tǒng)配置等，如果一個一個去找相關的配置，則學習成本較高，容易出現配置遺漏等情況，那么我們一般將業(yè)務流程抽象為一個SOP，在SOP中，展示對應配置的入口。例如：
3、支持查詢配置
提供全局性的查詢功能，支持查詢對應的配置。例如：
這天，運營給我反饋了一個問題，希望可以新增訂單自動打印的功能，以支持OMS系統(tǒng)在多個業(yè)務節(jié)點下，可自動打印小票，而不用店員再去手動點擊，而且要可以控制預約單在預約送達時間前1小時打印，由于門店使用的打印機型號不同，還要支持為不同的打印機配置不同的打印模板。
我識別到此需求后，我按照以下工作流程，進行了配置的梳理：
STEP1: 識別參與者，抽象用例：抽象出用例，才能拆分配置功能。強行在一個配置里，將所有業(yè)務規(guī)則都體現，是不現實的；
STEP2: 確定要配置的內容，確定配置的維度；
STEP3：根據配置的操作人和配置的維度，確認配置的入口；
最終可以整理出這個表格，接下來我們就可以根據這個表格、進一步梳理業(yè)務流程圖、整理原型、撰寫PRD了。
配置設計紛繁復雜，今天我以實際的工作經驗，給大家介紹了我對B端配置設計的一些思考，希望可以給大家一些思路，并且引導大家思考功能設計背后的邏輯，權當拋磚引玉吧，畢竟抄競品簡單，但是競品因何發(fā)展成這個樣子，其中的邏輯判斷，與設計權衡，才是我們應該了解的。
文章來源：人人都是產品經理 作者：kathic
分享此文一切功德，皆悉回向給文章原作者及眾讀者.
免責聲明：藍藍設計尊重原作者，文章的版權歸原作者。如涉及版權問題，請及時與我們取得聯系，我們立即更正或刪除。
藍藍設計( www.yvirxh.cn )是一家專注而深入的界面設計公司，為期望卓越的國內外企業(yè)提供卓越的UI界面設計、BS界面設計 、 cs界面設計 、 ipad界面設計 、 包裝設計 、 圖標定制 、 用戶體驗 、交互設計、 網站建設 、平面設計服務