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

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

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

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

產(chǎn)品的所有功能與展現(xiàn)的信息都應當服務于線下操作人員，系統(tǒng)功能貼合于實際業(yè)務流程，因此一切的開始，源于業(yè)務的調(diào)研。

第一坑 To B產(chǎn)品的產(chǎn)品調(diào)研

A）業(yè)務調(diào)研

C端產(chǎn)品并不存在業(yè)務調(diào)研一說，因為在確認了要解決用戶什么問題之后，產(chǎn)品的目標和業(yè)務便很明確。

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

B）功能調(diào)研

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

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

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

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

第二坑 如何決定產(chǎn)品框架

A）模塊間的交互

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

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

B）導航欄設計

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

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

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

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

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

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

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

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

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

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

第三坑 四面楚歌的業(yè)務操作功能

A）前置條件

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

B）后置條件

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

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

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

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

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

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

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

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

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

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

D）操作權限

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

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

本文由 @Ien 原創(chuàng)發(fā)布于人人都是產(chǎn)品經(jīng)理。未經(jīng)許可，禁止轉(zhuǎn)載。

題圖來自unsplash，基于CC0協(xié)議