談及賬号及權限的問題，更多人一開始會直接想到的是登錄注冊的交互體驗及安全性，但對于B2B電商平台來說，會遇到更多的場景，對于功能的要求也比較重視。本文主要從B2B電商的角度，講述賬号及權限設計的問題，以及我所踩過的那些坑。

一、賬号體系

B2B電商平台的交易角色由采購商，供應商和平台三方構成。

在項目初期，由于産品未參與數據庫設計的過程，所以數據庫設計者更多的是憑借已知的需求及經驗進行數據庫的設計，采購商的賬号方面主要是由兩個表組成：賬号表和采購商信息表；賬号與采購商信息之間的關系為1：n的關系。

但是随着項目的上線及推廣，該套賬号體系被證明不能滿足業務部門的需求。在我們原來的認知中，一個采購商（即一個企業）作為一個購買單位，如果有多個人負責采購的情況下，多個賬号共享一個采購商的信息即可。但是後來我們的采購商出現的連鎖店，而且連鎖店處于采購成本和管理的因素，更多的是由專門的采購人員或老闆進行統一的采購，因此賬号與采購商的關系變成了n：n的關系

因此衍生出如下幾個問題：

1. 數據庫的設計

根據需求一個采購商可能會存在多個采購人員，同一個采購可能需要同時負責多家店的采購，因而賬号和采購商的關系變為多對多的關系；

實際上由于前期設計錯誤，導緻重新進行數據庫的設計不再可能，隻能基于之前的數據結構進行修改，這裡我們将原來的一對多關系的兩個表整體看做一個采購商表，新增一個賬号表和一個關系表即可完成設計

另外，其他業務模塊對于賬号/采購商的引用需要進行重新的檢查，在業務邏輯上，一個采購實體的性質是采購商而不是賬号。所以和采購業務相關的業務模塊如：訂單、優惠券、文章消息、購物車商品等均與采購商id關聯，而與賬号相關的業務需要與賬号Id關聯（與新的賬号表中的id關聯），如：昵稱、登錄賬号、密碼等。

2. 業務流程設計

由于多個賬号共用一個采購商，在有員工離職或其他情況下，必須對于采購商的某個賬号進行關系的解綁，所以必須有一個賬号能夠管理該企業的其他賬号。所以對于直接創建新企業的賬号，将這個賬号賦予一定的權限，将其定義為管理員賬号。

對于非管理員賬号，可以由管理員賬号直接添加，這樣可以省去注冊的麻煩也可用于批量注冊賬号。同時業務設計中也需要考慮登錄同一個賬号後，在多個采購商之間進行切換使用的問題。

（1）新增賬号并綁定企業

注冊新賬号之後，可以直接繼續創建新的企業，創建新企業後，該賬号将自動成為企業的管理員。同時也可直接進入頁面浏覽之後，再創建新的企業。另外，也可直接由企業管理員添加進入該企業（有點類似于社交中群成員和群主的概念）。

（2）老賬号綁定企業

已注冊的賬号，可以選擇創建新企業或由管理員添加進入已存在的企業。

經驗教訓總結：在需求的初期，一定得做好需求的邏輯模型的設計，梳理其中的角色（實體），屬性及實體之間的關系，以供數據庫設計人員進行物理模型的設計，否則在後期會花費更多的成本進行修改。

二、權限設計

現在市面上大多數電商網站對于權限的設計已日趨完善，尤其是在商品浏覽方面，登錄與不登錄沒有什麼區别，甚至在下單支付環節大多數電商網站已經可以做到不用登錄即可下單，這方面不做過多說明

但是在to B端的電商網站中，由于對于不同地區，不同用戶等級的采購商來說，看到的價格是不一樣的。甚至有些電商網站為了保證自家商品的隐私性（是否有該商品，商品的價格是否有優勢），在不登錄的情況下都不可以浏覽商品。另外對于不同的行業，to B端的電商上的采購商必須提交相應的資質給平台進行審核才能進行采購。

因此，to B端的電商網站需要在用戶的體驗和業務需求上進行一些權衡，什麼情況下能浏覽？什麼情況下能看到價格？什麼情況下能進行下單支付？

在我們前期的系統設計中，索性直接一刀切，用戶打開APP直接進入登錄頁面，在未登錄且關聯采購商資質審核通過前不能進行進入商城主頁面。但随着業務的發展，在APP的推廣過程中，如果用戶看不到商城的商品，采購商不太願意注冊一個不了解的産品。

因為這中間涉及資質的審核，需要填寫企業資料、上傳證件，會比較麻煩，所以這種矛盾變得越來越激烈。因此，在後期我們對于用戶的權限進行的重新的調整。

權限設計邏輯如下：

根據登錄狀态和采購商狀态，将權限分為以下幾層：

1. 未登錄賬号的權限；
2. 已登錄賬号，但未綁定采購商的權限；
3. 已登錄賬号且已綁定采購商，但是采購商未審核通過；
4. 已登錄賬号且已綁定采購商，采購商資質審核已通過。

對于不同的權限等級，将頁面内容按照不同權限等級進行歸類：

1. 不需登錄即可看到的内容，主要是商品列表中的商品，注冊相關頁面等；
2. 需登錄但是不需要采購商信息的内容，如：賬号名，昵稱等；
3. 需要登錄且需要采購商信息，但采購商為未審核通過的狀态所看到的内容；
4. 需要登錄且需要賬号信息才能看到的内容，如：商品價格，購物車等。

按照以上邏輯對于權限進行劃分之後，就可對各個頁面進行整體的設計了。在我們的實際開發過程中，由于之前是隻有已登錄且關聯采購商審核通過才可進入商城主頁面。所以若需要對權限邏輯進行從新設計，那麼各個頁面調取接口的邏輯必須修改（這部分地方值得深入思考）。

所以最後我們對于未登錄，采購商資質未審核通過權限涉及的相關頁面重新設計了一套（頁面的複制粘貼，調取獨立的接口），但這樣的弊端是後續有一部分頁面的修改叠代都必須同時改兩處地方，而且頁面的體驗也會損失很大一部分。

經驗教訓總結：由于前面直接在登錄頁面進行一刀切，在後期對權限邏輯進行調整的時候，導緻涉及的東西太多而不敢直接在已有的基礎上進行修改。所以我們在做權限架構設計的時候，就算當初的需求是這樣要求的，也需要考慮後續需求修改的拓展性。

三、前端展示頁面相關設計

1. 登錄注冊流程：與C端的電商的登錄注冊模塊不同，除了賬号的申請之外還要考慮采購商企業資料的提交（也提供跳出路程的出口）。
2. 賬号的管理：上文說到的每個采購商的管理員需要管理子賬号，所以提供添加子賬号的頁面（不存在的子賬号則直接先生成一條賬号信息），并可将該賬号從采購商中删除。
3. 創建新采購商：提供兩條路徑：一個是在注冊時，一并完成新采購商的創建，一個是登錄後，專門提供一個入口創建新采購商。
4. 切換所屬的企業：采購商可以切換當前所屬的企業，以方面單獨為每個企業進行采購。

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

題圖來自Unsplash，基于CC0協議

,

更多精彩资讯请关注tft每日頭條，我们将持续为您更新最新资讯!

查看全部