編輯導語：規範化設計系統，不僅能夠減少溝通（撕逼）成本，還能提升產品的用户使用體驗。本文作者從自身工作實踐出發，結合案例對規範化設計的工作流程和過程中需要注意的問題進行了梳理分析，與大家分享。
近幾年B端產品異常火爆，但是B端和C端相對，設計規範沒有一個清晰的定義，尤其很多小公司的產品經理身兼數職，每天忙於各種業務的問題，沒有時間來思考系統如何規範化設計，經常會有以下的困惑：
- 需求文檔被開發各種吐槽；
- 系統上線後被業務方各種吐槽；
- 後續版本設計由於前瞻性不足，很難擴展；
俗話説：“磨刀不誤砍柴工”，我們抽空覆盤一下歷史的項目，參考一些優秀的設計，規範需求文檔，會有意想不到的效果。
二、Axure的元件庫規範相信很多小夥伴在學習Axure的時候，一定積攢了很多高大上的元件庫，最後在工作中卻沒有真正的發揮作用，每個公司每個人的設計習慣都有一定的差異，我們可以借鑑其他優秀的設計，嘗試自己來創建元件庫，形成自己的規範。
利用一些基本元件，組合創建一些常用的控件，在使用的時候直接拖動即可，具體創建方法大家自己去搜axure的學習課程就可以了。
對於B端產品，很多業務場景不一樣，設計的方式也有極大的差別，但是我們挑出共性，把系統通用的設計要求在全局規則中一起説明，避免不同技術同事設計不同頁面的時候會有不一樣的效果。
以下只是我梳理的部分要求，大家作為參考即可，全局規則是需要在工作中不斷總結更新的：
1. 搜索項1）搜索項保證整齊，具體排版見需求，搜素項固定於最上面，不允許滾動；
2）下拉搜索，分為“單個搜索”和“多個搜索”，默認都直接支持多個搜索；
3）文本搜索，默認為單個搜索，如果是“模糊搜索”或者”多個搜索”，需求會進行特殊説明，多個搜索時，全部採用空格隔開的方式，例如“AM123456 EB356323”；
2. 操作項1）操作功能放在表單上面，操作按鈕使用“icon”+“文字”的形式展示，最大的節約空間；
2）列表上面的操作若為批量操作的，必須勾選列表數據，若未勾選數據，則操作的時候提示：“請勾選數據再進行操作！”
3）搜索項全部做成“搜索配置”，每個頁面都可以根據用户配置想要的搜索項，但是每個頁面都會固定幾個搜索項是不能取消的，必須顯示的；
4）公共的搜索項要做成公共的形式，減少對接，例如“供應商名稱”，這個是在多個頁面都存在使用的搜索項，前後端對接的時候所有頁面對接方式一樣，避免重複對接，後續如果要改，也是改一個地方即可；
3. 表單1）表單在頁面下半部分展示，表單高度要自適應，若無特殊要求，表單不允許整屏滾動，只能表單內數據進行滾動展示；
2）表單中單條數據的操作項固定，不隨着橫向滾動條的移動變化；
4. 分頁1）分頁要固定在最底層，不允許滾動；
5. 彈框1）彈框頁面固定最上面的標題欄和最下面的操作欄，只允許彈框內滾動，不允許整屏彈框滾動，如有特殊要求會在頁面註明；
2）彈框根據內容決定彈框的大小，彈框要有背景遮罩，查看信息的彈框點擊遮罩的時候會關閉彈框，操作數據的表單彈框點擊遮罩不關閉彈框，這個關閉方式需要在頁面註明，若未註明，默認點擊遮罩不關閉彈框；
6. 導出1）需要大量處理數據生成表格的導出，產品經理需要做成進入“下載中心”後台生成數據的方式，不在當前頁面加載等待，生成完畢之後進入下載中心，再進行下載到本地；
2）導出數據的若未勾選數據，則導出搜索條件下面所有的數據，若勾選了數據則只導出所勾選的數據；
3）導出文件之類的功能一般在頁面直接導出了，不需要進入下載中心，除了有特殊説明的；
下圖為我畫的一個初稿，大家不可以參考：
我們B端很多接觸到的是企業內部員工，這些同事做系統最希望的是解決眼下的問題，很多會考慮後續公司業務的發展，但是我們作為產品經理，需要不斷關注公司的發展，關注行業內同等公司的發展和趨勢，在設計系統的時候預留足夠的空間來支持業務發展；
1. 系統配置項有一些功能是需要經常調整，或者後續極有可能進行擴展的，如果我們要求技術在代碼中直接寫死功能配置，那麼在後續的業務的拓展中就很有可能出現經常修改需求的情況，我們需要和業務進行密切溝通，整理出哪些參數是會發生變化的，把這些信息做成一些調整的配置，在業務發生改變的情況下能夠及時改變；
下圖就是系統的判斷規則作為配置化，如果業務在使用過程中有調整，他們可以在這裏及時調整數量，觀看不同配置下面數據的變化
做B端企業一定要有數據中台的概念，一個相同的數據在企業內部多個部門之間進行流轉，每個部門對於該數據的使用都有所不同，如果我們在每個系統都單獨維護相關的數據，極有可能出現數據不同步的情況，一旦出現就會有不可預知的風險；
例如電商公司有一個最基礎的數據“SKU”，在SKU上會有很多的信息：產品信息、產品圖片、採購屬性、訂單屬性、物流屬性、倉庫屬性等，我們之前項目就發生過一個問題，由於上游產品系統更換了圖片，但是未及時通知到採購系統，導致了採購買貨到倉庫之後才發現貨不對板，造成了很大的損失；
在這個事情上我們吸取教訓，後續處理這種公用的數據時，一律由源頭系統對數據進行修改處理，處理完成之後，各個系統從源頭數據庫進行調取使用，保證了數據的唯一性和準確性；
在這一環節，建議大家多和技術同學進行溝通，保證功能、數據準確的同事還要保證性能，溝通確定一個最優的方案。
3. 配合上下游系統B端系統大多數是一個鏈條，需要各方系統進行配合使用，產品同學在設計各自負責模塊的需求時，需要多和其他系統的同事進行溝通，瞭解其他系統的規劃和配合，在必要的時候也要熟悉一下其他系統的流程，與當前負責系統配合的地方一定要多多熟悉，這樣在設計自己系統功能的時候，就會有一個全局的意識，從公司層面來看怎麼才能讓整個鏈條跑通。
望與君共勉，歡迎評論騷擾~
本文由 @elvin 原創發佈於人人都是產品經理，未經作者許可，禁止轉載。
題圖來自pixabay，基於CC0協議。