本篇文章中，作者介紹了面向后臺系統(tǒng)設(shè)計的用戶管理三大模塊。一個清晰的用戶管理系統(tǒng)，可以增強用戶在使用系統(tǒng)中的連貫性以及業(yè)務(wù)的穩(wěn)定性，權(quán)限的清晰設(shè)定可以增強系統(tǒng)的安全性，減輕迭代的壓力，并減少權(quán)限的冗雜和浪費。一起來看看用戶管理模塊應(yīng)該如何進行產(chǎn)品設(shè)計吧。

登錄模塊是用戶接觸系統(tǒng)的第一觸點，尤其是對于C端業(yè)務(wù)而言若注冊流程過程過于冗雜，很容易會造成用戶的流失；而對于B端業(yè)務(wù)來說，注冊流程可以是第一步也可以適當忽略，具體需要根據(jù)公司內(nèi)部系統(tǒng)之間的連貫性進行判斷，忽略的情況下可以采取直接拉取已驗證的賬號進行登錄操作，以此基礎(chǔ)減少時間的浪費。

01 注冊、登錄模塊

登錄系統(tǒng)可以分為注冊登錄、拉取第三方驗證兩種登錄方式：

1. 拉取第三方驗證登錄：登錄無需賬戶，但需要在第三方或賬戶管理處有識別賬戶的統(tǒng)一驗證標識比如微軟提供的郵箱后綴驗證服務(wù)，首次登錄時需要在系統(tǒng)后臺中找到該用戶，并給予用戶可訪問或其他權(quán)限，此時數(shù)據(jù)庫中應(yīng)存儲用戶標識信息與權(quán)限便于新增權(quán)限和記錄用戶操作記錄。
2. 注冊登錄：用戶首次注冊登錄時需填寫必要信息，此時需要根據(jù)業(yè)務(wù)需求從而判斷需要郵箱、手機號等第三方綁定賬戶。一般情況下是可以通過手機號、微信號、QQ號等直接注冊的。

注冊流程圖：

登錄模塊：登錄與注冊是一個連貫的過程，所以在連接過程中需要做到邏輯流暢便于操作自動跳轉(zhuǎn)等。

登錄流程圖：

02 用戶管理（角色、賬戶和權(quán)限）模塊

后臺產(chǎn)品的用戶權(quán)限管理系統(tǒng)可以大致分為三個模塊：賬戶、角色和權(quán)限管理；

賬戶被賦予角色，角色被配置權(quán)限，一個賬戶可以被賦予多種角色，一個角色只能有其對應(yīng)的權(quán)限限制；以此達到拒絕耦合信息冗雜的情況。

1. 角色管理

角色是指擁有同一種身份性質(zhì)的某一類人群的歸納，但角色需要具有繼承和約束關(guān)系，以此來表明角色有上下級的區(qū)別。

在這個模塊中，我們需要根據(jù)業(yè)務(wù)來定義出不同的角色名稱以及定義相應(yīng)的角色信息。在業(yè)務(wù)允許的情況下，盡量不需要將角色設(shè)置過多，若存在著角色過多的情況也一定要與角色賦予的權(quán)限理清楚。比如：

繼承&約束關(guān)系：

• 角色需要滿足繼承關(guān)系以此表明角色的上下級關(guān)系，此部分可以參考決策樹根葉子節(jié)點來區(qū)分角色的父子關(guān)系。
• 角色需要滿足存在著約束關(guān)系，以此來表明角色之間的不同點對應(yīng)角色下設(shè)的權(quán)限和業(yè)務(wù)的不同。
• 先決條件角色：此情況考慮的是系統(tǒng)龐大時，用戶在新增一個較高影響范圍的角色和權(quán)限是否需要滿足該角色下的子角色；
• 互斥角色：一個用戶只能分配互斥角色組的一種，例如市場專員 、運營人員 、系統(tǒng)管理可以設(shè)置為互斥組，一個用戶只能歸屬為其中一組；設(shè)置互斥組是處于對系統(tǒng)和業(yè)務(wù)安全性的考量，比如一個用戶的角色是系統(tǒng)管理員的角色若賦予運營角色的權(quán)限在誤點擊的情況下就有可能會影響線上業(yè)務(wù)。但具體的互斥角色和對應(yīng)的權(quán)限設(shè)置需要根據(jù)業(yè)務(wù)的實際情況設(shè)定。運行時互斥：一個用戶可以擁有多個角色，但在實際業(yè)務(wù)操作運行中不可同時激活這兩個角色以此達成動態(tài)職責(zé)分離。

角色列表頁：

• 角色列表頁更便于系統(tǒng)管理員進行角色和用戶的對應(yīng)核驗，對角色能進行增刪改查基礎(chǔ)功能外，也可以根據(jù)業(yè)務(wù)實際情況考慮是否新增自定義角色功能等，以此考慮系統(tǒng)的拓展性。
• 列表頁 = 展示頁 + 一些必要操作的入口；在列表頁中可以將主要的信息展示出來比如角色ID、角色名稱、權(quán)限、創(chuàng)建時間以及操作等；當基本權(quán)限和操作權(quán)限較多時可以僅展示一部分，剩余部分可以采用【光標移動到此字段時進行全部展示or在操作字段下多加一個查看操作進行詳情頁的形式】

如下圖：

新增角色頁：

• “新增角色”和“編輯角色”都是給角色賦予相應(yīng)的定義，但編輯角色需要考慮目前角色的使用情況，在已有的系統(tǒng)使用中是否已經(jīng)存在并運行，當修改時是否會影響線上系統(tǒng)。賦予新增角色的權(quán)限是站在長期價值上考慮系統(tǒng)的可拓展性，在不斷迭代的業(yè)務(wù)中新增業(yè)務(wù)模塊和權(quán)限時無需接入新的開發(fā)，但同時更需要在一開始就做好相關(guān)的定義與新增的規(guī)則，所以在最初搭建時期不建議提供新增角色的功能。
• 當角色的權(quán)限較少時可以采用【下拉框】的形式來選擇，當權(quán)限較多時可以采用【權(quán)限羅列】的形式。

2. 權(quán)限管理

權(quán)限管理部分是邏輯性最強且對于系統(tǒng)全貌影響來說最為廣大的，需要提前將角色和對應(yīng)的權(quán)限進行匹配，將權(quán)限的名稱、描述、性質(zhì)（基本/操作）等信息梳理清楚，此處需要注意自身是無法給與自身權(quán)限的，雖然在一定情況下會造成操作的麻煩但極大的程度上減少了不安全性。

相關(guān)權(quán)限模型可以參考RBAC：基于角色的訪問控制

• RBAC定義：當一個操作，同時滿足a與b時，允許操作：a.規(guī)定角色可以對哪些資源進行哪些操作 ；b.規(guī)定主體擁有哪些角色
• RBAC的思想，來源于現(xiàn)實世界的企業(yè)結(jié)構(gòu)。

權(quán)限列表頁：

一個好的權(quán)限系統(tǒng)需要能夠滿足可拓展、高效易維護、層次分層并且可追溯。

• 在做權(quán)限梳理之前與業(yè)務(wù)和開發(fā)同學(xué)達成一致，確定哪些權(quán)限是同類型的、可同組聚合，而哪些業(yè)務(wù)或功能的權(quán)限是必須分開設(shè)定的。
• 【權(quán)限性質(zhì)】部分是根據(jù)業(yè)務(wù)情況實際設(shè)置的需要規(guī)定好角色與【查看】、【操作】等權(quán)限的設(shè)置，在邏輯整體上需滿足角色于權(quán)限的對應(yīng)，從而實現(xiàn)不同角色對應(yīng)的業(yè)務(wù)頁面查看、編輯、刪除等功能的不同操作，甚至同個頁面的某些元素的查看、編輯、刪除等功能根據(jù)角色與權(quán)限的對應(yīng)關(guān)系可單獨設(shè)定。
• 權(quán)限設(shè)定也可以考慮父子關(guān)系

3. 賬戶管理

此功能模塊與注冊賬戶的功能模塊息息相關(guān)。賬號管理，是將用戶與角色對應(yīng)起來的模塊，一個用戶對應(yīng)一個賬戶，一個賬戶可以對應(yīng)不同的角色，不同的角色被賦予不同的權(quán)限就可以達到了【一個賬戶對應(yīng)多種權(quán)限】賬戶管理。這一模塊，需要設(shè)置相應(yīng)字段，對內(nèi)部人員的信息進行管理，也是管理員最常用到的功能。

賬戶列表頁：

• 列表頁 = 展示頁+一些必要操作的入口，列表頁的主要作用是可以讓用戶清晰的查詢到必要信息，比如用戶ID、用戶名、部門、角色、賬號狀態(tài)、注冊時間以及操作（操作中首先應(yīng)該具備“編輯”、“刪除”基礎(chǔ)的操作功能）；
• 另一方面，某些賬戶可能存在凍結(jié)的情況（此情景狀態(tài)在用戶管理賬戶層級較少但某些業(yè)務(wù)場景中較為常見），基于此種情況需要新增增加“凍結(jié)”和“啟用”的功能。
• 除此之外，便于后續(xù)的數(shù)據(jù)分析和操作記錄可以前端做一些簡單的數(shù)據(jù)埋點，比如最近登錄時間、登錄次數(shù)等。

新增賬戶頁面：

當點擊“新增賬戶”按鈕時，當前頁面可以跳轉(zhuǎn)到填寫賬號信息的頁面，【新增賬號】頁面的字段要盡可能的羅列出賬戶所需的信息并且要確定此賬戶的所對應(yīng)的角色。由于角色本身是帶有權(quán)限性質(zhì)的，所以不需要匹配權(quán)限。如下圖：

總結(jié)

以上介紹的用戶管理三大模塊是主要面向后臺系統(tǒng)設(shè)計的，用戶也是企業(yè)內(nèi)部人員。一個清晰的用戶管理系統(tǒng)可以增強用戶在使用系統(tǒng)中的連貫性以及業(yè)務(wù)的穩(wěn)定性，權(quán)限的清晰設(shè)定可以增強系統(tǒng)的安全性，過于繁多的角色和權(quán)限不僅會增加迭代的壓力也會存在權(quán)限的冗雜和浪費。所以在產(chǎn)品設(shè)計的開始一定要遵循MVP原則，小步快走。