產品設計體系｜如何搭建註冊、登陸模組及使用者管理（角色、賬戶和許可權）模組

本篇文章中，作者介紹了面向後臺系統設計的使用者管理三大模組。一個清晰的使用者管理系統，可以增強使用者在使用系統中的連貫性以及業務的穩定性，許可權的清晰設定可以增強系統的安全性，減輕迭代的壓力，並減少許可權的冗雜和浪費。一起來看看使用者管理模組應該如何進行產品設計吧。

登陸模組是使用者接觸系統的第一觸點，尤其是對於C端業務而言若註冊流程過程過於冗雜，很容易會造成使用者的流失；而對於B端業務來說，註冊流程可以是第一步也可以適當忽略，具體需要根據公司內部系統之間的連貫性進行判斷，忽略的情況下可以採取直接拉取已驗證的賬號進行登陸操作，以此基礎減少時間的浪費。

01 註冊、登陸模組

登陸系統可以分為註冊登陸、拉取第三方驗證兩種登陸方式：

拉取第三方驗證登陸：登陸無需賬戶，但需要在第三方或賬戶管理處有識別賬戶的統一驗證標識比如微軟提供的郵箱字尾驗證服務，首次登陸時需要在系統後臺中找到該使用者，並給予使用者可訪問或其他許可權，此時資料庫中應儲存使用者標識資訊與許可權便於新增許可權和記錄使用者操作記錄。

註冊登陸：使用者首次註冊登陸時需填寫必要資訊，此時需要根據業務需求從而判斷需要郵箱、手機號等第三方繫結賬戶。一般情況下是可以透過手機號、微訊號、QQ號等直接註冊的。

註冊流程圖：

登陸模組：

登入與註冊是一個連貫的過程，所以在連線過程中需要做到邏輯流暢便於操作自動跳轉等。

登入流程圖：

02 使用者管理（角色、賬戶和許可權）模組

後臺產品的使用者許可權管理系統可以大致分為三個模組：賬戶、角色和許可權管理；

賬戶被賦予角色，角色被配置許可權，一個賬戶可以被賦予多種角色，一個角色只能有其對應的許可權限制；以此達到拒絕耦合資訊冗雜的情況。

1、角色管理

角色是指擁有同一種身份性質的某一類人群的歸納，但角色需要具有繼承和約束關係，以此來表明角色有上下級的區別。

在這個模組中，我們需要根據業務來定義出不同的角色名稱以及定義相應的角色資訊。在業務允許的情況下，儘量不需要將角色設定過多，若存在著角色過多的情況也一定要與角色賦予的許可權理清楚。比如：

繼承&約束關係

角色需要滿足繼承關係以此表明角色的上下級關係，此部分可以參考決策樹根葉子節點來區分角色的父子關係。

角色需要滿足存在著約束關係，以此來表明角色之間的不同點對應角色下設的許可權和業務的不同。

先決條件角色：此情況考慮的是系統龐大時，使用者在新增一個較高影響範圍的角色和許可權是否需要滿足該角色下的子角色；

互斥角色：一個使用者只能分配互斥角色組的一種，例如市場專員 、運營人員 、系統管理可以設定為互斥組，一個使用者只能歸屬為其中一組；設定互斥組是處於對系統和業務安全性的考量，比如一個使用者的角色是系統管理員的角色若賦予運營角色的許可權在誤點選的情況下就有可能會影響線上業務。但具體的互斥角色和對應的許可權設定需要根據業務的實際情況設定。執行時互斥：一個使用者可以擁有多個角色，但在實際業務操作執行中不可同時啟用這兩個角色以此達成動態職責分離。

角色列表頁

角色列表頁更便於系統管理員進行角色和使用者的對應核驗，對角色能進行增刪改查基礎功能外，也可以根據業務實際情況考慮是否新增自定義角色功能等，以此考慮系統的拓展性。

列表頁 = 展示頁 + 一些必要操作的入口；在列表頁中可以將主要的資訊展示出來比如角色ID、角色名稱、許可權、建立時間以及操作等；當基本許可權和操作許可權較多時可以僅展示一部分，剩餘部分可以採用【游標移動到此欄位時進行全部展示or在操作欄位下多加一個檢視操作進行詳情頁的形式】

如下圖：

新增角色頁

“新增角色”和“編輯角色”都是給角色賦予相應的定義，但編輯角色需要考慮目前角色的使用情況，在已有的系統使用中是否已經存在並執行，當修改時是否會影響線上系統。賦予新增角色的許可權是站在長期價值上考慮系統的可拓展性，在不斷迭代的業務中新增業務模組和許可權時無需接入新的開發，但同時更需要在一開始就做好相關的定義與新增的規則，所以在最初搭建時期不建議提供新增角色的功能。

當角色的許可權較少時可以採用【下拉框】的形式來選擇，當權限較多時可以採用【許可權羅列】的形式。

2、許可權管理

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

相關許可權模型可以參考RBAC：基於角色的訪問控制

RBAC定義：當一個操作，同時滿足a與b時，允許操作：a。規定角色可以對哪些資源進行哪些操作 ；b。規定主體擁有哪些角色

RBAC的思想，來源於現實世界的企業結構。

許可權列表頁

一個好的許可權系統需要能夠滿足可拓展、高效易維護、層次分層並且可追溯。

在做許可權梳理之前與業務和開發同學達成一致，確定哪些許可權是同類型的、可同組聚合，而哪些業務或功能的許可權是必須分開設定的。

【許可權性質】部分是根據業務情況實際設定的需要規定好角色與【檢視】、【操作】等許可權的設定，在邏輯整體上需滿足角色於許可權的對應，從而實現不同角色對應的業務頁面檢視、編輯、刪除等功能的不同操作，甚至同個頁面的某些元素的檢視、編輯、刪除等功能根據角色與許可權的對應關係可單獨設定。

許可權設定也可以考慮父子關係

3、賬戶管理

此功能模組與註冊賬戶的功能模組息息相關。賬號管理，是將使用者與角色對應起來的模組，一個使用者對應一個賬戶，一個賬戶可以對應不同的角色，不同的角色被賦予不同的許可權就可以達到了【一個賬戶對應多種許可權】賬戶管理。這一模組，需要設定相應欄位，對內部人員的資訊進行管理，也是管理員最常用到的功能。

賬戶列表頁

列表頁 = 展示頁+一些必要操作的入口，列表頁的主要作用是可以讓使用者清晰的查詢到必要資訊，比如使用者ID、使用者名稱、部門、角色、賬號狀態、註冊時間以及操作（操作中首先應該具備“編輯”、“刪除”基礎的操作功能）；

另一方面，某些賬戶可能存在凍結的情況（此情景狀態在使用者管理賬戶層級較少但某些業務場景中較為常見），基於此種情況需要新增增加“凍結”和“啟用”的功能。

除此之外，便於後續的資料分析和操作記錄可以前端做一些簡單的資料埋點，比如最近登入時間、登入次數等。

新增賬戶頁面

當點選“新增賬戶”按鈕時，當前頁面可以跳轉到填寫賬號資訊的頁面，【新增賬號】頁面的欄位要儘可能的羅列出賬戶所需的資訊並且要確定此賬戶的所對應的角色。由於角色本身是帶有許可權性質的，所以不需要匹配許可權。如下圖：

總結

以上介紹的使用者管理三大模組是主要面向後臺系統設計的，使用者也是企業內部人員。一個清晰的使用者管理系統可以增強使用者在使用系統中的連貫性以及業務的穩定性，許可權的清晰設定可以增強系統的安全性，過於繁多的角色和許可權不僅會增加迭代的壓力也會存在許可權的冗雜和浪費。所以在產品設計的開始一定要遵循MVP原則，小步快走。

本文由 @一個七月 原創釋出於人人都是產品經理。未經許可，禁止轉載。

題圖來自 Unsplash，基於 CC0 協議

該文觀點僅代表作者本人，人人都是產品經理平臺僅提供資訊儲存空間服務。