作者總結了入行6個月以來所遇的三大坑，點滴思考與記錄，相信能夠給你帶來幫助。

8月16號星期三下午輪崗結束至此已有4個月，期間參與了3個項目。一個原本今天要上線，無奈公司DBA部門搬家導致服務器不可用而延期；一個受制于各種原因，由原來8個模塊砍到4個再到上星期為止只上線了一個頁面-_-||；還有一個業務大方向未確定但原型圖已完成了31.33%且無PRD。

雖說都沒看到結果，但無論是為了自身成長還是為了往后更大的項目做準備，都應該在此停留并作出階段總結。

首先要說清楚B端產品，很大程度上其實只能說是一種輔助線下業務，提高工作效率的工具，而對于我所做的電商公司后臺管理系統來說更是如此—在過去沒有電腦的時代，倉庫庫存、出入庫調撥公司財務狀況這類的信息都用紙質載體記錄，倉庫工作人員可以隨意用筆在載體上修改信息（記錄的規范可能存在于倉庫具體操作規范里不過如今可以靠電腦系統來作出限制達到信息規范的效果）。

產品的所有功能與展現的信息都應當服務于線下操作人員，系統功能貼合于實際業務流程，因此一切的開始，源于業務的調研。

第一坑 To B產品的產品調研

A）業務調研

C端產品并不存在業務調研一說，因為在確認了要解決用戶什么問題之后，產品的目標和業務便很明確。

B端產品的業務流程則多如牛毛，而且彼此之間也緊密關聯。在原有基礎上更改一個小流程，都會影響到很多其他數據，一旦節點和數據回傳的時間沒有琢磨好，往往會發生數據沖突。在這么復雜的情況下，就需要對熟悉業務的人員盤根問底，了解好每一個數據的意義，這會浪費業務人員大量的時間。就我們公司而言，有時間解答我們問題的往往是管理層，但他們沒有底層人員熟悉業務和操作，而底層員工則太忙而沒有時間，因此需要提前安排好調研時間。

B）功能調研

如果做的是C端，那么產品人員自己也是用戶的一員。對于自家產品，沒事就可以隨便點點點，發現哪些地方交互做得不舒服，哪些信息不夠突出，甚至可以去appstore下載幾十個競品參考一下，立馬優化。

但對于B端產品來說，市面上根本看不到其他公司的后臺系統。而軟件服務商提供的，往往在注冊的時候就會被要求提供手機或身份證或企業執照等證明文件。

即使可以順利注冊登錄，看到的模塊和功能也只是別人家產品的基礎業務功能，而這些功能往往是所有競品都有的基礎部分，更重要的后臺處理邏輯看不見，要分析只能分析到表面的皮毛。對于增值性和服務性的拓展功能就更不用說了，都是要錢的?。ú慌懦锌犊蠓降睦习逶敢馓湾X買買買）

此外還有一點，產品經理接到一個項目時，往往會根據過去的經驗來想象和模擬業務流程，如果在調研B端產品的業務前就先入為主地憑空捏造出一套看似合理的業務流程的話，最終被打臉的可能性是極大的。

第二坑 如何決定產品框架

A）模塊間的交互

電商系統由于涉及訂單、貨物管理和金額，因此系統功能模塊多而且數據交互也多。賣家在使用時，可能需要不斷地在多個頁面間切換，比如發貨時，需要在訂單模塊查看買家所在地（訂單目的地），在物流模塊查詢運費，選擇最優的渠道，如果遇上偏遠地區的買家，可能還要額外設置物流匹配規則節省日后遇到類似情況的處理時間。

如果按功能模塊區分，“與買家溝通”是屬于客服模塊的（也有可能賣家在電商平臺溝通）；“設置和保存渠道設置”是物流模塊的，其他則是訂單模塊的。在考慮到訂單模塊原本已有較多功能按鈕的情況下，是否根據業務流程加入“溝通買家”和“設置物流渠道規則”這兩個功能，要的話放在哪不影響頁面，則需要產品經理來判斷。

B）導航欄設計

（馬幫ERP，為中大型賣家服務）

首先，目前大部分網頁導航欄菜單都位于左側或者頂部，二者選其一或二者皆有。這是因為人在瀏覽網頁時，最先關注的是左上方的內容，再順著色塊的引導從左到右或從上到下去關注內容。所以一般情況下，品牌logo都會放在左上方利于使用者加深印象。

其中，頂部導航欄能存放的模塊較少，左側導航欄的擴展性更好。

如果系統模塊只有兩層或更少，采用左側導航欄（加上導航欄可以縮放的功能）可以加大內容展示面積，模塊名稱和頁面名稱的層級結構也能通過點擊厚伸展的動效讓人覺得一目了然。但如果操作時需要在不同模塊的不同子頁面間不斷切換的話，模塊伸展的動效反而會讓使用者覺得不耐煩。

特別欣賞公司現有系統的標簽欄功能，點擊過的頁面會保存歷史，先前加載過的數據也會保留，這樣如果需要切換頁面操作，就可以直接點擊標簽欄，而不用重新在導航欄里面找了。

但如果在已經采用了頂部導航欄，再使用標簽欄的話，會讓頁面出現兩個“橫條”，減小內容展示面積。如果點擊的操作區域不大，更會導致點擊錯誤的情況，因此如果采用了頂部導航欄的設計，就不建議加上標簽欄了。

還有 2016年“跨境電商最具人氣獎”店小秘只有頂部導航欄，不過下拉菜單的分類做的詳細，面對的目標用戶又是小型賣家，看上去更適合這種輕量型的設計。

之所以把導航欄的設計放在產品框架這里討論，正是因為目前在做電商ERP。而ERP系統的模塊較多，且操作者使用時需要切換頁面。如何展示各個模塊和頁面讓使用者一目了然，減少尋找頁面的時間；如何通過合理的功能按鈕連接頁面之間的關系，避免尋找頁面，都是產品經理需要考慮的。

C）涉及到的角色權限問題

權限控制一直是SAAS化軟件的核心，電商ERP系統也需要權限控制。而在企業管理員開放權限給下屬使用時，面臨的導向問題也是和產品定框架時的問題一樣：是按照業務邏輯去分配權限呢，還是按照功能模塊頁面去分配？如果兩種方向都無法完美地解決權限控制的問題，那只好一個一個功能按鈕一類一類數據去分配了。

第三坑 四面楚歌的業務操作功能

A）前置條件

前置條件指的是想要執行某個功能按鈕前要做的事情。比如當我要刪除某條數據記錄前，需要先勾選，如果這條記錄在某個狀態下是不能刪除的，那么就應該有系統提示原因。有的功能按鈕觸發之后變動的數據較多，對應限制的邏輯也要增加。

B）后置條件

和前置條件相比，后置條件更兇殘了，指的是執行某個功能按鈕后會發生的影響。前后置條件都一樣，包含前端界面顯示和后臺數據的變化，需要產品經理十分熟悉系統操作和數據層面的邏輯，考慮不周全的話，又是開發的一頓暴揍。

To B產品的坑大部分都是出在后置條件，模塊多，數據量大，并且一個模塊涉及到后臺的數據表可能有好幾張，操作一條記錄往往會牽扯到多張表里面的多條數據的變化，可以說是“牽一發而動全身”了。除了憑借對產品的熟悉程度去設置以外，沒有其他辦法。

所幸的是，測試工程師也能通過數據測試協助完善前后置條件，但除非十分熟悉系統業務，否則測試人員也只是根據PRD和他們自身的經驗去判斷系統有無出錯。

C）批量操作與非批量操作

我曾經見過一個簡陋的后臺系統，里面有一個操作按鈕位于數據表的上方，必須讓使用者先勾選復選框之后才能點擊操作，當時我為了盡快了解這個功能的作用，只勾選了一條記錄就去點擊這個按鈕了，可是隨后系統卻提示我需要勾選多條記錄。有了這個經驗，當我去點擊旁邊的按鈕時，預先勾選了兩條數據，隨后系統還是提示我操作錯誤了——這個按鈕的功能和第一個一樣，不過它只能對單條數據操作。

這個系統很蠢，也少有蠢成這樣的系統，但是卻給了我提示：

1. 數據表上方的操作如果只能針對單條或多條來進行操作，應當在名字上有區分，比如“批量刪除”，而不只是“刪除”；
2. 如果只能針對單條記錄操作，應當簡化“勾選復選框——點擊按鈕”這兩步操作，最好的狀況是把按鈕放在數據表的每一條數據里面，點擊按鈕就等于完成了操作；

對于批量操作還有一個需要注意的地方，比如批量刪除，如果批量勾選的數據中包含了不可刪除的數據記錄，那么點擊批量刪除后，是所有記錄都不允許刪除并提示，還是執行可刪除的操作然后披露未刪除的數據呢？前者要注意如果所有都不允許刪除，那么勾選的記錄也要在前端繼續保持勾選狀態，避免讓人再重新勾選一遍，并且應當提示哪些數據妨礙了操作的進行。

如果是后者，則要注意只對部分而不是全部勾選的數據操作，是否符合操作者的本意？另外，前端無法判斷哪些數據可以執行操作哪些不可以，因此執行操作的數據會提交到后臺進行判斷才能返回披露的結果，這樣設計是否會對系統造成壓力或其他影響？

另外就是，為了突出系統的某些功能（業務上的需要），有些針對單獨數據的操作也可以放在數據表的上方，這時就需要從操作的交互或者視覺上給予使用者提示。

D）操作權限

相對于通過權限來控制數據的展現，通過權限來決定賬號的使用者能否看到功能按鈕是一個更好的方式。打個比方，看到一堆的數據但是沒有可操作按鈕，就避免了無權限者去修改數據的可能；看到了可操作的功能按鈕，卻沒有對應可操作的數據，也可行，但是會讓使用者很產生負面情緒。當然，這兩種方式并不沖突，可以讓無權限者看不到數據同時也看不到操作按鈕，就讓他當做沒有這個東西存在吧。

字太多了，還望各位輕噴。

本文由 @Ien 原創發布于人人都是產品經理。未經許可，禁止轉載。

題圖來自unsplash，基于CC0協議