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

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

雖說都沒看到結(jié)果，但無論是為了自身成長(zhǎng)還是為了往后更大的項(xiàng)目做準(zhǔn)備，都應(yīng)該在此停留并作出階段總結(jié)。

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

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

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

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

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

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

B）功能調(diào)研

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

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

即使可以順利注冊(cè)登錄，看到的模塊和功能也只是別人家產(chǎn)品的基礎(chǔ)業(yè)務(wù)功能，而這些功能往往是所有競(jìng)品都有的基礎(chǔ)部分，更重要的后臺(tái)處理邏輯看不見，要分析只能分析到表面的皮毛。對(duì)于增值性和服務(wù)性的拓展功能就更不用說了，都是要錢的！（不排除有慷慨大方的老板愿意掏錢買買買）

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

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

A）模塊間的交互

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

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

B）導(dǎo)航欄設(shè)計(jì)

（馬幫ERP，為中大型賣家服務(wù)）

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

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

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

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

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

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

之所以把導(dǎo)航欄的設(shè)計(jì)放在產(chǎn)品框架這里討論，正是因?yàn)槟壳霸谧鲭娚蘀RP。而ERP系統(tǒng)的模塊較多，且操作者使用時(shí)需要切換頁面。如何展示各個(gè)模塊和頁面讓使用者一目了然，減少尋找頁面的時(shí)間；如何通過合理的功能按鈕連接頁面之間的關(guān)系，避免尋找頁面，都是產(chǎn)品經(jīng)理需要考慮的。

C）涉及到的角色權(quán)限問題

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

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

A）前置條件

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

B）后置條件

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

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

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

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

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

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

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

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

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

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

D）操作權(quán)限

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

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

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

題圖來自u(píng)nsplash，基于CC0協(xié)議