談及賬號(hào)及權(quán)限的問題，更多人一開始會(huì)直接想到的是登錄注冊(cè)的交互體驗(yàn)及安全性，但對(duì)于B2B電商平臺(tái)來說，會(huì)遇到更多的場(chǎng)景，對(duì)于功能的要求也比較重視。本文主要從B2B電商的角度，講述賬號(hào)及權(quán)限設(shè)計(jì)的問題，以及我所踩過的那些坑。

一、賬號(hào)體系

B2B電商平臺(tái)的交易角色由采購商，供應(yīng)商和平臺(tái)三方構(gòu)成。

在項(xiàng)目初期，由于產(chǎn)品未參與數(shù)據(jù)庫設(shè)計(jì)的過程，所以數(shù)據(jù)庫設(shè)計(jì)者更多的是憑借已知的需求及經(jīng)驗(yàn)進(jìn)行數(shù)據(jù)庫的設(shè)計(jì)，采購商的賬號(hào)方面主要是由兩個(gè)表組成：賬號(hào)表和采購商信息表；賬號(hào)與采購商信息之間的關(guān)系為1：n的關(guān)系。

但是隨著項(xiàng)目的上線及推廣，該套賬號(hào)體系被證明不能滿足業(yè)務(wù)部門的需求。在我們?cè)瓉淼恼J(rèn)知中，一個(gè)采購商（即一個(gè)企業(yè)）作為一個(gè)購買單位，如果有多個(gè)人負(fù)責(zé)采購的情況下，多個(gè)賬號(hào)共享一個(gè)采購商的信息即可。但是后來我們的采購商出現(xiàn)的連鎖店，而且連鎖店處于采購成本和管理的因素，更多的是由專門的采購人員或老板進(jìn)行統(tǒng)一的采購，因此賬號(hào)與采購商的關(guān)系變成了n：n的關(guān)系

因此衍生出如下幾個(gè)問題：

1. 數(shù)據(jù)庫的設(shè)計(jì)

根據(jù)需求一個(gè)采購商可能會(huì)存在多個(gè)采購人員，同一個(gè)采購可能需要同時(shí)負(fù)責(zé)多家店的采購，因而賬號(hào)和采購商的關(guān)系變?yōu)槎鄬?duì)多的關(guān)系；

實(shí)際上由于前期設(shè)計(jì)錯(cuò)誤，導(dǎo)致重新進(jìn)行數(shù)據(jù)庫的設(shè)計(jì)不再可能，只能基于之前的數(shù)據(jù)結(jié)構(gòu)進(jìn)行修改，這里我們將原來的一對(duì)多關(guān)系的兩個(gè)表整體看做一個(gè)采購商表，新增一個(gè)賬號(hào)表和一個(gè)關(guān)系表即可完成設(shè)計(jì)

另外，其他業(yè)務(wù)模塊對(duì)于賬號(hào)/采購商的引用需要進(jìn)行重新的檢查，在業(yè)務(wù)邏輯上，一個(gè)采購實(shí)體的性質(zhì)是采購商而不是賬號(hào)。所以和采購業(yè)務(wù)相關(guān)的業(yè)務(wù)模塊如：訂單、優(yōu)惠券、文章消息、購物車商品等均與采購商id關(guān)聯(lián)，而與賬號(hào)相關(guān)的業(yè)務(wù)需要與賬號(hào)Id關(guān)聯(lián)（與新的賬號(hào)表中的id關(guān)聯(lián)），如：昵稱、登錄賬號(hào)、密碼等。

2. 業(yè)務(wù)流程設(shè)計(jì)

由于多個(gè)賬號(hào)共用一個(gè)采購商，在有員工離職或其他情況下，必須對(duì)于采購商的某個(gè)賬號(hào)進(jìn)行關(guān)系的解綁，所以必須有一個(gè)賬號(hào)能夠管理該企業(yè)的其他賬號(hào)。所以對(duì)于直接創(chuàng)建新企業(yè)的賬號(hào)，將這個(gè)賬號(hào)賦予一定的權(quán)限，將其定義為管理員賬號(hào)。

對(duì)于非管理員賬號(hào)，可以由管理員賬號(hào)直接添加，這樣可以省去注冊(cè)的麻煩也可用于批量注冊(cè)賬號(hào)。同時(shí)業(yè)務(wù)設(shè)計(jì)中也需要考慮登錄同一個(gè)賬號(hào)后，在多個(gè)采購商之間進(jìn)行切換使用的問題。

（1）新增賬號(hào)并綁定企業(yè)

注冊(cè)新賬號(hào)之后，可以直接繼續(xù)創(chuàng)建新的企業(yè)，創(chuàng)建新企業(yè)后，該賬號(hào)將自動(dòng)成為企業(yè)的管理員。同時(shí)也可直接進(jìn)入頁面瀏覽之后，再創(chuàng)建新的企業(yè)。另外，也可直接由企業(yè)管理員添加進(jìn)入該企業(yè)（有點(diǎn)類似于社交中群成員和群主的概念）。

（2）老賬號(hào)綁定企業(yè)

已注冊(cè)的賬號(hào)，可以選擇創(chuàng)建新企業(yè)或由管理員添加進(jìn)入已存在的企業(yè)。

經(jīng)驗(yàn)教訓(xùn)總結(jié)：在需求的初期，一定得做好需求的邏輯模型的設(shè)計(jì)，梳理其中的角色（實(shí)體），屬性及實(shí)體之間的關(guān)系，以供數(shù)據(jù)庫設(shè)計(jì)人員進(jìn)行物理模型的設(shè)計(jì)，否則在后期會(huì)花費(fèi)更多的成本進(jìn)行修改。

二、權(quán)限設(shè)計(jì)

現(xiàn)在市面上大多數(shù)電商網(wǎng)站對(duì)于權(quán)限的設(shè)計(jì)已日趨完善，尤其是在商品瀏覽方面，登錄與不登錄沒有什么區(qū)別，甚至在下單支付環(huán)節(jié)大多數(shù)電商網(wǎng)站已經(jīng)可以做到不用登錄即可下單，這方面不做過多說明

但是在to B端的電商網(wǎng)站中，由于對(duì)于不同地區(qū)，不同用戶等級(jí)的采購商來說，看到的價(jià)格是不一樣的。甚至有些電商網(wǎng)站為了保證自家商品的隱私性（是否有該商品，商品的價(jià)格是否有優(yōu)勢(shì)），在不登錄的情況下都不可以瀏覽商品。另外對(duì)于不同的行業(yè)，to B端的電商上的采購商必須提交相應(yīng)的資質(zhì)給平臺(tái)進(jìn)行審核才能進(jìn)行采購。

因此，to B端的電商網(wǎng)站需要在用戶的體驗(yàn)和業(yè)務(wù)需求上進(jìn)行一些權(quán)衡，什么情況下能瀏覽？什么情況下能看到價(jià)格？什么情況下能進(jìn)行下單支付？

在我們前期的系統(tǒng)設(shè)計(jì)中，索性直接一刀切，用戶打開APP直接進(jìn)入登錄頁面，在未登錄且關(guān)聯(lián)采購商資質(zhì)審核通過前不能進(jìn)行進(jìn)入商城主頁面。但隨著業(yè)務(wù)的發(fā)展，在APP的推廣過程中，如果用戶看不到商城的商品，采購商不太愿意注冊(cè)一個(gè)不了解的產(chǎn)品。

因?yàn)檫@中間涉及資質(zhì)的審核，需要填寫企業(yè)資料、上傳證件，會(huì)比較麻煩，所以這種矛盾變得越來越激烈。因此，在后期我們對(duì)于用戶的權(quán)限進(jìn)行的重新的調(diào)整。

權(quán)限設(shè)計(jì)邏輯如下：

根據(jù)登錄狀態(tài)和采購商狀態(tài)，將權(quán)限分為以下幾層：

1. 未登錄賬號(hào)的權(quán)限；
2. 已登錄賬號(hào)，但未綁定采購商的權(quán)限；
3. 已登錄賬號(hào)且已綁定采購商，但是采購商未審核通過；
4. 已登錄賬號(hào)且已綁定采購商，采購商資質(zhì)審核已通過。

對(duì)于不同的權(quán)限等級(jí)，將頁面內(nèi)容按照不同權(quán)限等級(jí)進(jìn)行歸類：

1. 不需登錄即可看到的內(nèi)容，主要是商品列表中的商品，注冊(cè)相關(guān)頁面等；
2. 需登錄但是不需要采購商信息的內(nèi)容，如：賬號(hào)名，昵稱等；
3. 需要登錄且需要采購商信息，但采購商為未審核通過的狀態(tài)所看到的內(nèi)容；
4. 需要登錄且需要賬號(hào)信息才能看到的內(nèi)容，如：商品價(jià)格，購物車等。

按照以上邏輯對(duì)于權(quán)限進(jìn)行劃分之后，就可對(duì)各個(gè)頁面進(jìn)行整體的設(shè)計(jì)了。在我們的實(shí)際開發(fā)過程中，由于之前是只有已登錄且關(guān)聯(lián)采購商審核通過才可進(jìn)入商城主頁面。所以若需要對(duì)權(quán)限邏輯進(jìn)行從新設(shè)計(jì)，那么各個(gè)頁面調(diào)取接口的邏輯必須修改（這部分地方值得深入思考）。

所以最后我們對(duì)于未登錄，采購商資質(zhì)未審核通過權(quán)限涉及的相關(guān)頁面重新設(shè)計(jì)了一套（頁面的復(fù)制粘貼，調(diào)取獨(dú)立的接口），但這樣的弊端是后續(xù)有一部分頁面的修改迭代都必須同時(shí)改兩處地方，而且頁面的體驗(yàn)也會(huì)損失很大一部分。

經(jīng)驗(yàn)教訓(xùn)總結(jié)：由于前面直接在登錄頁面進(jìn)行一刀切，在后期對(duì)權(quán)限邏輯進(jìn)行調(diào)整的時(shí)候，導(dǎo)致涉及的東西太多而不敢直接在已有的基礎(chǔ)上進(jìn)行修改。所以我們?cè)谧鰴?quán)限架構(gòu)設(shè)計(jì)的時(shí)候，就算當(dāng)初的需求是這樣要求的，也需要考慮后續(xù)需求修改的拓展性。

三、前端展示頁面相關(guān)設(shè)計(jì)

1. 登錄注冊(cè)流程：與C端的電商的登錄注冊(cè)模塊不同，除了賬號(hào)的申請(qǐng)之外還要考慮采購商企業(yè)資料的提交（也提供跳出路程的出口）。
2. 賬號(hào)的管理：上文說到的每個(gè)采購商的管理員需要管理子賬號(hào)，所以提供添加子賬號(hào)的頁面（不存在的子賬號(hào)則直接先生成一條賬號(hào)信息），并可將該賬號(hào)從采購商中刪除。
3. 創(chuàng)建新采購商：提供兩條路徑：一個(gè)是在注冊(cè)時(shí)，一并完成新采購商的創(chuàng)建，一個(gè)是登錄后，專門提供一個(gè)入口創(chuàng)建新采購商。
4. 切換所屬的企業(yè)：采購商可以切換當(dāng)前所屬的企業(yè)，以方面單獨(dú)為每個(gè)企業(yè)進(jìn)行采購。

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

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